A summary of “Escaping the build trap” by Melissa Perri

Whenever people asked me which book I would recommend to them for entering Product Management, I always immediately told them to first read “Inspired” by Marty Cagan, also known for being the founder of the SVPG. However, after reading “Escaping the build trap: How Effective Product Management Creates Real Value” by Melissa Perri, I might have to reconsider my choice, since it’s a noteworthy alternative.

I hope my summary convinces you to read the book!

What’s the build trap?

According to Melissa, it’s “when organizations measure their success by outputs rather than outcomes!”. They focus on shipping features, instead of the value of these features.

In short, her book tells the story of how you get from delivering to achieving while leveraging a reference story of a company called Marketly as well as concepts like the value exchange system.
The latter is a concept that describes the relationship between customers and businesses that is used to structure the book and to connect related topics.

My simplified version of the value exchange system

In this system, product teams create products/services to fulfill the needs of their customers and to create value for them while solving their problems. In exchange, the customers pay money that creates value for the business. The main difficulty with it is how to measure and define value on the customer side.

According to Melissa, it’s the job of the business (i.e., Product Manager) to understand their customer’s problems, wants, and needs to act and create value based on emerging opportunities. Melissa stresses that this value will not be created and provided by simply shipping features or by copying the ones of your competitors but by figuring out what makes you valuable and sets you apart.

To make the topics covered in the book more tangible, Melissa uses an exemplifying story of an online education platform called Marketly that became a Product-led company by moving from being output-focused to outcome-focused.

But why Product-led? Because Product-led companies know that the success of products is primarily driven by growth and learning as opposed to other forms (Sales-led, Visionary-Led, Technology-Led) where shipping features (aka output) is the main concern.

Product Management with respect to growing and learning simply helps by “exploring the known unknowns” and “reducing the universe of unknown unknowns”, since everyone can build products based on “known knowns”, but these often don’t add value. Ok, but what are “known unknowns” or “unknown unknowns”? In the book they are described as:

• Known knowns are facts, in “feature speak” these are the “basic” or “must-have” features everyone has. So replicating them won’t drive people to use your product.
• Known unknowns are questions that a Product Manager asks to advance, he or she uses experiments to make them known and knowns
• Unknown knowns are intuition, “this could be it” moments that are based on experience, however, which also have to be checked by experiments
• Unknown unknowns are discoveries, moments of surprise that you discover by talking to your customers

The role of the Product Manager

After introducing the concept of the build trap and explaining the terms, the first chapter defines the role of the Product Manager. To Melissa “a Product Manager overlaps business and tech to translate needs into products”. A Product Manager understands the customer and the business, while also considering markets, technologies, and data when synthesizing the why. According to the book “its role in the organization is to work with a team to create the right product that balances meeting business needs with solving user problems”.

The bad Product Manager (PM)

To more clearly shape what a Product Manager is, Melissa provides archetypes of bad PMs:

• The mini CEO: believe their main purpose is to rule and command. They are solution-focused and often do not involve the team. They don’t explore, they dictate, which is why they aren’t liked by the team and why the team doesn’t contribute as much.
• The waiter: only routes through the request of the stakeholders. He or she usually has no goals and no vision to prioritize, which is why they often struggle when faced with trade-off decisions. They feel helpless and can’t push back.
• The Project Manager: tend to focus on answering when things are finished but not why to build them in the first place and what it solves.

The good Product Manager

In contrast to this, Melissa also states what to her makes a great PM:

• Starts with the vision and knows their users, processes, and pain points
• Focuses on the why and the problem
• Aligns business goals with that
• Keeps asking whether the feature will get the business closer to these goals
• Doesn’t take orders and involves the team during exploration and research
• Pulls the data to know what drives Key Performance Indicators
• Follows up on findings
• Runs experiments
• works backward to determine what can be in version 1.0 and iterates
• Asks what success looks like and has metrics for measuring it

Product Manager career paths

To explain the responsibilities of the different career levels (PM, SPM, Direction, VP of Product, CPO), Melissa first divides the work of a Product Manager into:

• Tactical work: features, short term, crunch data, shape work
• Operational work: tie things together, alignment of teams and roadmaps
• Strategic work: market positioning, strategic intent, and goals

My main takeaway of the chapter is that when getting up the ladder, the type of work shifts away from tactical work to more and more operational and strategic work.

Organizing your teams

This section describes how to organize teams, where Melissa explains the two concepts of coverage and flexibility.

Coverage means having teamwork on dedicated parts of a product, which has the advantage of such teams more easily identifying themselves with these parts.

