Readers of these articles know that I view the high-fidelity prototype as the primary means of describing the product to be built. I have written elsewhere why a prototype is significantly more useful to the product team than the typical paper-based specification. However, that's really the secondary benefit. The primary reasons to create a high-fidelity prototype are to help you gain a much deeper understanding of your product, and ultimately so that you can actually test your ideas with real users before you have your engineering teams take months to go build something that you have no real evidence will serve its purpose.
Have you seen this situation before? Your company gets all excited about a product idea, and as product manager you are asked to define it. You are told that the engineers will be finished with their current project in 4 weeks, so that means take all the time you need, as long as you are ready in 4 weeks.
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.