6 diagrams I use to explain Product Management concepts

Some visualisations to help you understand and communicate key ideas in Product Management

They say a picture is worth a thousand words but, honestly, I think they are worth much more. They help you build a common understanding and remove much of the complexity and nuance that comes with written and verbal language.

I wanted to share 6 diagrams I find myself frequently using to when discussing Product Management ideas. These are a few drawings are well-received and convey the point well. The 6 diagrams are:

• The “Product Manager Bottleneck”
• The “Delivery Size Throughput”
• The Classic “Waterfall vs Agile”
• The “Initiative Size, Risk and Leadership Involvement”
• The “Knowledge Silos”
• The “Segmentation Value”

Please feel free to use them in any way you find beneficial to your role.

The “Product Manager Bottleneck”

One of the most common mistakes I see Product Managers make is feeling the need to be a part of every discussion. I understand there is a positive intention behind it — you’re the PM and you need to be across everything in case you’re asked about it.

Unfortunately, this has many drawbacks. First, it’s not practical. You will rapidly become overwhelmed — negatively impacting not only the effectiveness of your team but also your own well-being. Trust me, I’ve done it. Second, you undermine the autonomy of your team.

Great Product Managers know when to be involved and when to step back. They know when to let conversations happen without them. The purpose of an autonomous team is to remove as many dependencies as possible.

In the example below, you can imagine a situation on the left where the Web Engineer asks about a tracking concept to be implemented, the PM then approaches the Product Analysts who said it should match the iOS implementation. The PM then approaches the iOS Engineer in order to collect the details and goes back to the Web Engineer to explain them. Not only does this add unnecessary work to the PM, but it also delays the resolution the Web Engineer is seeking.

In comparison, in the example on the right, the Web Engineer directly approaches the…