Escaping the Build Trap

The Value Exchange System

Every company sits inside a value exchange. Customers carry real problems, wants, and needs. A business builds something to resolve them, and if it genuinely works, value flows back: money, loyalty, data, referrals, growth. The loop only holds up in one direction, once the thing built actually resolves the problem on the other side.

Two kinds of value, one loop

"Customer value" means a real problem got solved for a real person, well enough that they'd choose to pay for it, keep using it, or recommend it. "Business value" is what the company gets back once that happens: revenue, retention, brand strength, market position. The build trap is treating output, a feature shipped, as if it were value on its own, when value only exists once the loop actually closes on both ends.

A subscription product makes this concrete. A customer keeps paying every month not because features exist, but because the product keeps solving a problem well enough to justify the renewal. The moment it stops solving that problem, the exchange breaks, and churn is the customer formally ending the deal.

• A feature that ships but nobody uses closes no loop; it is cost without value.
• A feature nobody explicitly asked for can still close the loop by accident, but that is luck, not process.
• The only reliable way to know a loop closed is to measure what actually changed for the customer and the business, not to count what got built.

For a PM, this reframes the real question behind every roadmap item from "can we build this" to "will this close the loop." A sprint that ships ten stories and moves no customer or business metric has not created value yet, no matter how busy the team looked doing it.

Constraints on the Value Exchange System

The value exchange never runs in a vacuum. Three forces constrain what "good value" can even mean for a given company at a given moment, and a PM who ignores them will design solutions that are technically correct and practically unworkable.

The three constraints

• Organizational communities: internal stakeholders, other teams, and existing commitments all shape what solutions are realistic to propose, whether or not they're the theoretically best answer.
• Competitors: what rivals already offer sets a customer's baseline expectation, so a solution has to clear that bar, not just solve the problem in isolation.
• Legal and regulatory forces: industries like healthcare and finance operate inside rules that limit which solutions are even legal to ship, regardless of customer or business appeal.

None of these constraints excuse skipping the value exchange; they shape which solutions are viable inside it. A healthcare PM solving the exact same customer problem as a consumer-app PM will land on a very different solution, not because the underlying problem differs, but because the constraint set around it does.

The PM-specific lesson here is that "good product sense" is contextual, not universal. Copying a tactic wholesale from a case study at a different kind of company, or a different regulatory environment, often fails for reasons that have nothing to do with execution quality. Understanding your own organization's real constraints before proposing a solution is part of the job, not a distraction from it.

Projects Versus Products Versus Services

A project has a defined start, a defined end, and a fixed scope; once it ships, the team typically disbands or moves to the next assignment. A product has no natural end date. It's a living, ongoing relationship between a business and a customer that keeps evolving as the problem, the market, and the technology change. A service sits in between, human-delivered value that can scale into a product once patterns repeat enough to systematize.

Why the difference matters

Companies stuck in the build trap manage products like projects: define scope, staff a team, ship it, measure "done" by whether it shipped on time and on budget, then reassign the team. That structure has no mechanism for asking whether the shipped thing actually worked, because the team measuring "done" has already moved on to the next assignment by the time real usage data comes in.

A product mindset keeps a durable team owning an area over time, so the same people who shipped a feature are still around, still accountable, when the usage data comes back. That accountability loop is what makes learning and iteration possible in the first place; a project-based team structurally can't learn from its own output because it's gone before the lesson arrives.

For a PM, this chapter is a diagnostic: look at how your own team is staffed and measured. If success is defined as "delivered on the date committed," that's project management wearing a product manager's title, and the fix isn't better prioritization, it's a different organizational structure entirely.

The Product-Led Organization

Companies tend to fall into one of four organizational patterns, and each one determines where roadmap decisions actually come from, regardless of what any individual PM believes good process should look like.

The four types

• Sales-led: the roadmap is set by whichever deal needs a custom feature to close. This works at small scale, but breaks down past roughly fifty to a hundred customers, once no single account can represent what the broader market actually needs.
• Visionary-led: the roadmap is set by one person's taste and judgment, the way Apple ran under Steve Jobs. It can be extraordinarily effective while that person is present, but it depends entirely on one person's bandwidth and doesn't survive succession well.
• Technology-led: the roadmap is set by whatever's newest and most technically interesting to build. It produces impressive engineering with no guarantee anyone actually wants it, because "can we build this" quietly replaces "should we build this."
• Product-led: the roadmap is set by validated business outcomes, tested against real customers, prioritized against strategy, not against whichever voice in the room is loudest that quarter.

Why product-led is the target, not just one more option

The first three patterns aren't failures of effort or talent; sales-led and technology-led companies can genuinely thrive early on. The problem is that none of the first three scale past a certain size, because each depends on a single narrow signal, one deal, one person, one technology, standing in for the whole market's actual needs. Product-led organizations build the muscle to keep validating outcomes as the company grows past what any single signal can represent.

