Probably the single most common question I get from CEO's is where to find great product managers?
In my last article (Product Management vs. Product Marketing) I discussed why product management is very different from product marketing, and how critical it is to have capable product managers. The note seemed to strike a chord in that a record number of you wrote to express your agreement and the need to educate companies about this issue. However, quite a few managers of product management mailed me to say that while they agreed, they had inherited an organization where many of the people with "product manager" titles were really product marketing people with all the problems I described, and they were struggling to correct the situation.
Industry pundits claim that 9 out of 10 product releases are failures in that they don’t meet their goals. I don’t know if that’s the exact stat or not, but I bet it’s not far off. I do believe strongly that most releases are ill-conceived. Countless release cycles are wasted on products that are either not useful or not usable. There are many reasons for these bad products, and each article I write is intended to address some aspect, but I have long argued that the root cause of these wasted releases can most often be traced to how the role of product manager is defined at your company, and the capabilities of the people you choose for this role.
Recently Microsoft launched what may prove to be a very significant technology for those of us that build rich Internet applications. You can learn about this at www.microsoft.com/silverlight <http://www.microsoft.com/silverlight> . But this note isn’t really about Silverlight; it’s about some lessons from their launch. Silverlight is a platform technology, and normally Microsoft is quite good at launching this type of product, and I do think there is true promise for this technology, however, I am very unimpressed with this launch.
Earlier I wrote about general lessons from Apple, but now that i've had my iPhone for a couple of weeks, I thought I'd talk about some of the lessons from this new product. I believe there's much to learn (good and bad) from virtually every new product introduction, but this one is a particularly rich example.
Even though we've been estimating project costs since the beginning of software, it's remarkable to me how much confusion remains. I think the root cause of this confusion is that management needs cost information very early in the process, yet engineering doesn't have the information it needs to do a reasonably accurate estimate until much later in the process. The result is either premature estimates that prove wildly inaccurate, or surprises because people had different assumptions all along and when the accurate estimate comes in, management has a severe case of sticker shock.
How many of you understand the economics of your product? Do you know your exact revenue model? Do you know the total costs of your product? Do you know how much you pay for each new customer? Do you know their lifetime value to the company? Do you know the return your product has generated for the company?
Often I’m asked what the right balance is between new product development and investing in improving existing products. I suppose it’s natural for companies to want to have some sort of percentage guideline, but I try to get companies to think about these investments a little differently. To me, all of these projects are product investments, and rather than worry about whether you’re investing enough in new product lines versus existing product lines, I would rather have the team worry that they’re investing in the best opportunities.
Every so often I meet a product manager that tells me that they are not allowed to talk to their users or customers. Sometimes it’s because the sale reps want to control all access; or maybe it’s because marketing is supposed to be the interface with the customer; and occasionally there is literally a corporate policy restricting direct customer access because of worries about inappropriate statements or commitments. For whatever reason, if you work at a company where you’re told you can’t talk to your users, my advice is to first try hard to change this policy, but if that doesn’t work, dust off your resume and find a place where you can practice your craft and have a shot at creating great products.
If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.