The “Product Manager Bottleneck”

You don't need to be always available. First, it’s not practical, Second, you undermine the autonomy of your team.

Case

Right : Web Engineer directly approach analyst. Note how many fewer interactions (red arrows) need to happen

The number of interactions rapidly increases and these are all dependent on the PM.

How to use this: If you’re constantly overwhelmed, reflect on how your team interacts with each other — do you need to be in every meeting?

Does your team operate the same when you're on vacation or does everything stop? If it’s the latter, you need to make a conscious effort to facilitate interactions without you.

The “Delivery Size Throughput

often come across frustrations both from business partners and Product Teams about their time-to-market — they feel it’s too slow.

The problem is usually caused by only working on larger chunks of work (funnel on the left). As a result, a team can only work on one topic at a time. This approach may be acceptable if we’re certain something is the right thing to build, but this is very rarely the case.

The reason the agile approach promotes smaller chunks of work is because value delivered quicker and with less risk. The funnel to the right gives us much more flexibility. Smaller pieces of work (blue dots) can move through the funnel at a rapid pace to be validated. If they’re successful, we can invest more effort (small pink circle). If it’s unsuccessful, we iterate again but with limited investment.

How to use this: Look back on what you’ve worked on over the last few months (not just what you shipped). Were all the topics large in scale and complexity or were there a mix of ongoing pieces of work? These may all be in the same theme or different. Assign a basic size to each piece of work (S, M, L) and reflect on what your funnel would look like.

The Classic “Waterfall vs Agile”

If all Product Managers owned the Profit & Loss statements for their product, the wage line item would often be the largest expense. You should look for every opportunity to increase Profit (Return).

When teams ship after a large release, you hope to get an immediate hit of value. Even operating on the assumption that you release the perfect solution with no technical issues first time (spoiler alert: it’s unlikely).