The disadvantage of this is that “output focus” more easily sneaks in when the product matures and creating value becomes harder.

Flexibility, on the other hand, occurs with new and temporary teams, think of squads or feature teams, which according to Melissa are more flexible and outcome-oriented per definition.

Melissa concludes that a good way of balancing these two concepts is to ask your customers the question of how they get value out of your product and then organize around the identified “value stream”. This way it keeps value creation and strategy together.

Product Strategy

Melissa defines strategy as “not a plan but a framework that helps to make decisions!”. According to her, strategy “connects vision to economic outcomes”, product portfolio to initiatives, and solution options to the teams.

According to her, Strategy is created and deployed at each level and across the company.

Her view is based on the “The art of action”, a book by Stephen Bungay, who defines strategy as: “a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context.”

To introduce you to strategy frameworks, Netflix, and their launch of the Roku is provided as an example. It demonstrates how having a strategic framework in place enabled Netflix to make a last-minute shift to enable Netflix on the Xbox instead of launching the Roku, an internally developed internet-enabled device.

Melissa argues that the shift was only possible because Netflix focused on a solid vision and organized its key initiatives around key outcomes.

This made them realize to shift to the Xbox since it will have a faster time to market and a broader reach. This was only possible because they connected and aligned their vision down to the teams and the team’s chosen solution options allowed the Product Managers to not think feature level but to zoom out to the intended key outcomes.

Strategy gaps and how they relate to the build trap

Next, Melissa illuminates how strategy gaps, discovered by Stephen Bungay, explain why companies that try to fill these gaps often fail.

• Knowledge gap (btw. outcomes and plans): the difference between what we would like to know and what we know. A sign of this is when leadership tries to aid their uncertainty by asking for more and more information. Melissa suggests providing this certainty, by having and making a plan of how you going to reach the vision. If you don’t have one, then Melissa encourages you to overcome this by simply asking yourself what’s missing to have one? While this gap is often perceived as a lack of trust, Melissa points out that it’s rooted in missing alignment.
• Alignment gap (btw. plans and action): the difference between what leadership wants you to do and what you do. A sign of this is when team effort can’t be connected to your company effort, or when PMs provide different answers to what their goals are than their leaders. To aid this gap, leadership provides more and more instructions and passes down feature requests. Instead, they should provide goals and give the freedom to explore solutions to problems to reach these goals. Melissa claims that in such environments, where experimentation and validation fall short, the wrong stuff is built! True alignment happens when the upper levels own the why (direction), while the lower levels own the how (solution).
• Effect gap — between actions and outcomes is when planned outcomes are not equal to the actual results. A sign of this is when leaders exercise more and more control since they don’t see the results they were hoping for. The opposite should be the case, leadership should provide the freedom to Product Managers to learn and adjust their actions.

To avoid all these gaps, the chapter’s conclusion is to make use of autonomous teams. The main argument for them is that they simply scale, while command and control structures, with lots of management levels in between, don’t.
In this respect, Melissa emphasizes that the reason for hiring smart people is to give them the room to grow the company and to build products that people love. She concludes that whenever people, teams, and levels are aligned, you don’t need much management oversight and you don’t have to fill strategic gaps.

A good strategy framework

To Melissa, there is a difference between strategy creation and strategy deployment.

Strategy creation, as explained in the book, is “finding problems and organizing around them at every level, while solving them”. For instance, Spotify uses its DIBB (Data, Insights, Believes, and Bets) framework, which is an example of a strategy creation framework. Melissa points out that calling it “bets” makes it easier to shift the mind from outputs to outcomes since it sets expectations. For this to work, Spotify built an environment for experimentation and innovation, where it’s safe to fail and easy to course correct. Important to know is that at each level in your organization, where you deploy a strategy, you have different meeting cadences, which according to Melissa, is often the root cause of the trouble. In this respect, one piece of advice she gives is to sufficiently constrain teams in their time horizon, for them not to get stuck and helpless. Another is to properly link the different cadences. For this, she provides the following common

• Executives think long-term cycles, like 2–5 years
• Leadership/Management think in 1–2 years.
• Product Managers think in months and quarters.
• Teams think in weeks.

Conversely, a good strategy deployment framework example is Objectives and Key Results (OKRs), initially used at Intel and later made popular at Google. A strategy deployment framework has the premise of setting direction at each level to act while linking and aligning the previously mentioned levels and cadences. The book lists the following common levels:

• Vision sets where the company is going (long-term)
• Strategic intend challenges what has to be solved to reach the vision.
• Product initiatives: problems that come along with challenges
• Options: ways the problems can be addressed (i.e., features)