The PM-specific lesson is diagnostic before it's tactical: a PM trying to introduce product-led practices into a sales-led org by copying a product-led company's process, without first naming what type of org they're actually in, is solving the wrong problem. The fix has to match the pattern.

What We Know and What We Don't

Most companies genuinely believe they know their customers, their market, and why past decisions succeeded or failed. Much of that confidence is unearned. Teams often can't actually articulate the evidence behind a belief they treat as settled fact, because the belief was never validated in the first place, just repeated until it hardened into "common knowledge."

Separating fact from assumption

• What we know: validated through direct customer research, real usage data, or a tested experiment with a clear result.
• What we assume: inherited from a past decision-maker's intuition, an old market read that's never been revisited, or a competitor's move that got copied without understanding why it worked for them.

The build trap thrives on this confusion, because assumptions dressed as facts get built against directly, skipping the validation step that would have caught a bad bet before engineering time was spent on it. A team that "knows" its users want a feature, when that knowledge is actually three-year-old anecdote from one sales call, is one unvalidated assumption away from a wasted quarter.

This chapter functions as a bridge into Part II: an organization can't fix its process for deciding what to build until it's honest about how much of its current roadmap rests on assumption rather than evidence. For a PM, the practical habit is a simple gut-check before defending any roadmap item: can you name the actual evidence, not just the belief, and would that evidence hold up if a skeptical colleague asked to see it directly?

Bad Product Manager Archetypes

Before defining what a good PM does, it helps to name the failure modes clearly enough to recognize them in the mirror, not just in a colleague.

The archetypes

• The Mini-CEO: treats the PM title as a grant of authority to dictate what gets built, alienating engineering and design instead of collaborating with them. The "CEO of the product" framing, however well-intentioned, encourages exactly this behavior.
• The Waiter: takes stakeholder requests and converts them directly into backlog items with no validation in between, effectively running an order-taking service rather than a product function.
• The Former Project Manager: manages the "when" of delivery, timelines, status updates, sprint velocity, while never actually owning the "why" of value. The team ships on schedule and still might have built the wrong thing.

Each archetype is a coping mechanism for the same underlying problem: nobody clearly defined what the job actually is, so the PM defaults to whichever adjacent role feels most familiar, whether that's an executive, a customer-service function, or a delivery manager.

Applying it to your own team

A useful gut-check: track a week of a PM's actual meetings and decisions. If most of them are about defending a delivery date, converting requests into tickets, or issuing directives without team input, that PM has drifted into one of these archetypes regardless of their stated job description, and the fix is a role reset, not more training on frameworks.

A Great Product Manager

A great PM's core job is holding the intersection of business viability, customer desirability, and technical feasibility, and constantly checking that whatever the team is about to build genuinely satisfies all three, not just the one that's easiest to validate.

What the role actually requires

• Deep understanding of the business's goals and how a given initiative connects to them, not just familiarity with the feature backlog.
• Direct, ongoing exposure to customers, not secondhand requirements passed through a stakeholder or a sales rep.
• Enough technical fluency to have a real conversation with engineering about tradeoffs, without needing to be an engineer themselves.
• A bias toward evidence over opinion, including their own opinion, when the two conflict.

What a great PM is not

The role isn't an idea generator whose job is pitching features, and it isn't a project coordinator whose job is keeping a schedule current. It's closer to a general manager of a specific slice of the business: accountable for outcomes in that area, empowered to say no to ideas that don't serve the strategy, and expected to defend decisions with evidence rather than authority.

The habit that separates a great PM from an order-taker isn't a personality trait, it's a repeatable discipline: before greenlighting any initiative, be able to state the customer problem, the evidence it's real, and the metric that will prove the solution worked, in that order, every time. A PM who can't produce all three on demand for their current top roadmap item hasn't actually validated it yet, no matter how confident the team feels about it.

The Product Manager Career Path

Most companies never actually design a PM career ladder; they borrow engineering's ladder and relabel the titles, which quietly imports assumptions that don't fit the role. A "Senior PM" promoted the way a senior engineer is promoted, based on individual output and technical depth, ends up optimized for the wrong thing.

A ladder built around scope of ownership, not seniority theater

• Associate PM: learning the fundamentals under close mentorship, typically owning a narrow feature area.
• Product Manager: owns a full product area's outcomes independently, from strategy through delivery.
• Senior Product Manager: owns a more complex or higher-stakes area, and increasingly mentors other PMs.
• Group Product Manager or Director: manages a team of PMs across a portfolio, translating company strategy into product strategy for that group.
• VP of Product: owns the overall product strategy and the org design of the product function itself.

The distinguishing axis at each level isn't years of experience, it's the size and ambiguity of the outcome someone is trusted to own without close supervision.

A poorly designed ladder produces exactly the archetypes from Chapter 6: PMs get promoted for shipping volume because that's the only thing the ladder actually measures, which rewards output-chasing at the moment a company most needs outcome-focused judgment from its senior people.

