5-Minute Tools for Product Leaders: Managing Growth Bottlenecks

As product leaders we often need to discover and prioritize between opportunities to create growth, ranging from feature development through marketing initiatives to organizational developments. Thinking in bottlenecks is a powerful mental tool that can facilitate decision making in both situations.

About Bottlenecks

In the previous article, Managing Bottlenecks Using the PERT Chart, we briefly introduced the concept that a bottleneck is the single most important element that constrains a system, like the neck of a bottle limits the amount of water that flows through. And as Eliyahu M. Goldratt argues in his book The Goal: A Process of Ongoing Improvement, the ability to consistently identify and lift bottlenecks is a fundamental management competence.

What makes bottlenecks especially impactful is that they block or delay every step that follows them - no matter how well other elements perform, as long as the bottleneck persists, steps that depend on it cannot create more value. For example, if the list page of an e-commerce site breaks down, neither the subsequent product pages and the purchase funnel will create any value, as the user who would navigate through each needs to stop at the list page and has no option to proceed.

Taking a truly cross-functional perspective, a bottleneck can be virtually anything:

• a list page breaking down and preventing traffic to flow through product pages,
• a product gap compared to a competitor causing users to switch,
• knowledge that is missing in the organization to identify product gaps compared to competitors,
• an outdated internal policy that describes how UI design should adhere to brand guidelines and preventing applying flexible design practices,
• an internal policy accounting for a unit as cost center instead of profit center, preventing receiving additional investments to fund growth.

In reality we have a varying degree of oversight and influence over cross-functional bottlenecks, but we can always apply a conscious mindset of thinking in what is the next most fundamental bottleneck within our range of oversight and influence. The mindset is not product leadership specific, but can also be applied to it. Below I will share 3 examples of how I have used it for decision making, with the objective to create growth.

The Conversion Stairway

While leading product developments across multiple markets in an online travel marketplace model, one of my challenges to understand was that the same UI enhancement may achieve great results on one market and have no impact on another one.

The most convenient answer could have been that markets are just different. But, after having tried specifically localized initiatives and used the marketplace as personally a traveler on different markets, I felt the answer needed to be something else. Over time, I developed the hypothesis that the marketplace was in different stages in different markets, and therefore the next most important growth opportunities were also different in different markets. So, I drafted a model that could help decision making. With a bit of a 2024 visual uplift and some fun Miro stickers, today it would look like this:

This model states that, given that a good UI is already in place, the marketplace should proceed through the following stages to reach the objective of conversion increase:

1. a wide-enough range inventory should be on the marketplace,
2. the inventory should have attractive-enough prices,
3. a high-enough number of reviews, including textual reviews should establish trust,
4. a fast-enough platform should enable instant response experience, including on mobile,
5. and then an even better UI could contribute to conversion increase again.

One parallel element, the brand could positively impact all of the stages.

This model described the key bottlenecks and the order to lift them, in order to unblock the impact of further UI improvements. It also helped explain that I should not expect conversion increase from further UI improvements in markets where the preliminary conditions were not met. Once I could formulate these series of bottlenecks to lift, it helped me form hypotheses on why certain initiatives were working in certain markets, and to argue in strategic decision making on where to put focus next in each market.

Content Creation or Branding Uplift?

Following a 2014 launch an e-commerce blog in Romania that successfully accumulated 1 million sessions (article in Hungarian here), we were looking to roll out the blog to the Hungarian market, with the goal to also gain organic traffic. The Hungarian market was in a more mature state of brand awareness, therefore the branding considerations of the blog were also more important.

This raised the question whether we should enhance the brand perception of the blog first by branching out a separate template for the market, or just roll out the existing template from Romania and go ahead with content creation. As usual, the development pipeline was full, so it was not just a question of prioritization for the blog itself, but for the overall portfolio.

We could argue that we had already achieved success in Romania for accumulating organic traffic, so we should go ahead with the content creation and not wait for a template update. In the next few years, as the blog started accumulating content, organic traffic also started to accumulate. We managed to identify correctly that the next most important bottleneck was content creation, not the brand experience, allowing for faster growth. And ultimately, the witnessed growth justified the cost of adding a localized template a few years later.

Bottleneck Maps for Organizational and Tech Stack Developments

While leading a development department covering backend, frontend, UX, PM/PO and IT functions, there were considerable organizational and technological development opportunities to uncover and prioritize.

For annual organizational development plans I usually made a GANTT chart displaying the selected initiatives. This was a useful method for planning and tracking up to a 1-year horizon, and until it could roughly fit a PowerPoint slide. However, as the company was growing and it came to planning 3 years level organizational visions, including potentially more fundamental improvements as well to achieve a regional level operation, I started having a problem with maintaining oversight and tracking dependencies in a single place. This was when it came in handy to start tracking the opportunities in a single chart, by:

• Starting to write down opportunities whenever I encountered them - we talked about it during planning, someone mentioned occasionally in a meeting, I read something in an article.
• Populating the opportunities into a single flowchart, and started arranging them into dependencies. The dependencies started formulating as I put them into a single map and started arranging them.
• Keeping it practical. The point was to help decision making, not to make it perfect. By finding the right balance between the level of granularity to include, it indeed helped reduce cognitive load by mapping the steps out and having them in a single place to just open up and refer to.

While I won’t include a big chart here for simplicity, we can take a look at how this could look like for example for introducing a new framework into a part of the product. The chart below illustrates that:

• we would experiment with multiple frameworks at first,
• then decide on the applied framework,
• then recruit 2 specialists and train the team internally in parallel,
• then start writing new code in the framework,
• then in the future refactor previous code as decided on an ongoing basis.