Mission and vision

E.g., Amazon has the following company…

• Mission: Our mission is to be Earth’s most customer-centric company
• Vision: where customers can find and discover anything they might want to buy online, and endeavors to offer its customers the lowest possible prices.

To Melissa, the main purpose of a company’s mission is to justify its existence, while a company vision, should provide a long-term focus and a direction on where to go and how to achieve the company mission.
The company vision should also tell what value the company brings to its customers. The difficulty with this is to connect the company vision to the operational work.
Conversely, a product vision ties together all the value of the product and answers why you built it in the first place. It should describe the problems of your users and how it enables them to solve them. While not being too specific, it ideally emerges through experimentation and around solving the problems of the user.

Strategic Intend

A strategic intend asks what’s the most important thing that we can do to reach the company vision. An organization should ideally only define a few strategic intends (1–3, depending on the size) and they should be high-level, long-term, and stable. For these reasons, they usually fall into one of the following buckets:

Examples of strategic intends:

• Expand into new markets by increasing revenue from x to y
• Increase annually user growth from x to y
• lead the streaming market

Product initiative

A product initiative translates goals into problems the user can solve. It answers how we can reach the strategic intent. One strategic intent can be linked to multiple such product initiatives, while the problems they describe should be backed by numbers.

Following the first example of a strategic intend, the following example lists the connected challenges of acquiring new users to grow revenue, while translating the goal into a solvable problem.

Alternatively, one could also grow or better retain existing users to tackle the same strategic intend (i.e., the challenge of growing revenue).

Examples for product initiatives:

• We believe, that by having more targeted and solution-oriented marketing measures for the new market, we can increase revenue by 1.5M€
• We believe, that by increasing more relevant content on our site, we can acquire new users and increase revenue by 2M€
• We believe, by better proving the value of our services, we can increase revenue by 1M€

At this level, you should ask questions to find the root cause of your identified problems. E.g., Why are people not signing up for your product? Or why are people leaving? Pull data and ask your customers for feedback that will answer your questions.

Options

Options are your bets or experiments that try to find the right solution to the problems identified in your product initiatives.

Examples for options:

• New solution-oriented sales play for existing capabilities
• Easier and faster ways for customers to find your solution offerings
• Build feedback loops for customers on areas of interest in the new market
• Outreach to new customers with the new sales plays for the solution

The Product KATA

The “Product KATA” is “a process to uncover the right solution from a problem-solving standpoint”. It “uncovers the right thing to build” and helps to form the habits to do so. As stated in the book, it’s an adapted version of the Toyota KATA, a PDCA cycle tailored to Product Management. The following is a slightly adapted version of this:

My simplified Product Kata

1. Understand the strategic intent to get to possible product initiatives. This means breaking down strategic intends, such as “increase revenue by x%”, by translating their underlying goals to solvable problems (i.e., product initiatives), such as “we believe by increasing the amount of content we can increase revenue by y%,
2. Evaluate the current state of the strategic intent and find out how the product can help with it. This means pulling the necessary data and analyzing it thoroughly. Ask a question such as “What’s our current retention rate”, or “How many people are leaving because they don’t find relevant solutions?”.
3. Determine what problems you can solve to reach the defined strategic intend. Think of options for how to solve the identified problems. Refine your option statements by breaking down how they can be measured and how they get you closer to the product initiative’s goal. Melissa suggests setting short-term team goals for this, which then act as leading indicators for whether you are reaching your product initiative’s goal. Examples of a related option would be “by increasing content, we can increase acquisition by y% and retention by”.
4. Product process: In step four we deeply go through the following exploration and optimization questions to explore and validate the problem and find the right solution.

• What’s the goal?
• Where are we now concerning the goal?
• How do I try to solve that problem?
• What is the biggest problem/obstacle standing in the way?
• What do I expect to happen (hypothesis)?
• What actually happened, and what did we learn

Step 1 to 3 is to understand and set the possible direction. Important for this is to have metrics at all levels to connect the production activities in the production process (step 4) to the desired business outcomes. Metric framework examples in the book are AARRR and HEART.

When using metrics, a good tip in the book is to make use of “mutually destructive metric pairs”. That means not relying on one metric only but challenging it with another.

Another tip is to use leading indicators on one level for lagging indicators on a higher level. E.g., measure user happiness and engagement to anticipate changes in retention.

The Product Management process

This process tries to “find solutions to real problems” and figures out which of them can be solved to grow the business. During that, its job also is to facilitate the experimental mindset to “fall in love with the problem” and not the solution.

