Product Management Anti-Patterns - Why Products Fail

I went to an interesting event last week put on by the SVPMA. Marty Cagan from SVPG spoke about "The New Definition of Product Management". By the way, if you ever have the chance to hear Marty speak, or to bring him in for training I'd recommend it. I've heard others from product management teams say the same thing.

Marty's theory is that the main reason products fail to meet their objectives (and 50% of products fail to meet objectives) is poor product management, or more appropriately, the way companies define product management. Here are some of the anti-patterns he talked about:

• thinking that customer requirements = product requirements: 1) customers don't know what's possible and 2) customers don't know what they want.
• using product management for keeping track of which customer requested which feature
• definining product management's role as a spec factory, where either product marketing or sr. management define the high level business requirements, and product management's job is to churn out the PRD

In a nutshell, that kind of thinking will never produce a breakthrough product like an iPod or iPhone (Apple has set the bar pretty high for product companies, haven't they?)

Getting it right:

First, recognize that the Product Manager, more than anyone, is ultimately responsible for the product's success or failure. It doesn't matter how great the rest of the team is if they aren't given something worthwhile to build.

The job of the Product Manager is to discover products that are useful, usable, and feasible. To do that, they need to have:

• knowledge of the user
• knowledge of the domain and market
• knowledge of the technology (not the nuts and bolts, but rather they need to know what's possible)

Some other best practices he spoke about include building hi-fi prototypes, instead of a PRD, to define the product and refine it with users, and to create a strong bond between the UX team and the technical architect - you need to have those discussions between design and engineering early, where the architect can offer insights like "if we did it this way, it would be cheaper to build" and "with Flex we could do X Y and Z". These are two things we do at Macadamian and they've shown to be very successful.

If you're interested in digging deeper, SVPG has a collection of great articles on their site .