For a PM evaluating their own growth, or a lead designing a ladder for their team, the concrete test is whether promotion criteria reference validated outcomes and decision quality, or whether they quietly reference velocity and feature count. The second version trains exactly the behavior the whole book argues against.

Organizing Your Teams

How a company draws its team boundaries determines what kind of PM decisions are even possible, independent of anyone's individual skill or intent. A team structured around a technical component, "the search team," "the backend team," can only really answer questions about that component, not about a customer outcome that spans several of them.

Two failure patterns

• Organizing by technical component: teams become internal service providers fulfilling tickets from other teams, with no single owner accountable for whether the underlying customer outcome actually improved.
• Organizing as a project-based "feature factory": a team assembles around a specific initiative, ships it, disbands, and reassembles for the next one, the same accountability gap described back in Chapter 3's projects-versus-products distinction.

The alternative: durable, outcome-owning teams

Perri points to companies like TransferWise, which organized cross-functional teams around outcomes such as retention, new-currency expansion, and acquisition, rather than around a technology layer or a single feature. Each team owns a metric end to end, with the engineering, design, and product skills needed to move it, and stays intact long enough to see whether their bets actually worked.

This connects directly back to Chapter 4: an organization can declare itself product-led on paper, but if its actual team boundaries are drawn around technology or one-off projects, the org chart itself will keep forcing output-based decisions regardless of stated intent.

Before proposing a new process or ritual to fix a team's prioritization problems, check whether the team boundary itself is the actual constraint. A brilliant discovery process bolted onto a team that's structurally organized around a technical component will keep losing to the org chart every time.

What Is Strategy?

Strategy is not a plan, and treating the two as interchangeable is one of the most common ways companies sabotage their own product work. A plan is a fixed sequence of actions decided in advance. Strategy is a decision-making framework, a set of filters that tells a team how to choose its own actions as new information arrives.

A useful test

If a document doesn't change when new information contradicts it, it was never a strategy, it was a plan wearing strategy's name. And if a "strategy" changes every time someone has a new idea with no real evidence behind the change, it isn't a strategy either, it's just noise with a strategic-sounding label attached.

Perri frames good strategy as something that gets deployed downward through an organization, not handed down as a finished document to be executed literally. Each layer, company vision, strategic intents, product initiatives, specific solutions, translates the layer above it into decisions appropriate to that layer's scope, rather than simply passing the exact same instruction further down the chain.

A PM who receives "increase revenue 20 percent" as their strategy has actually received a goal, not a strategy; strategy would explain which customer segment, which problem, and which approach the company believes is the highest-leverage way to get there, leaving the specific solution for the team closest to the evidence to determine.

The practical habit: when a strategy document arrives, check whether it explains a reasoned bet about cause and effect, or whether it's just a target number with no theory behind it. Only the first kind gives a team enough to make good local decisions when circumstances shift.

Strategic Gaps

Most strategy failures aren't failures of the strategy itself, they're failures in how it travels through an organization. Drawing on Stephen Bungay's work on military strategy, Perri names three specific gaps that open up between leadership's intent and what actually happens on the ground.

The knowledge gap

The difference between what leadership needs to know to make a good decision and what the organization actually knows at the top. It opens because information naturally degrades as it moves up through layers of management, each one summarizing and filtering what gets passed along. It closes by pushing real, unfiltered customer and market evidence upward, not by leadership simply asking harder questions of the same filtered reports.

The alignment gap

The difference between what leadership actually wants accomplished and what teams actually do. It opens when leadership hands down a specific solution instead of an intent, because a prescribed solution leaves no room for a team to adapt when local conditions don't match leadership's assumptions. It closes by communicating strategic intent, the outcome and the why, and trusting teams to choose the right local action.

The effects gap

The difference between the results leadership expected from an action and what actually happened. It opens when nobody's tracking outcomes closely enough to notice the gap, or when there's no mechanism to feed that mismatch back into the next decision. It closes by giving teams real autonomy to adjust their approach based on outcome data, rather than management responding to a miss by adding more upfront controls.

A misused framework here looks like adding process to fix a gap that isn't a process problem, more status reports for a knowledge gap that's actually about information quality, more approval steps for an alignment gap that's actually about vague intent. A PM diagnosing a strategy failure should first identify which of the three gaps actually caused it before proposing a fix, since the fix for one gap can worsen another.

Creating a Good Strategic Framework

A strategic framework is the connective tissue between a company's vision and a team's daily work, and building one well means making every layer legible to the layer below it without dictating specifics that only the team closest to the evidence should decide.

The core structure

• Vision: where the company is headed over roughly five years or more, deliberately not specific enough to dictate this quarter's roadmap.
• Strategic intents: the handful of business challenges currently standing between the company and that vision, revisited and updated as conditions change.
• Product initiatives: the specific problems a team takes on to make progress against one strategic intent.
• Options: the actual solutions a team tries, tested and either scaled or killed based on evidence.