We can expand the logic of creating this map to multiple domains and longer-term horizons, and then ultimately end up with a nice big chart to map what and how we want to improve some main organizational and technological questions in the upcoming years. Of course the level of granularity needs to change as the map gets bigger in order to stay comprehensible. The above example illustrates one particular example with a lower level granularity for the purpose of the article.

How to Identify and Lift Bottlenecks

Bottlenecks are always specific to the context you are working in and the objective you are working towards. Thus, there is no silver bullet to identify bottlenecks, but more of a combination of attitude and tools. My advice would be:

1. Do the field work to understand context - understanding, listening, talking to people, observing, reading and processing feedback.
2. Look at the domain cross-functionally, possibly working with a cross-functional team to identify the path that could lead to your objective.
3. Use particularly the mindset of 5 Whys, digging into a problem until you think you have actually reached the fundamental cause.
4. Once you have uncovered possible steps, see if you can establish order of dependencies between them, either just by thinking or creating models like above. Asking what-if questions can facilitate thinking in dependencies, like “What if we executed B without A? What if we execute them together? Would it make sense to do all the other options if we didn’t execute A first?”.

It is important to assess as cross-functionally as possible because, as mentioned above, a bottleneck can be pretty out of the box, like a feature, a bug, a policy or a gap in the inventory.

There are also some more advanced tools to help identify bottlenecks in the Theory of Constraints, and a lot of related tools are mentioned in this Asana article. From the thinking tools of the Theory of Constraints I used the Current Reality Tree and the Future Reality Tree for understanding a project situation, and the Evaporating Cloud for helping to illustrate a conflict in organizational development. Taking an example for the Evaporating Cloud, we could use it to illustrate the underlying conflict I am facing while writing this article:

The chart illustrates that in order to achieve my objective, I have an underlying conflict in prerequisites that has no obvious solution - wanting to write a long and short article at the same time is not possible, and is actually a bottleneck to reaching my objective to write a valuable LinkedIn article. Thus, I either have to iterate on my objective, or find a solution to remove the conflict between my two prerequisites - otherwise I won't be able to reach the objective I am working towards.

Both The Goal and the Asana article above also details that once you identified the next most important bottleneck, the next step is to decide on how to lift it, and then have a focused effort to lift that bottleneck - bring together a team, stop other projects to allow focus, reallocate funding, whichever can be necessary to lift that next bottleneck. In the blog example above, saying no to the template upgrade project allowed focus on content creation faster.

And then, once the bottleneck is lifted, go on to look for the next one, and repeat the process - thus, lifting bottlenecks can ultimately become a process of continuous improvement. Personally, I use it less frequently in my work, more on that in the closing section.

Related Product Specific Tools

As mentioned above, managing bottlenecks in not a product specific mindset. I am adding three tools that I consider related to add some further value in product leadership context.

There are two frameworks that describe subsequent steps towards achieving conversion and growth, each from a different perspective. AARRR stands for acquisition, activation, retention, referral and revenue, and describes stages to achieve product-led growth. You can read about it more in this article by Amplitude. AIDA stands for Attention, Interest, Desire and Action, and describes the steps to convert a lead into a customer. You can read about it more in this article by Hubspot.

A powerful tool to set impactful objectives that can guide thinking in bottlenecks towards achieving them is to identify "magic numbers". I would also call these certain growth-triggering points in the customer experience, constellations of factors that signal an order of magnitude jump in conversion probability.

• Airbnb had determined in its early growth stage that 300 listings, with 100 reviewed listings, was the magic number to see growth take off in a market.
• Facebook used a similar metric in its early days for achieving 7 friends in 10 days.
• Slack identified 2,000 messages of a team as the magic number for long-term engagement.

It can be argued that for such magic numbers it is not the precise is number that is the most important, but finding the right focus points and branding it as a a North Star metric. This can help in governing the efforts towards lifting bottlenecks throughout the organization towards that objective. I used a more simple, similar approach to forming an MVP hypothesis for what level and geographical coverage of inventory to achieve before launching a new marketplace product.

On a related note, if you are more interested in growth strategy, I recommend to check the Advanced Growth Strategy program of Reforge. It takes the concept of funnel-based growth models a step further, and describes a mindset of turning them into self-reinforcing growth loops.

How to Get Started

Thinking in bottlenecks has helped make me better decisions to create growth, reduce cognitive load and expand my strategic horizon. In the longer run I have developed more of a habit that when I feel I am in a more complex situation with multiple possible steps to take, or I feel I need to create structure towards a strategic vision, I take a bottleneck perspective to the situation and see if thinking through in this mindset can help me make the right decision. This also means that I don’t apply it on a daily basis, more when I feel it adds significant value to think more deeply about the next steps.

If the article has sparked your interest to explore further, my recommendation to get started is to:

• Check out The Goal: A Process of Ongoing Improvement - it is written in a very enjoyable novel-style, and used to be one of the three books to read for the senior management of Amazon.
• Experiment with the mindset, starting small, as you best see fit.
• If you are further interested, also check out The Critical Chain for applications in project management, and The Phoenix Project and The DevOps Handbook for applications in software development.
• Give me feedback on how it worked - that would be the goal, and I’m curious!

This article has been the second part of a series with the goal to help product leaders grow, by describing practical tools I have found useful throughout my career. The articles will aim to find a sweet spot between being short enough to read in 5 minutes and long enough to inspire to try, explore further or initiate discussions on them. I hope you liked it, stay tuned for the next one!