The new product manager

I was excited to see Brad reference this new blog on agile product management. I had a post percolating on this very topic and I’ve enjoyed Brian’s first posts.

For the most part the product management role in software has remained pretty static over the past 15 years or if anything, become further specialized with special designations like product strategy, product definition, product marketing, technical product manager, partner product manager, etc.

The “established” thinking on product management is pretty well encapsulated in this chart developed by Pragmatic Marketing.


I think it would be a missed opportunity not to reexamine the role of the product manager. Changes in technology and process have almost necessitated it. Web applications with their short release cycles and quick user feedback, and agile with its focus on incremental development, change the nature of product management. Some of these changes need to happen to accommodate agile development cycles. Other changes needed to happen anyways and the aforementioned trends have just accelerated them.

So what’s different today?

Well in this new agile world, a product manager needs to be:

A priority setter. At any point in time there should be a #1, #2, and #3 priority for the development team. The product manager should be able to clarify those priorities on a weekly or even daily basis.

An information gatherer/disseminator. The old product manager outlined a feature set for a whole release at a time. That meant while the release was in development, the product manager was almost antagonistic to new ideas. “Let’s just get this release done, no new ideas now please.” With agile, that constraint is lifted. A new idea is an opportunity to improve the ROI of the development team that very month. Product managers need to spend a lot more energy getting new ideas into the queue to improve the probability of increasing ROI. This also means that the product manager will come up with fewer of these ideas on his own. More likely he’ll solicit them from users and developers and do less editing/filtering.

A salesperson. Selling the vision of the product to the development team is essential. How else can they come up with lots of good feature ideas or believe in the priorities? More energy is spent explaining the “why” of the product versus the “what.”

This also means a product manager should not be:

A document generator. Why bother to generate that 100 page PRD? It’s going to change a month into the project anyhow.

The final word on what makes it into a product. Control is an illusion.

The sole expert on the product topic. Appeal to authority just encourages everyone else to turn their brains off.

These shifts in focus also change the psychic rewards for the product manager. Most product managers I’ve known love being the satisfaction of being resident expert. They also enjoy being the George Bush of their product.

The new product managers get their kicks by helping the development team be successful. They also enjoy the tinkering, trial and error and quick feedback that comes with agile product management. Before: “I’ve pulled this lever 50 times. I have 11 years of experience pulling this lever in a best of breed environment.” After: “Hey, what does this other lever do? Let’s pull it and see what happens.”

Looking forward to more posts from Grillin' in the Storm.