Skipping a layer, jumping straight from company vision to a specific feature request, is exactly how strategy collapses into a wish list. Each layer exists specifically to translate ambiguity into something more concrete without prematurely locking in a solution before it's been tested.

A strategy deployed well reads less like a fixed roadmap and more like a living decision tree: leadership owns the top two layers and revisits them on a slower cadence, while teams own the bottom two layers and revisit them constantly as new evidence comes in from problem and solution exploration.

When a request lands on a PM's desk with no visible connection to a strategic intent, the right response isn't to quietly build it or quietly kill it, it's to ask which layer it's supposed to sit at, and to push back if nobody can actually answer that question.

Company-Level Vision and Strategic Intents

A company vision has one real job: describe a compelling future far enough out that it doesn't need to change every quarter, while being concrete enough that it actually rules some things out. Amazon's vision, to be Earth's most customer-centric company, is cited as a model precisely because it's specific enough to disqualify decisions that would sacrifice customer trust for short-term gain, while staying broad enough to survive years of strategic pivots underneath it.

Strategic intents translate vision into current urgency

Strategic intents are the small number of business challenges standing between the company and its vision right now, revisited on a much faster cadence than the vision itself, often annually or even quarterly for a fast-moving company. They're framed as challenges to close, not solutions to build, which is what leaves room for teams below to figure out how.

A cautionary counterexample

Perri references Yahoo's internal "Peanut Butter Manifesto," a memo describing a company spread so thin across incoherent priorities that resources, like peanut butter, were smeared across too many initiatives to make real progress on any of them. It's used as a warning about what happens without disciplined strategic intents: everything becomes a priority, which functionally means nothing is.

• Test a company's stated vision by asking whether it would actually disqualify a real decision the company might otherwise make, or whether it's vague enough to justify anything.
• Test a "strategic intent" by asking whether it names a challenge to close, not a feature to ship; if it already names a solution, it's skipped a layer.

For a PM, the practical use is upward, not just downward: when a team's own initiatives don't map cleanly to any stated strategic intent, that's worth surfacing to leadership as a possible gap in the intents themselves, not just a gap in the team's discipline.

Product Vision and Portfolio

A product vision is the strategic intent layer's translation into a specific product area's future state, answering what this product needs to become to serve its role in the company's broader strategy. It's more concrete than a company vision but still describes a direction, not a fixed feature list.

Portfolio thinking

Larger companies rarely have one product; they have a portfolio, and portfolio-level strategy means deciding how much investment each product area deserves relative to the others, based on its strategic importance and its current maturity, not based on which team shouts loudest in a planning meeting.

Perri contrasts a simpler case, Roku's largely single-product business where product vision and company vision nearly overlap, against a much harder case, a sprawling multi-product organization like Bank of America, where dozens of product lines each need their own vision that still has to roll up coherently into one company strategy.

A common trap at the portfolio level

Treating every product in the portfolio as equally strategic leads to spreading investment evenly across all of them, the same Peanut Butter Manifesto failure from Chapter 13, just applied at the product-portfolio level. Some products deserve aggressive investment because they're core to the current strategic intent; others deserve maintenance-level investment because they're mature, and forcing equal investment into both wastes the scarce resource that actually matters, focused attention.

A PM managing one product in a larger portfolio should be able to state where their product sits in that investment hierarchy, and why, since a maintenance-tier product being resourced and evaluated as if it were a growth bet, or the reverse, is a strategy mismatch that no amount of tactical execution can fix.

The Product Kata

The product kata is the book's central process framework, adapted from Toyota's improvement kata, a management routine originally built for continuous manufacturing improvement and repurposed here for product discovery.

The four steps

• 1. Understand the direction: know the strategic intent or target condition leadership has set, the outcome this work is meant to serve.
• 2. Know your current condition: gather real data and research on where things actually stand today relative to that direction, not where the team assumes they stand.
• 3. Set the next target condition: define one specific, measurable, near-term outcome that would represent genuine progress toward the larger direction.
• 4. Work the gap: use the Product Process, problem exploration, solution exploration, then building and optimizing, to close the distance between the current condition and the target condition.

Once a team hits the target condition, or learns enough to know it needs to be revised, the loop restarts, meaning the kata is a continuous cycle, not a one-time planning exercise a team runs at the start of a quarter and then executes blindly.

How it differs from a roadmap

A traditional roadmap commits to a list of features on a timeline set months in advance, largely regardless of what gets learned along the way. The kata commits to a direction and a near-term target condition, while leaving the actual solution deliberately open until problem and solution exploration have generated real evidence about what will work.

Teams sometimes adopt kata language, "target condition," "current condition," without changing the underlying behavior, effectively renaming their existing roadmap items as target conditions and skipping the actual exploration work the framework depends on. The kata only functions if a team is genuinely willing to change the solution based on what problem exploration reveals, not just relabel a predetermined plan.

