The ideas here draw on Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.
Both books start from the same uncomfortable observation: your team ships a lot, and very little of it matters. Melissa Perri named that condition the build trap in 2018. Eight years later, AI has made building so cheap that the trap no longer requires effort to fall into. You can wander in by accident on a Tuesday afternoon.
So which book actually gets you out? I wrote one of them, so read this with that in mind. I will try to be fair to Perri's book, which earned its place on nearly every product leader's shelf, and honest about where the two genuinely disagree.
The short version
- Escaping the Build Trap (Melissa Perri, 2018) diagnoses organizations that measure success by what they ship instead of what changes. Its fix is product strategy and an outcome-driven operating model.
- Customer-Led Development (Spencer Shulem, 2026) argues that even outcome-driven teams often lack the critical input: specific, named customers attached to every decision, with loops closed when work ships.
- They agree on the disease. They disagree on where the cure enters the system: from strategy downward, or from customers inward.
Escaping the Build Trap summary, in one paragraph
Perri's argument is that most companies are stuck measuring outputs (features shipped, velocity, release dates) rather than outcomes (the value customers and the business actually receive). She calls this the build trap, and she is clear that it is an organizational problem, not a PM problem. The book walks through a fictional company, Marquetly, to show how the trap forms and how to climb out. Her prescription has four big parts: redefine the product manager role away from order-taker or mini-CEO and toward someone who connects business and customer value; replace feature roadmaps with a strategy that cascades from vision to strategic intents to product initiatives; run work through an experimental, problem-first process she calls the Product Kata; and build a product-led organization whose structure, incentives, and leadership reward learning over shipping. It is a book about operating models, written for people who can change them.
The core ideas to remember
- The build trap: success measured by output instead of outcome.
- The value exchange: customers get value from solving problems; the business gets value back. Features are only a means to that exchange.
- Strategy as a framework, not a plan: leaders set direction and intent; teams decide how to get there. (Perri draws on Stephen Bungay's work on the gaps between plans, actions, and outcomes.)
- The Product Kata: understand the direction, analyze the current state, set the next goal, then experiment toward it.
- Product-led, not sales-led or tech-led: the organization optimizes for outcomes rather than for whoever shouts loudest internally.
Customer-Led Development, in one paragraph
Customer-Led Development starts with a test: name the specific customers behind your last strategic decision. Not a segment, not a persona. Names. If you can't, the book argues, you are customer-influenced at best, no matter what your mission statement says. Its diagnosis is that customer truth degrades as it passes through departments (sales interprets, product reinterprets, engineering builds its understanding, marketing positions the result), and that outcome language can hide this as easily as output language can. The prescription is three interlocking systems: the Customer-Led Organization (CLO) for how decisions get made, Customer-Led Development (CLD) for how things get built, and Customer-Led Growth (CLG) for how you expand through customers. The forcing function is attribution: every feature carries customer names before development starts, and those customers hear back when it ships. The book's added urgency is AI. When anything can be built, the scarce resource is knowing what to build, for whom.
The core ideas to remember
- Influenced vs. led: having customer input somewhere in the process is not the same as customers driving the process.
- Departments as filters: every handoff adds interpretation, and every interpretation adds error.
- The CLO constitution: unfiltered customer voice, decisions traced to customer names, success defined as customer success, truth flowing horizontally, and feedback loops measured in hours rather than months.
- The unified brain: one shared source of customer truth, so teams argue about the same facts instead of competing interpretations.
- Closed loops: shipping isn't the finish line. Telling the customers who asked is.
Side by side
| Escaping the Build Trap (2018) | Customer-Led Development (2026) | |
|---|---|---|
| Diagnosis | Orgs reward outputs over outcomes; strategy is missing or misread as a plan | Customer truth is filtered, unattributed, and never closed out; outcomes drift from real customers |
| Prescription | Product strategy, the Product Kata, a redefined PM role, a product-led operating model | Three systems (CLO, CLD, CLG); name customers on every decision; close every loop |
| Primary reader | Product leaders, execs, and PMs in organizations undergoing transformation | Founders, product and engineering teams, and anyone shipping fast with AI |
| Unit of work | The outcome: a strategic intent or product initiative tied to a measurable change | The named customer need: a feature with specific customers attached and a loop to close |
| Key question | What outcome are we driving, and how do we know? | Which customers, by name, is this for, and will they hear from us when it ships? |
| Direction of travel | Top-down: vision to intents to initiatives to experiments | Inside-out: customer signal straight to decision-makers |
| Failure it prevents | The feature factory with no strategy | The outcome-driven team optimizing a metric no real customer recognizes |
| Failure it risks if misapplied | Strategy decks that never touch an actual customer | Chasing the loudest accounts without strategic judgment |
Where they agree
The overlap is bigger than the difference, and it's worth stating plainly because it's the part both books would want you to act on Monday.
- Velocity is not success. Perri spends a book on this. CLD's third principle says the same: velocity doesn't matter if nobody uses what you ship.
- The PM is not a waiter. Taking orders from sales or stakeholders and passing them to engineering is the failure mode in both books. Perri attacks it through role design; CLD attacks it by removing the relay entirely.
- Roadmaps shouldn't be feature promises. Both treat the roadmap as a communication tool tied to reasons, not a list of deliverables with dates.
- Learning beats guessing. Perri's Product Kata and CLD's validate-before-building step are cousins. Both insist you understand the problem before committing to a solution.
- It's an organizational problem. Neither book lets you blame one bad PM. The trap is built into incentives, structure, and how information moves.
The cost of getting this wrong is not abstract. Pendo's 2019 Feature Adoption Report found that 80% of features in the average software product are rarely or never used, and estimated that waste at up to $8.4 million a year for a $50M company. That's the build trap with a price tag.
Where they differ
1. Where the cure enters the system
Perri's model is fundamentally a strategy cascade. Leadership sets a vision and a small number of strategic intents; product initiatives translate those into problems; teams experiment toward outcomes. Customers appear throughout, but the architecture flows from the top. (Paraphrased.)
CLD flips the entry point. The architecture flows from customer signal toward decisions, and strategy is the judgment you apply to that signal, not a substitute for it. If a strategic intent can't be tied back to customers you can name, CLD treats that as a warning sign, not a detail.
Rule of thumb: if your strategy can be written without mentioning a single customer by name, it's a hypothesis, not a strategy.
2. The unit of work
This is the sharpest difference. Perri's unit is the outcome: reduce churn in a segment, increase activation, grow a market. Outcomes are a huge improvement over features. But outcomes are aggregates, and aggregates can drift. A team can move an activation number while the customers who actually pay for the product wonder why nobody fixed the thing they asked about three quarters ago.
CLD's unit is smaller and more stubborn: a specific need, attached to specific customers, with a loop that has to close. It's harder to fake. You either have names or you don't. You either told Acme Corp the thing shipped or you didn't.
3. The sales-led objection
Here's where a careful reader of Perri will push back. Her book explicitly warns against sales-led organizations, where whoever closed the biggest deal dictates the roadmap. (Paraphrased.) Isn't "customer-led" just sales-led with better branding?
No, and the distinction matters. In CLD, sales is one of the filters the system is designed to remove. A sales-led company builds what sales says a prospect wants. A customer-led company sees what the customer actually said, alongside every other customer, and weighs it: How many asked? Which accounts? What did they say in their own words? CLD's examples weigh requests by count and by account importance, and route strategic calls through customer councils. The loudest voice is still one voice.
Perri and CLD are on the same side against sales-led roadmaps. They just disagree on the remedy. Perri adds strategy above the requests. CLD adds visibility and attribution underneath them.
4. What counts as evidence
Perri asks you to define success metrics and run experiments. CLD agrees, then adds a second evidence standard: attribution. Can you find the exact quotes that led to this decision? The gap between those two standards is where a lot of teams live. A McKinsey survey of more than 500 senior executives found that 63% named customer feedback as a top source of growth ideas, but only 15% said they consistently use customer input in their decisions. Plenty of companies value customers in principle. Very few can show the trail.
Why AI-built software deepens the build trap
When Perri wrote her book, building was expensive. That expense was a kind of accidental discipline: if a feature cost a team a quarter, someone eventually asked whether it was worth it.
AI removes that brake. A prototype takes an afternoon. A feature takes a sprint, sometimes a day. That changes the build trap in three ways:
- The trap gets cheaper to enter. When output is nearly free, output metrics inflate. Shipped-features dashboards look fantastic right up until retention doesn't move.
- The trap gets harder to see. Expensive mistakes are memorable. Cheap ones pile up silently as surface area: more settings, more edge cases, more things to maintain that nobody asked for.
- The bottleneck moves. If engineering capacity is no longer the constraint, the constraint becomes knowing what to build and for whom. That's precisely the input CLD is built around.
There's a subtler risk too. AI can summarize thousands of feedback items into a tidy theme. Useful, but it can also become one more filter in the telephone game. CLD's answer is that synthesis is fine as long as the raw signal stays accessible and the names stay attached. A theme without names is an interpretation. A theme with names is evidence.
Rule of thumb: the cheaper it is to build, the more expensive it is to not know who you're building for.
Intuit offers a useful pre-AI illustration of the cost of not listening. In its early years, employees would wait in computer stores, ask Quicken buyers if they could follow them home, and watch the installation, treating every stumble as Intuit's fault. Later, surveys showed many customers using Quicken to keep their company's books. Scott Cook said Intuit ignored that signal for four years. When it finally built QuickBooks, Cook said in 2014 that the business became 11 times larger than Quicken (Inc.). The signal was there, attached to real customers. The delay was organizational. AI wouldn't have fixed that. It just would have made it easier to ship a dozen other things in the meantime.
Which to read first, by situation
| Your situation | Read first | Why |
|---|---|---|
| Your org has no product strategy; the roadmap is a stakeholder wish list | Escaping the Build Trap | You need the strategy cascade and a redefined PM role before attribution will stick |
| You're a leader running a product transformation at a larger company | Escaping the Build Trap | Perri wrote for exactly this reader, and the Marquetly case maps to transformation work |
| You have OKRs and outcomes, but customers still feel unheard | Customer-Led Development | Your outcomes may have drifted away from named customers; the five-decisions test will show you |
| You're shipping fast with AI and feature count is outpacing adoption | Customer-Led Development | It addresses the bottleneck that moved: what to build, for whom |
| Sales, product, and support tell different stories about the same customer | Customer-Led Development | The departments-as-filters and unified-brain ideas target this directly |
| You're a founder at under 50 people | Customer-Led Development | You can still name every customer; build the habit before scale makes it hard |
| You're a new PM learning the craft | Escaping the Build Trap | It's the clearest explanation of what the PM role should and shouldn't be |
A quick self-diagnostic: pick your last five major decisions. For each, can you name the customers who drove it, find their actual words, and point to a plan to tell them when it's done? If you struggle to articulate why any of those decisions mattered, start with Perri. If you can explain the why but not the who, start with CLD.
A reading stack for escaping the build trap
- Customer-Led Development by Spencer Shulem (2026). Names, attribution, and closed loops as the operating system for product decisions, written for the AI era.
Disclosure: I wrote this one. - Escaping the Build Trap by Melissa Perri (2018). The defining book on outputs vs. outcomes, product strategy, and the product-led organization.
- The Mom Test by Rob Fitzpatrick (2013). How to talk to customers so they give you facts instead of polite lies. Makes the names you collect worth something.
- Continuous Discovery Habits by Teresa Torres (2021). A practical weekly cadence for customer interviews and opportunity mapping.
FAQ
What is the build trap?
The build trap, a term popularized by Melissa Perri, describes organizations that measure success by outputs (features shipped, deadlines hit) rather than outcomes (value delivered to customers and the business). Teams get busier while results stay flat.
What is the main takeaway of Escaping the Build Trap?
Stop treating features as the goal. Build a product strategy that sets direction without dictating solutions, empower product managers to find problems worth solving, experiment toward measurable outcomes, and reshape the organization so it rewards learning over shipping.
Is Customer-Led Development a rebuttal to Melissa Perri's book?
No. It accepts her diagnosis and adds an input it argues is often missing: specific, named customers attached to every decision, plus closed loops when work ships. It's closer to a sequel for teams that already think in outcomes.
Isn't customer-led the same as building whatever customers ask for?
No. Customer-led means customer signal reaches decision-makers unfiltered and every decision is attributable. Requests are still weighed by volume, account importance, and strategic fit. Building whatever the loudest customer wants is the sales-led trap both books warn against.
Does AI make Escaping the Build Trap outdated?
Not outdated, but more urgent. Perri's warning about valuing outputs matters more when outputs are nearly free. What AI changes is the bottleneck: when building is cheap, knowing exactly which customers you're building for becomes the scarce skill.
If you want the full system for turning named customers and closed loops into how your team decides, it's all in Customer-Led Development.
And if ideas like "the cheaper it is to build, the more it costs to not know who it's for" are your kind of thing, subscribe to the Context Limit newsletter for more of them.