Escaping the Build Trap

The problem it names

Most companies do not set out to build things nobody uses. They drift there. A big customer asks for something, sales promises it, a release date is set, and the team ships. Everyone is busy and the numbers that get reported go up: features, releases, velocity. Melissa Perri calls the result the build trap, and the book is about how a business gets out of it.

The useful part is where she puts the blame. Her example company has inexperienced product managers, but she tells its CEO the deeper trouble is how the company is set up. If you recognise a team that is working hard and getting nowhere, the diagnosis here is worth having.

What changes after you read it

You start asking a different question about every piece of work: what outcome is this meant to produce, and how will we know? That one question changes how you read a roadmap, a sales request or a quarterly plan. A feature that cannot name an outcome becomes a guess, and you treat it as one.

You also stop thinking of strategy as a document. In the book it is a framework for making decisions. That is more useful on a Tuesday afternoon than a vision statement on the wall.

Why it matters beyond product teams

The book is written for product people, but the trap is not limited to them. Any business that rewards activity over results ends up here. Sales teams selling roadmap promises, yearly budgets that punish a team for spending less and bonuses tied to a delivery list all push the same way. The chapters on rewards, budgeting and safety and learning apply to an owner running a small company as much as to a VP of product.

If you run a business, read the part on how organisations get stuck and ask where your own incentives point.

The decision side of it

Perri keeps returning to the same habit: separate what you know from what you assume, then test the assumption before you build. That maps well to logging decisions. A decision with a stated goal, a stated assumption and a check at the end can be reviewed later. A decision that was just a feature request cannot.

The Product Kata is also the kind of routine you can write down as a playbook. I'd try the same six questions on a pricing change or a campaign, though the book itself applies them to product work.

When to read it, and when not to

Read it when growth has slowed while the team is shipping more than ever, when you are about to hire your first product people, or when strategy has turned into a yearly feature list. It is also a good read before you introduce goals across a company.

Skip it if you run a one-person business. It is written around software companies with several product teams, a chief product officer and a product operations team, so a small owner will take the ideas but not the structure.

Escaping the Build Trap argues that companies fail when they confuse output with value. Perri says a company can keep shipping and still produce little a customer wants, and that the fix is not better product managers alone. It is a company set up around outcomes: strategy that guides decisions, teams that learn before they build, and rewards that pay for results. The book walks through this with a made-up but realistic company called Marquetly, an online training company for marketers that keeps pushing out features while the product managers it hired struggle.

The Value Exchange System

Customers have problems, wants and needs. A company makes products and services to meet them. Value is only realised when the customer's problem is solved, and only then does something come back to the business: money, data, knowledge or promotion. Perri says companies slip into the build trap when they cannot measure that and pick an easy proxy, which is the number of features delivered. One data platform she worked with had 30 features, and customers used only 2% of them consistently, yet more were still in development.

Projects Versus Products Versus Services

A project has a scope, a deadline and an end. A product delivers value repeatedly without new work each time. A service uses people to deliver value. Many companies work only in projects, so each has its own measures but no strategy above it. She says companies in the build trap often mistake project management frameworks such as PRINCE2 for product management.

The Product-Led Organization

Here Perri lists the other ways a company can be led: by sales, by a visionary or by technology. Sales-led companies let contracts set the roadmap. That can be fine for a startup landing its first big client. Visionary-led companies depend on one person. Technology-led companies build clever things with no buyers. A product-led company lets the success of its products drive growth, and it has to change roles, strategy, process and the organisation itself to get there.

What We Know and What We Don't

Before any project, she sorts the situation into four boxes: known knowns, known unknowns, unknown knowns and unknown unknowns. Facts get treated as facts. Assumptions become questions to test. Gut feeling is listened to but checked, because that is where bias lives. The job of product management is to investigate the known unknowns and shrink the area around the unknown unknowns.

Bad Product Manager Archetypes and A Great Product Manager