Before writing a target condition, a PM should be able to state the evidence for the current condition in specific numbers, not impressions, since a target condition set against a vague sense of "where we are" instead of real data is exactly the assumption-as-fact failure described back in Chapter 5.

Understanding the Direction and Setting Success Metrics

The first real step inside the kata's loop is translating a strategic intent into a metric specific enough that a team can tell, without debate, whether their work moved it. A goal like "improve the user experience" fails this test because reasonable people can disagree endlessly about whether it happened; a goal like "increase seven-day retention from 40 percent to 50 percent" does not.

Choosing the right kind of metric

Perri references established metrics vocabularies as useful starting points rather than rules to follow rigidly: the Pirate Metrics framework, Acquisition, Activation, Retention, Referral, Revenue, for funnel-stage thinking, and HEART, Happiness, Engagement, Adoption, Retention, Task Success, for experience-quality thinking. Neither framework is meant to be applied wholesale; the point is picking whichever metric genuinely represents the outcome this specific initiative is meant to drive.

Choosing a metric that's easy to move but disconnected from real value, a vanity metric like raw signups instead of activated, retained users, produces the illusion of progress inside the kata while the underlying business problem stays unsolved. A metric earns its place in this step only if moving it would represent something leadership would actually recognize as progress toward the strategic intent.

A useful discipline before a kata cycle starts: write the target metric down, then ask whether a skeptical executive, seeing only that number improve, would agree real customer value was created, or whether they'd reasonably ask "so what?" If the honest answer is "so what," the metric needs to change before the team invests a single sprint chasing it.

Problem Exploration

Problem exploration is the step teams skip most often, and skipping it is the single most direct route back into the build trap: jumping straight to a solution before confirming the underlying problem is real, and worth solving, at the scale assumed.

What real problem exploration looks like

• Talk directly to customers who plausibly experience the target condition's gap, not just whichever customer is easiest to reach.
• Look for patterns across multiple conversations rather than treating any single anecdote as proof.
• Frame what's learned as a testable hypothesis about the problem, not yet a proposed solution.
• Size the problem: how many customers actually experience it, and how painful is it relative to other things competing for their attention.

A specific failure mode

Teams frequently conduct interviews that are really validation-seeking rather than discovery: asking customers whether they'd like a feature the team has already decided to build, rather than asking open questions about the underlying problem and letting the answer genuinely surprise them. The former produces confirmation; only the latter produces real learning.

Problem exploration takes real time and produces no visible artifact a stakeholder can see progress against, which makes it an easy target to cut when a team is under delivery pressure, exactly the pressure that the build trap's output-obsessed culture creates in the first place. Cutting it doesn't remove the risk of building the wrong thing, it just moves that risk from before the build, where it's cheap to discover, to after it, where it's expensive.

When a stakeholder pushes to skip straight to a solution, the useful reframe is cost, not process purity: a week of problem exploration is dramatically cheaper than a quarter spent building and later discovering the problem wasn't real, or wasn't the one that actually mattered to customers.

Solution Exploration

Once a problem is validated, solution exploration means generating and testing multiple possible answers before committing real engineering time to any single one, rather than jumping to the first plausible idea and building it directly.

The discipline

• Generate more than one candidate solution, even roughly sketched, before evaluating any of them in depth; a single option compared against nothing isn't really being evaluated.
• Test cheap approximations first: a prototype, a mockup, a landing page, a concierge version done manually, anything that produces real customer signal without full engineering investment.
• Evaluate candidates against the success metric set in Chapter 16, not against internal preference or which idea is more fun to build.
• Be genuinely willing to kill an option that tests poorly, even one a senior stakeholder favors.

Why cheap testing matters more than clever testing

The point of this step isn't finding the theoretically perfect method, it's finding the cheapest test that would meaningfully change the team's confidence in a candidate solution. A rough prototype that reveals customers don't understand the core concept is more valuable at this stage than a polished build that reveals the same thing three months later.

Teams sometimes treat solution exploration as a formality, running one shallow test on a solution they've already emotionally committed to, then treating a lukewarm result as confirmation because they wanted to build it anyway. Genuine solution exploration requires holding candidate solutions loosely enough that a bad test result actually changes the plan.

A practical habit: before greenlighting engineering work on a solution, name the cheapest test that could have proven this specific solution wrong, and check whether that test actually happened, or whether the team just built confidence in it through internal conversation instead of external evidence.

Building and Optimizing Your Solution

Only once a solution has survived exploration does real engineering investment begin, and even then, the kata's loop doesn't end at launch. Building is followed by measuring against the exact success metric defined back at the start of the cycle, then optimizing based on what that measurement actually shows.

Why shipping isn't the finish line

A build-trap organization treats launch as the completion of the work; the team ships, celebrates, and moves to the next roadmap item. A kata-driven team treats launch as the start of the measurement phase: did the target condition metric actually move the amount predicted, and if not, why not.

