The Product Manager BottleNeck
Don’t be the Product Manager that slows delivery, isolates your team, and burns out.
A mistake I made early on in my Product Management career was trying to be involved with every discussion and workstream. I had a positive intention behind my approach. I was the PM and wanted to be across my domain to ensure everyone had the right context and to answer questions from the team or from stakeholders.
I thought that was the only way I could be a Helpful Product Manager, otherwise, I’d be letting people down. It seemed to be the way other Product Managers were doing it and, since I was new to the role, I followed the direction. The team also seemed to be comfortable with the way of working.
Unfortunately, this approach was actually hampering me and the team. Unintentionally, I was:
- Slowing the pace of our team’s delivery
- Undermining the autonomy of the team
- Almost burning-out
I became the bottleneck for the team and my intent to help actually hindered us.
Unfortunately, the more this happens the more you build a culture of dependence on the Product Manager and it becomes an ever vicious circle. The role of a Product Manager is to facilitate a team of a passionate and skilled specialist, not to control them.
I want to explore the Product Manager Bottleneck and give some tips for breaking the cycle.
Visualising the Bottleneck
In the example below, I imagine a generic agile team. This team has a mix of disciplines all contributing their specialist knowledge.
Situation 1 (Left) — A Client-Web Engineer wants to implement the correct tracking concept for a new feature. In the diagram on the left, the Web Engineer asks the PM about a tracking concept to be implemented, the PM then approaches the Product Analyst 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. It takes 6 interactions for the Web Engineer to get their answer.
Situation 2 (Right, Above) — In comparison, in the example on the right, the Web Engineer directly approaches the Analyst who explains the situation. They then align with the iOS Developer to get their answer. Note how many fewer interactions (red arrows) need to happen and how much quicker that situation resolves.
This example is extremely simplified. Normally, teams are working on several topics in parallel so let’s take this example and add another couple of topics (green and blue).
You see the number of interactions rapidly increases and these are all dependent on the Product Manager. Now we easily see the drag the Product Manager bottleneck has on the flow of information.
Imagine how many unread Slack messages this PM has, how many blockers are raised by the teams at the stand-up, and how many context switches the Product Manager has to make. It’s certainly not conducive to shipping value fast.
The Impact of the Bottle Neck
At the start of the article, I outlined the impact this has:
- Slows the pace of delivery
- Undermines the autonomy of the team
- Burns out the Product Manager
Slows the pace of delivery
This happens for two main reasons. The first is reasonably straight-forward — every interaction, even if done immediately, takes additional time. You need to factor in the communication and delays in replying. These small delays add up very quickly. These delays are times of no value, where, in the example above, team members are waiting for the direction from the Product Manager.
The second reason is that it takes more interactions to complete a task. Look back at the diagram at the start of the article and notice the number of additional arrows. The valuable interactions are only really the ones between the developers and the analysis — the Product Manager is simply (slow) overhead.
Undermine the autonomy of the team
Online you’ll find numerous articles that set the Product Manager up as the umbrella (or more crudely, the ‘s*** shield’) of the team. The logic says the Product Manager should take on this role to let the team focus on the problems. Unfortunately, I’ve seen this translate to Product Managers wrapping the rest of the team in bubble-wrap and siloing them (and silos are bad for any knowledge organisation).
The value behind autonomous teams is more than just having the disciplines (iOS, Backend etc) in the team — it is about having a group of individuals with the capability to solve real customer and business problems. This extends beyond their skills in Swift or PHP, but also the diversity of perspectives they bring to the team. The silo has the effect of restricting the team’s context reducing their ability to meaningly contribute.
The Product Manager can provide direction or advice but does not need to be involved in every conversation. Trust that your team is made up of clever people that can work together to solve problems.
Ultimately, you’re going to become so overwhelmed by simply directing and managing conversations you’re going to feel exhausted. You’ll be spending more time acting as unnecessary overhead. You won’t be able to spend time understanding the real problems of your customers and how your business can solve them.
This overhead adds a massive amount of context switching which destroys your productivity. That weight will build up and it can be very difficult to recover from it. Last year, Rian van der Merwe wrote a fantastic article on the dangerous rise of the “crazy-busy” Product Manager and the bottleneck contributes to that.
Your value as a Product Manager comes from acting as a knowledge facilitator, not a knowledge controller. You don’t need to solve every problem. You need to create an environment where your team can.
Tips for taking a step back
- Give context — To really empower your team and make them autonomous, you need to share a higher-level of context. Be transparent about business opportunities and customer frustrations and even political dynamics that exist in your organisation. This transparency builds trust and understanding. Tip: Using Teresa Torres’s Opportunity Solution Tree is a great way to help build a bigger picture as it maps the relationship between overall outcomes and the pieces of work you're doing.
- Direct to the source of truth —Any time you’re asked a question, think if you’re the best person to answer it. If you don’t know the answer and would need to answer someone else sand the original requester to that person. Even better…
- Keep it transparent — Communication should default to open. If people ask you ad-hoc questions in private or direct messages, copy the question over to your team’s public channel, tag the person that started the thread, and tag the people you think can answer the question best. You’ll find the conversation will continue without your involvement (and you can jump in if you need to or review later).
- Delegate — If there is a particular topic that one of your team knows more about, let them lead on it. This can be anything from interfacing with an API from a team you engineer used to be a part of or making it clear that all tracking related questions go to the team's analyst first. This has a double benefit of empowering the specialists and reducing your workload.
- Democratise Documentation — A wise man once said, “an undocumented agreement is a disagreement”. Here are 7 tips you can share with your team to improve your team’s documentation culture.
- Facilitate — Looking more broadly at your organisation — bringing the team into conversations with your peers in other departments can strengthen their knowledge of the business and the challenges you’re trying to solve together. Involving them early will give them the same context from the start. Once people have your context you can start removing yourself from meetings and only attend the ones you need to.
- Know when to *be* involved — the article has focused on understanding when you don’t need to be involved. The flip side of this is knowing when you should be involved. Key, directional decisions or with particular stakeholders will still need your guidance. Checkout Diagram 4 in this article for more thoughts leadership involvement in decision making.(Thanks to Jonathan Yeap for this great point!)
Trust that your team is made up of clever people that can work together to solve the problems. Share knowledge and responsibility and you’ll find your velocity increases, your team feels empowered, and your mental wellbeing improves.
If you enjoyed this article, you may also enjoy these pieces:
- 6 Diagrams I use to explain Product Management (👏 my most popular article of 2019)
- Creating your Personal Product Philosophy exploring how to codify your approach to Product Management and how you define your role
- How helpful to be as a Product Manager brings some of my learnings about managing my own time and helping others in the Product Management role.