Escaping the Build Trap by Melissa Perri, published by O’Reilly Media in 2018, is a book about a common failure in product companies: measuring success by how much gets shipped instead of what changes for customers. Perri is a product management consultant and teacher who founded Produx Labs and the online school Product Institute. She calls this failure the build trap and explains how product teams and their leaders can get out of it.
What is Escaping the Build Trap about?
Perri argues that companies fall into the build trap when they treat features as the goal. Teams celebrate releases, executives ask for dates and nobody checks whether the work moved customer behaviour or company results. The cure is to shift attention from outputs (features, releases) to outcomes (customers solving problems, which in turn produces business results) and to organise the company around that value exchange between customers and business.
The book follows a fictional company, Marquetly, as it struggles with the problem and slowly changes. Through that story, Perri covers four areas. First, the role of the product manager, whom she describes as neither a mini-CEO nor a waiter taking orders but someone who connects customer problems with business aims. Second, strategy, which she treats as a system for decisions that flows from company vision to team-level goals, with clear options at each level. Third, the product management process, including her version of the improvement kata: understand the direction, analyse the current state, set the next target condition and experiment towards it. Fourth, the organisation: how leadership, incentives, budgets and product operations must change so teams can focus on outcomes.
The writing is plain and practical, with checklists, diagrams and stories from Perri’s consulting work in both startups and large companies.
What are the main lessons for founders?
- Measure outcomes. Swap your release count for a number that shows customer behaviour changing, such as active usage, conversion or retention.
- Define the product manager role clearly. Give product managers authority over the problem and the outcome, and expect them to connect customers, data and business goals.
- Make strategy a chain. Company goals should lead to product goals, which lead to team experiments. Each team should be able to explain how its work links upward.
- Treat the plan as a set of bets. Present upcoming work as themes and problems with expected results, and update them as you learn.
- Reward learning. If bonuses, praise and promotions follow shipped features, teams will keep shipping features. Change the incentives first.
Who should read Escaping the Build Trap?
It suits founders whose startups have grown past the first product team, product managers in scale-ups and leaders in larger companies trying to fix a feature factory. Board members and investors who want to ask better product questions will also benefit. The fictional company makes the ideas easy to share with non-product colleagues.
Very early solo founders can skip it for now. The problems it describes appear once a company has several teams, managers and a backlog of requests from sales and leadership.
How do you put Escaping the Build Trap to work this week?
- List everything your team shipped last quarter and write, next to each item, the outcome it changed. Mark the ones where you do not know.
- Pick one company goal and write the chain beneath it: product goal, team goal and the next experiment.
- Replace one feature request on your plan with a problem statement and a target result, and let the team propose solutions.
The free Startups and Teams module in the Fe/male Switch Startup School helps founders set up roles and responsibilities as the company grows.
Where does Escaping the Build Trap fall short?
The book is aimed at companies large enough to have product managers, layers of strategy and budget cycles, so small startups will find much of it ahead of their stage. The fictional company makes the story easy to follow, yet it also simplifies the politics of real change. It gives less detail on discovery techniques and experiment design than other product books. Pair it with Inspired for the day-to-day work of product teams and Measure What Matters for setting the goals that outcomes roll up into.