Melissa promotes that the process teaches you to iterate until you reach the desired outcome and not just ship version 1.0. Or according to the “The Lean Startup”, to get stuck in the “build” phase of the build, measure, and learn cycle. The steps are:

1. Problem Exploration
2. Solution Exploration
3. Solution Optimization

First, explore the problem, where the main responsibility of a Product Manager is to talk to your users and to find their true problems. Melissa again stresses the magic of asking further and further questions, which is demonstrated by the following example.
In the first round of questioning Marketly discovered that the (originally perceived) problem was their course creation workflow that was badly designed and lacked features. Redesigning this workflow would take months!
In the second round of questioning, they found out that teachers are primarily missing expertise to upload videos, the true problem. The solution to this could be as simple as providing a written guide on how to shoot videos to the teachers, which could be done on a weekend and requires no engineers. To find such true problems the book suggests primarily using user research techniques that map the pain points on the user's journey.

After the true problem is found, the team should experiment with solutions and validate that they solve the problem. To Melissa this step is all about gathering rapid feedback from your users, so as to not waste time and money. Here, the primary focus should be on learning. Methods that can be used here that are listed in the book are:

• Concierge: where background processes are fully manual and potentially could not be scaled but are executed like this to prove value. E.g. Zappos send their first shoes, by buying them from shoe stores after an order was created.
• Wizard of Oz: feels real, while parts could be manual or fake.
• Concept testing: showing concepts and gathering generative feedback

Yet, Melissa states that when your solution is certain you should not conduct experiments since the main purpose of them is to reduce risks and decrease uncertainty.

To get to version 1.0 and since not all experiments scale, we often need to optimize by using techniques that ensure we all understand, align, and prioritize the work to be done. Melissa introduces story mapping and north start documents as helpful techniques.

To prioritize from a strategic point of view, Melissa recommends using “qualitative cost of delay”, a method introduced by Ozlem Yuze and Joshua J. Arnold, which essentially asks what to ship sooner and describes the impact of time on the outcomes you want to achieve. At this point, you should make sure that the success of your solution can be measured after each release. For this, the book suggests adding your goals to your definition of done.

In the end, Melissa simplifies the Product Process to:

• set the direction
• diagnose the problems and find the real obstacles
• experiment to find the right solution

Or put briefly, built with intent!

Product led organizations

In the last chapter of the book, Melissa talks about how to get to a product-led organization and how to scale them, which to her “is a culture that organizes around outcomes”.

Here, I just briefly list my main takeaways from the different sections.

Outcome-focused communication is all about having an outcome-oriented mindset and how to go from shipping to being a customer-centric organization.

• Requires patients from leadership, since outcomes take time to emerge.
• Have standardized roadmaps to more easily align throughout teams
• Have the right meeting cadence on all levels
• A roadmap is a living and changing thing, not updated only annually or quarterly.
• The book “Roadmap relaunched” says roadmaps should contain: themes, hypotheses, goals, success metrics, the stage of development (Alpha/Beta/GA), and important milestones.
• Use the stage of development on the roadmap to be in sync with your sales department and to not overpromise/oversell and then underdeliver
• Install a product operations unit in your organization to aid scale problems such as alignment of roadmaps, capacity, goals, and outcomes, automation of data collection, reporting, and standardization of Product Management in general.

In Rewards & incentives, Melissa encourages adjusting compensation to the outcome-oriented mindset and gives guidance on how to implement it from the bottom-up. Mainly by defining success criteria and measuring them with proper metrics.

Section Safety and Learning shows the importance of having a learning and experimenting culture.

• The main argument for this is to reduce risk.
• The biggest risk is to build a product without knowing it’s the right thing
• Leaders should set boundaries, in which people can safely conduct these experiments and at worst fail safely, inexpensively, and ideally fast.

Melissa closes the book with a small section on budgeting where she motivates people to break free from artificial annual cycles and encourages them to instead take product decisions with a more venture capital-like mindset. Seeing every new idea as an investment decision.

Conclusions

I really enjoyed Melissa’s book, since it didn’t just provide you with blunt definitions but also concrete and easy-to-follow examples, taken from her experience at “Marketly” and from other big players like Netflix and Spotify.

The part I believe could need some improvements is the chapter around the Product KATA. I can’t pinpoint it without going over it again but to me, the concepts and steps explained felt not perfectly lining up.

Feel free to leave me a comment about whether you like it and read the book, since no summary can give you the full experience of this well-written piece!

Looking for more on Product Management?

Check out my curated list to find other great resources that I’ve come across and that I usually recommend to others.