Optimizing, not just shipping once

Most solutions don't hit their target condition perfectly on the first release. The optimization phase means iterating on the shipped solution based on real usage data, adjusting the specific implementation while staying anchored to the same target metric, rather than declaring victory prematurely or abandoning a fundamentally sound direction after one imperfect first attempt.

Once the target condition is genuinely hit, or the team learns enough to know the target condition itself needs revising, the four-step kata loop from Chapter 15 restarts: a new current condition gets assessed, and a new target condition gets set. This is what makes the process continuous rather than a single project with a beginning and an end, tying directly back to the products-versus-projects distinction from Chapter 3.

The concrete discipline: put a specific date on the calendar, at launch, to review the target metric, not an open-ended "we'll check on it sometime." A metric review that never gets scheduled reliably never gets done, and an unmeasured launch quietly slides back into being treated as pure output.

Outcome-Focused Communication

Part V returns to the product-led organization from Chapter 4, this time asking what has to actually change day to day, not just structurally, for an organization to operate that way in practice. It starts with something as basic as how progress gets communicated upward and across the company.

The habit to break

Status updates in a build-trap culture default to output language: what shipped, how many stories closed, whether the sprint hit its commitment. This language trains everyone listening, including leadership, to keep rewarding activity, which reinforces the exact behavior the rest of the book argues against.

The habit to build instead

Outcome-focused communication reports against the target metric from the kata cycle: what the team learned, what moved, and what didn't, framed around the strategic intent it's meant to serve, not around a list of completed tickets. A status update that says "we tested three solutions to the onboarding drop-off problem, one moved activation by four points, here's what we're doing next" teaches a very different lesson than "we shipped twelve stories this sprint."

Outcome language sometimes has to report a negative result, a metric that didn't move, a hypothesis that failed, which feels riskier to say out loud than "we shipped on time." Perri argues this discomfort is exactly the signal a build-trap culture is still operating underneath the surface, since a genuinely product-led organization treats a validated negative result as real progress, not as a failure to hide.

A concrete test for any status report a PM writes: could a reader tell, from the update alone, whether real customer or business value moved, or only whether work got completed? If only the second is answerable, the update itself is quietly reinforcing the build trap, regardless of how the underlying work was actually done.

Rewards and Incentives

What gets rewarded is what gets repeated, and most companies unintentionally reward the exact output-chasing behavior their leadership claims to want to eliminate, because performance reviews, bonuses, and promotions are still measured against shipped volume rather than validated outcomes.

Where incentives quietly misfire

• Performance reviews that cite feature counts or sprint velocity train PMs to optimize for those numbers directly, regardless of whether the features created value.
• Team-level goals set as delivery deadlines, rather than outcome metrics, make hitting the date the actual success condition, independent of what shipped.
• Public recognition, celebrating launches rather than celebrating validated learning, however small, sends the same signal informally that formal metrics send officially.

Redesigning incentives around outcomes

Aligning rewards with the book's core argument means evaluating a team, and an individual PM, on whether their target condition metric moved, and on the quality of the evidence behind their decisions, rather than on how much they shipped in a given period. This sometimes means rewarding a team that spent a quarter validating that a proposed solution wouldn't work, since killing a bad idea before full investment is real value creation, not a wasted quarter.

Rewarding validated negative results runs directly against most companies' existing instinct to treat "we built X" as the safe, defensible thing to report upward, and "we learned X wouldn't work" as something to downplay. Changing incentive structures without also changing the cultural comfort with negative results tends to produce incentives on paper that nobody actually trusts enough to act on.

A PM in a position to influence how their own team is evaluated should push, concretely, to have at least one outcome metric, not just delivery metrics, written into the team's formal goals, since an unwritten preference for outcomes rarely survives contact with a review cycle still measuring output.

Safety and Learning

A product-led organization depends on teams running real experiments, and real experiments sometimes fail. If failing an experiment carries a genuine career or reputational cost, teams will quietly stop running honest experiments and start running experiments designed to succeed, which defeats the entire point of testing in the first place.

What psychological safety actually enables here

It's not a soft cultural nicety layered on top of the process, it's a load-bearing precondition for problem and solution exploration to work at all. A team that fears reporting a failed test will either hide the result, reframe it dishonestly as a partial success, or stop running genuinely risky tests altogether in favor of safe ones that were unlikely to teach anything new.

Building the practice

• Leadership modeling curiosity about a negative result, asking what was learned, rather than reacting with visible disappointment about a missed target.
• Separating the evaluation of a PM's judgment and process quality from the evaluation of any single experiment's outcome.
• Treating a validated "this doesn't work" as documented progress worth sharing across teams, since it prevents another team from re-running the same failed bet later.

