The Product Management Stack

“Dammit, Morpheus. Not everyone believes what you believe.”

“My beliefs do not require them to.”

The Matrix

There is a lifetime of articles, blog posts, videos, podcasts and books out there describing the ideal product stack. Some of them are focused on product strategy, some on execution, some on a bit of both. Some are more applicable to a type of industry or product than others (software, hardware, services, operations, etc.) Some scale better than others. They’re all good, they’re all useful, and they’re all right.

Over the years I’ve developed my own view of the Product Management stack (“PM stack” for short) that’s worked for me. By PM stack I mean a comprehensive view of the big, non-negotiable elements of managing a product and their inter-relationships. By developed I mean scribbled, whiteboarded, tried, tested, burnt fingers, refined, evolved, taught myself Canva and drew an acceptable diagram. In communicating with stakeholders, peers and ICs I’ve used different versions of this view, to admittedly varying degrees of success.

My PM Stack

It’s a bit crowded and can be hard to take in especially if you’re not used to seeing it often in your dreams/nightmares. Let me highlight the key concepts here, and in future posts I’ll unpack some of the notable ones.

The PM stack starts with the company vision at the top, and ends with on-demand releases at the bottom right. So it covers the gist of what a VP Product/Head of Product/CPO would start with and a Product Owner would typically end with, with the Product Manager role covering the messy middle.

There can be no useful product strategy without a sound company strategy, and the same reasoning applies to vision & mission when they are used[1]. This is obvious, hard and underrated — and probably the most important thing I’ve learned in recent years.

At the top right is a constant reminder of the 3 elements that make up the kernel of a good strategy: a diagnosis, a guiding policy and coherent actions[2].

Then we get into the fun part that everyone believes in, few understand and even fewer get right: OKRs. I’ve found that if key results are not easily traceable all the way down to sprint goals, then there’s a communication gap that must be addressed urgently. This is a key enabler of empowered teams.

Going from the product roadmap down to the product backlog, a logical grouping such as Value Streams (esp. if you follow SAFe) or Themes are essential in organizing work, abstracting details and understanding dependencies between teams. On the left of the stack, the continuous validation process ensures that:

• Only validated work makes it way into the backlog (more on this later)
• For major capabilities, a build/buy/partner analysis is done before committing to the work[3]
• User feedback, insights and analytics are fed back into the work stream

The product backlog is made up of epics, user stories (delivering tangible value to internal or external users), enabler tasks (“under the hood” work, tooling, research spikes, technical debt), ideas and bugs. Note that continuous integration doesn’t automatically imply continuous delivery. It helps to have delivery decoupled from integration, using either branches[4] or feature flags[5].

I believe it’s essential for every product leader, and for as many people as possible in product, design & engineering teams, to have a high level understanding of the PM stack. It could be the one I’ve distilled here, or something similar to it, adapted to the company/industry’s reality. Within the PM stack, product leaders might specialize in different areas in larger organizations, or do a little bit of everything in ambitious startups.

I hope you found this view helpful. Feel free to reuse/adapt it — just let me know if you do! Please leave a comment if you have thoughts or questions, or hit me up on Twitter or LinkedIn. Thanks for reading, and hit Follow if you found this useful!

Note: This visualization is heavily inspired by this r/productmanagement thread and this Reforge article.

References/Further Reading:

1. Recent tweet by Melissa Perri. For more read “Escaping the Build Trap”.
2. “Good Strategy, Bad Strategy” by Richard Rumelt.
3. An example of a Build vs Buy framework is here. I use an adapted version based on the same approach.
4. Trunk Based Development
5. Feature flags
6. “How to Define Your Product Strategy” series by Gibson Biddle