Part II describes the archetypes of bad product managers: the Mini-CEO, the Waiter and the Former Project Manager. The Waiter is an order taker who turns stakeholder requests into a list of items to build. A good product manager is responsible for the why, while a project manager owns the when. The role carries no authority over people, so influence matters. Chapter 8 then sets out a career path and the shift from tactical to strategic work as people grow.

Organizing Your Teams

Companies tend to group teams by value stream, by feature or by technical component. At Marquetly the teams sat over technical components, so one product owner kept making work for an API that was already stable, because that was what her team owned. Perri's point is that ownership by area creates work for its own sake.

What Is Strategy? and Strategic Gaps

Part III opens with a CTO who asked for a specification of everything to build over three months and called it a strategy. As Perri puts it, a good strategy is "a framework that helps you make decisions". She then borrows Stephen Bungay's three gaps between outcomes, plans and actions: knowledge, alignment and effects. Demanding more detailed information does not close the knowledge gap, and more detailed instruction does not close the alignment gap. Each level should define how it will meet the intent of the level above.

Creating a Good Strategic Framework

Marquetly's new chief product officer, Jen, asks product managers why they are working on their projects and hears answers that do not connect to the company's goals. Perri introduces a structure that runs from company vision to strategic intents, product initiatives and options. She shows how Spotify treats initiatives as bets informed by data, insights and beliefs, and how strategy deployment tells stories on different time scales at each level.

Company-Level Vision and Strategic Intents, and Product Vision and Portfolio

The company vision sets direction for everything below it, and strategic intents are the business outcomes it wants. Product initiatives turn those into customer problems, and options are the possible solutions. Her Netflix example is a subscriber who wants to watch anywhere, with anyone, comfortably, which led to several routes onto devices.

The Product Kata

This is the core process. Perri builds on the Improvement Kata used at Toyota, which Mike Rother documented, and asks six questions in turn. What is the goal? Where are we now? What is the biggest obstacle? How do we try to solve it? What do we expect to happen? What happened, and what did we learn? Repeating it builds a habit, like a martial arts kata, and the question "what do you need to learn next?" keeps the team learning.

Understanding the Direction and Setting Success Metrics

Marquetly's product leaders put numbers on their goal. Retention after six months was 40%, and users said they wanted more course variety. From those figures they estimate the revenue at stake and set targets for retention and acquisition. The initiative gets a number, and the team can measure progress against it.

Problem Exploration and Solution Exploration

Over 75% of teachers who start a course never publish it, so one team studies why. User research shows the course portal is poor, but a bigger problem turns up: teachers spend long hours editing video. The team then runs a small experiment, doing the video editing for a few teachers, and learns that teachers also need guidance on making good course videos. Each round shows the next obstacle.

Building and Optimizing Your Solution

Two small experiments raise the publish rate from 25% to 75%. Licences for every teacher would cost too much, and building the software would take over a year, so the team proposes buying the Budapest company behind the tool. Perri also covers prioritising work once a solution is proven.

Outcome-Focused Communication

Perri describes three recurring meetings: quarterly business reviews on strategic intents and financial outcomes, product initiative reviews, and monthly release reviews. The release review shows only what is certain to ship, and teams can share roadmaps so that marketing, sales and executives know what is coming.

Rewards and Incentives, Safety and Learning, Budgeting, and Customer Centricity

Part V covers the systems around the teams. A scorecard of items to deliver leads product leaders to build anything that ticks the box before the year ends. Teams need safety to try things, and Perri says it is not a success if you fail and do not learn. Yearly budgets punish teams that find a cheaper route or decide not to build, so she suggests funding the way a venture capitalist does, stage by stage. Customer centricity means going to see customers work, as John Deere's teams do on a working farm. The book then returns to Marquetly and ends with an afterword.

What to do with it

• Pick one piece of work in progress and write down the outcome it should produce and how you would measure it.
• Check your goals. If an objective reads like a delivery date, rewrite it as a result for a customer or the business.
• Run the six Product Kata questions on your next problem, and write down what you expect to happen before you try anything.
• Review how people are rewarded and budgeted. If either pays for shipping, change it before you change the process.
• Use the six questions in the appendix on your own company, starting with who came up with the last feature or product idea you built.