Incentives and safety reinforce or undermine each other. Rewriting formal metrics to value outcomes over output, without also making it genuinely safe to report a metric that didn't move, produces a culture where teams learn to game the new metrics rather than actually pursue honest experimentation, the same failure mode in a new disguise.

When a PM's own experiment produces a negative result, the useful habit is reporting it with the same confidence and detail as a positive one, specific numbers, specific next step, since visibly modeling that behavior does more to build team-level safety than any policy statement could.

Budgeting

Traditional annual budgeting allocates a fixed amount of money to a fixed set of projects at the start of a fiscal year, based on the best guess available at that moment, and then holds teams to that allocation regardless of what gets learned over the following twelve months.

Why this collides with the kata

A team running the kata is supposed to change direction based on evidence discovered through problem and solution exploration; a budget locked a year in advance structurally punishes exactly that flexibility, since redirecting funding mid-year usually requires a lengthy approval process that discourages teams from acting on what they've actually learned.

A more adaptive approach

Perri argues for funding outcomes and teams rather than funding a fixed list of pre-specified projects, closer to how a venture investor stages funding against evidence of progress rather than committing an entire round up front regardless of results. A team keeps its funding as long as it's making credible progress against its target condition, and budget conversations happen on a shorter, more frequent cycle than once a year.

This is one of the hardest changes in the whole book to actually implement, because annual budgeting is often owned by finance functions with their own planning cycles, audit requirements, and incentives that have nothing to do with product strategy, and changing it usually requires buy-in well above any individual PM's authority.

Even without the power to redesign company-wide budgeting, a PM can push for smaller, evidence-gated funding checkpoints inside their own team's existing budget, treating a quarter's allocation as staged against the target condition rather than assuming the full amount is guaranteed regardless of what the data shows partway through.

Customer Centricity

Customer centricity is frequently claimed and rarely practiced with real discipline; most companies that describe themselves as customer-centric mean they collect customer feedback occasionally, not that customer evidence genuinely drives prioritization decisions when it conflicts with an internal preference.

What genuine customer centricity requires

• Direct, recurring exposure to real customers for the people making prioritization decisions, not filtered secondhand through a single customer-facing team.
• A willingness to let customer evidence override a senior stakeholder's strong internal opinion, which is the actual test of whether customer centricity is real or just stated.
• Treating customer research as continuous infrastructure, built into every kata cycle's problem exploration step, rather than an occasional special project run once a year.

A specific failure Perri returns to

Kodak's own researchers identified consumers' desire for digital photo sharing early, well before digital cameras displaced film. The company had the customer insight already in hand; what it lacked was an organizational structure, and a budgeting and decision-making process, capable of acting on that insight quickly. Customer centricity failed not at the research stage but at every stage after it.

Customer centricity depends on everything covered earlier in Part V actually being in place: outcome-focused communication surfaces what customers are telling the org, incentives reward acting on that evidence, safety makes it acceptable to report inconvenient customer findings, and adaptive budgeting makes it possible to actually redirect resources once those findings arrive. Customer centricity without the rest of the organizational redesign is just a value statement with no mechanism behind it.

A concrete self-check: name the last prioritization decision where customer evidence directly overruled a senior stakeholder's preference. If that example doesn't exist, or is hard to recall, that's a more honest signal about the organization's real customer centricity than any values statement on the wall.

Marquetly: The Product-Led Company

The book closes its case study by returning to Marquetly, the fictional-but-realistic e-learning company used as a running example throughout the book, now shown after applying the transformation the earlier chapters describe.

Where Marquetly started

A fast-growing company that had hired hundreds of engineers, then backfilled a twenty-person product organization under one VP, mostly with people who had no real product management background. Teams were structured around technical components, roadmaps were built from a mix of sales requests and executive taste, and success was measured by counting shipped features, the build trap in a fairly typical, unremarkable form.

What actually changed

• Teams were reorganized around outcomes, onboarding activation, course completion, instructor retention, instead of technical components, applying Chapter 9's structure directly.
• Strategy was rewritten as layered intents rather than a fixed feature roadmap, following the framework from Chapters 12 through 14.
• PMs adopted the kata as their operating rhythm, running real problem exploration before committing engineering time, rather than converting stakeholder requests directly into sprints.
• Leadership changed how it asked for updates, requesting outcome data rather than delivery status, which shifted what teams optimized for without a single new policy document.

Marquetly didn't become product-led by hiring better individual PMs or running a training workshop; it became product-led by changing the structures those PMs operated inside, team boundaries, strategy communication, and what got measured and rewarded. The same people, given a different structure, made visibly different decisions.

Marquetly's arc is a caution against blaming individual PM skill for what's actually a structural failure. Before assuming a team needs better PMs, check whether the team's structure, metrics, and incentives would let even a great PM, as defined back in Chapter 7, actually succeed inside them.

Escaping the Build Trap to Become Product-Led

The book's closing chapter treats the transformation to product-led as a real organizational change effort, not a single decision a company makes once and then has permanently, and it names what that change actually costs and where it tends to stall.

