The build trap is specific, recognisable, and almost universal. An organisation conflates activity with progress. Features shipped become the measure of success. Roadmaps fill with requests from salespeople, executives, and customers - each one reasonable in isolation, collectively incoherent. Teams get faster at delivering outputs that produce no meaningful outcomes. And leadership, unable to explain why growth has stalled despite all the shipping, demands more features, faster.
Melissa Perri's Escaping the Build Trap is the clearest diagnosis of this condition in print, and the most practical guide to treating it. It does not assume a greenfield organisation or a product-native leadership team. It starts from where most organisations actually are - embedded in process, accountable to commitments already made, managing stakeholders whose mental model of product development is fundamentally output-oriented - and maps a realistic path out.
Most organisations that describe themselves as "customer-centric" are measuring the wrong things and rewarding the wrong behaviour. They track features delivered, velocity points completed, and on-time release rates - none of which tells them whether the product is actually getting better at solving customer problems.
This is not a product management problem. It is a leadership problem. The metrics an organisation measures are a direct reflection of what its leaders believe good looks like. If those metrics are output metrics, the organisation will optimise for output - regardless of what the strategy documents say.
Escaping the Build Trap provides the vocabulary, the frameworks, and the practical steps for leaders who want to close the gap between the organisation they have and the one they need.
In an output-oriented organisation, success is defined as shipping. The PM who delivers everything on the roadmap on time is celebrated. The PM who stops work because customer research suggests they are solving the wrong problem is questioned. And so the organisation learns - through its incentives - that building is the goal.
The escape route is not simply saying "we care about outcomes." It is redesigning every signal in the system - how teams are evaluated, how success is communicated to stakeholders, how roadmaps are structured, how PMs are hired and promoted - to reflect a genuine commitment to outcomes. Words without system redesign produce compliance without change.
Perri defines product strategy as the force that connects the company's overall business objectives to the specific bets the product organisation makes. Without it, product teams make locally sensible decisions that are globally incoherent. Features get built that satisfy individual stakeholders but collectively produce a product without a clear direction.
A genuine product strategy answers: where are we going, why is that the right direction, and how does the work of this team connect to that destination? In its absence, roadmaps become shopping lists. The problem is not the teams - it is the absence of the strategic scaffolding that allows teams to make decisions aligned with organisational intent.
Borrowing from Toyota's improvement kata, Perri introduces the product kata as a discipline of structured experimentation. Teams identify a current state, define a desired outcome, understand the obstacles, identify the next experiment, run it, and learn. Then repeat.
The power of the kata framing is that it normalises iteration without framing it as failure. The assumption is not that you will get it right the first time. The assumption is that you will learn your way to right - and that the discipline of the process is what makes learning systematic rather than accidental.
This is not a methodology. It is a habit of mind. And like all habits, it requires consistent practice, leadership modelling, and resistance to the pressure to skip the learning in favour of more shipping.
One of the book's most direct challenges is aimed at product managers who have become expert backlog managers - prioritising, grooming, and communicating requirements - but have never developed deep fluency in the business metrics their product is accountable for affecting.
Perri's argument is that a product manager who cannot fluently discuss revenue, retention, activation, and unit economics is not yet doing product management. They are doing feature curation. And feature curation, however competent, cannot produce the outcome-oriented decisions that genuine product strategy requires.
The book's final and most important argument is structural: even the most capable product managers cannot practice outcome-oriented product thinking in an organisation whose leaders reward output. The build trap is a leadership problem, and escaping it requires leadership change.
This means leaders resisting the urge to prescribe solutions in the request they send to product teams. It means tolerating the discomfort of teams working on problems rather than delivering against requirements. It means measuring success differently - and explaining to the organisation why the measurement has changed. None of this is easy, and none of it happens without visible, sustained commitment from the people with the authority to shape how the organisation operates.
If your roadmap is a list of features with delivery dates, it is a project plan. A product strategy would look very different. Which one does your organisation actually have?
The most dangerous person in a product organisation is not the bad PM. It is the excellent PM who is excellent at delivering the wrong things - because they make the build trap invisible.
Customer requests are data points, not requirements. The customer tells you what they want. Your job is to understand why, and whether solving that why in the way they described is actually the best use of your investment.
Velocity is a capacity measure, not a value measure. A team that ships twelve story points of features nobody uses is not performing better than one that ships four points of something transformative.
The question "did we ship it?" is always answerable. The question "did it work?" is harder, requires more time, and is the only one that matters. Which question does your organisation actually close the loop on?
Audit your last five shipped features against their stated outcomes. Did the feature produce the behaviour change or business result that justified building it? If you cannot answer this question, your definition of done is incomplete.
Rewrite one roadmap item as an outcome goal. Take a feature currently described as "build X" and reframe it as "achieve Y behaviour change, evidenced by Z metric." Notice what additional questions this raises about whether X is actually the right solution.
Interview your PMs about the business metrics they own. Can they articulate how their product decisions affect revenue, retention, and activation? If not, this is a development priority - not an intelligence issue, but a system design issue.
Identify the single most powerful output metric in your organisation and find its outcome equivalent. If the metric is "features shipped per quarter," the outcome equivalent might be "problems solved per quarter, as evidenced by adoption and retention data." Present both to leadership and start a conversation about which one the organisation should be measuring.
Trace one stakeholder request back through to a real customer problem. Not the stakeholder's interpretation of the problem - the actual observed customer behaviour that the request is intended to address. Then ask whether the requested feature is the best solution to that problem.
"The goal of product management is not to ship features. It is to change behaviour - in your customers and in your business metrics. Everything else is means, not ends."
- Melissa Perri