Where transformations stall

• Leadership endorses the idea of being product-led in principle, but doesn't change how it evaluates teams in practice, leaving the incentive structures from Chapter 21 untouched underneath a new vocabulary.
• Middle management, evaluated on their own team's shipped output, has a direct incentive to resist any change that makes output a less central metric, even when they agree with the philosophy.
• The change gets treated as a PM-only initiative, training product managers on the kata and strategy frameworks, without touching engineering, design, finance, or leadership's own habits, which leaves the surrounding structure fighting the new behavior.

What sustained change actually requires

• Genuine leadership commitment that survives a quarter or two of results that look worse by old output metrics before outcome-based practice starts producing visibly better decisions.
• Cross-functional buy-in, since team structure, budgeting, and incentives touch far more than the product function alone.
• Patience with the fact that becoming product-led is a multi-year organizational shift, not a single reorg or a single training session.

Escaping the build trap was never really about hiring smarter product managers or adopting a smarter framework in isolation. It's about redesigning the structures, org charts, strategy communication, incentives, budgeting, and cultural safety, that determine which decisions are even possible for the people already doing the work.

The most useful thing an individual PM can take from this closing chapter isn't a checklist, it's a change in scope: pushing for structural fixes, team boundaries, how success gets measured, how strategy gets communicated, alongside personal process improvements, since process discipline alone tends to erode back into the build trap the moment organizational pressure returns.

Six Questions to Determine Whether a Company Is Product-Led

The book's appendix distills everything into a short diagnostic a reader can run on their own organization directly, without needing to read the rest of the book first.

• Does the organization make decisions based on validated outcomes, or based on whichever stakeholder, deal, or executive opinion is loudest?
• Are teams structured around durable outcomes, or around technical components and one-off projects?
• Does strategy get communicated as intent teams can adapt, or as fixed directives teams simply execute?
• Are incentives and performance reviews built around outcomes moved, or around output shipped?
• Is it genuinely safe to report a failed experiment, or does failure carry a real career cost?
• Does budgeting adapt to evidence as it comes in, or lock in a fixed plan regardless of what's learned?

A company answering "output, directives, and shipped features" to most of these questions is still operating inside the build trap, no matter what its mission statement or internal messaging claims. This appendix functions less as new content and more as a compact, repeatable audit a reader can rerun on their own organization every so often, since the honest answer to these six questions tends to shift slowly over time, not all at once.

The Entire Book in One Framework

Every framework in this book, the value exchange system, the four organization types, the three strategy gaps, the product kata, connects to a single underlying diagnostic: does this decision get made from validated evidence about outcomes, or from an assumption, a loud voice, or the sheer momentum of shipping something. The build trap is what happens when an organization's structure, not any individual's intent, keeps forcing the second answer.

Escaping it means redesigning that structure end to end. Strategy has to be deployed as layered intent, not fixed directives. Teams have to be organized around durable outcomes, not technical components or one-off projects. The kata has to replace a fixed roadmap as the actual operating rhythm. And incentives, safety, and budgeting all have to reward evidence and learning over raw output, or every process fix above them will quietly erode back into the old pattern.

Shipping is not success. A feature only becomes real progress once it has genuinely solved a customer's problem and moved a real business result, and everything before that point is activity, not value.

10 Most Important Takeaways

• The build trap is measuring success by output, features shipped, instead of outcome, whether a real problem got solved and a business result moved.
• There are four organization types, sales-led, visionary-led, technology-led, and product-led, and only product-led actually scales past the size where one deal, one person, or one technology can represent the whole market.
• Strategy fails between the boardroom and the team through three specific gaps: a knowledge gap, an alignment gap, and an effects gap, each with its own distinct fix.
• Strategy should be deployed as layered intent, vision, strategic intents, product initiatives, options, never handed down as a fixed feature list.
• The product kata replaces a fixed roadmap with a repeatable loop: know the target condition, know the current condition, set the next target condition, close the gap through real experimentation.
• Problem exploration has to happen before solution exploration, and skipping it is the single most common way teams fall back into the build trap under delivery pressure.
• A great PM owns the "why" behind what gets built and is judged on outcomes moved, not on shipped volume, feature count, or delivery dates hit.
• Teams should be organized around durable outcomes, not technical components or one-off projects, or the org chart will keep forcing output-based decisions regardless of stated intent.
• Incentives, psychological safety, and adaptive budgeting all have to change together, since fixing any one of the three without the others tends to produce a culture that games the new metric instead of genuinely changing behavior.
• Becoming product-led is a multi-year organizational redesign, not a single reorg, a training workshop, or a new set of frameworks handed to the PM team alone.

A company doesn't become product-led by hiring better product managers, it becomes product-led by building the organizational structure, team boundaries, strategy communication, incentives, and budgeting, that lets the product managers it already has make good decisions instead of fighting the org chart to make any decision at all.