tomaszstaniak Escaping the Build Trap
A diagnostic and corrective framework for product teams and organizations stuck in the "build trap" — the cycle of shipping features without measuring outcomes. Based on Melissa Perri's "Escaping the Build Trap." Includes a pre-mortem checkpoint to detect build-trap patterns before committing to a roadmap.
Core Principle
The build trap is when organizations measure success by outputs (features shipped, story points completed) instead of outcomes (customer problems solved, business metrics moved). Companies fall into the build trap when they become feature factories — taking orders from stakeholders, building what's requested, and never asking "did it work?"
The way out is not a process change or a new tool. It's a fundamental shift in how the organization defines the role of product, how strategy flows from vision to execution, and how success is measured.
Scoring
Goal: 10/10. When evaluating product development practices, rate 0-10:
| Score | Description |
|---|---|
| 0-2 | Deep in the build trap. Roadmap is a feature list from stakeholders. No one tracks whether shipped features achieved anything. |
| 3-4 | Aware of the problem. Some metrics exist, but features are still driven by HiPPO (Highest Paid Person's Opinion) or sales requests. |
| 5-6 | Transitioning. Outcomes are discussed but not consistently used to make decisions. Some teams experiment; others still take orders. |
| 7-8 | Outcome-driven. Teams own outcomes, have autonomy to find solutions, and kill features that don't move metrics. Strategy connects vision to team-level work. |
| 9-10 | Product-led organization. Every team has a clear outcome. Strategy deployment works end-to-end. Product managers are empowered. Experiments and data drive decisions. Learning is valued over shipping. |
The Build Trap Diagnostic
Is your organization in the build trap? Check these signals:
| Signal | Build Trap | Healthy |
|---|---|---|
| Roadmap content | Feature list with dates | Outcomes with time horizons |
| Success metric | "We shipped it on time" | "It moved the metric" |
| PM's job | Write requirements, manage backlog | Discover problems, test solutions |
| Strategy | "Build everything for everyone" | "Solve this problem for this customer" |
| Stakeholder requests | Accepted as requirements | Treated as inputs to discover the real need |
| Shipped feature that failed | "At least we shipped" | "What did we learn? Should we iterate or kill it?" |
| Team autonomy | Low — told what to build | High — told what outcome to achieve |
The Four Product Manager Archetypes
| Archetype | Behavior | Build Trap Risk | Fix |
|---|---|---|---|
| The Waiter | Takes orders from stakeholders and delivers them | Highest — no ownership of outcomes | Give PMs outcomes, not feature requests |
| The Former Project Manager | Manages timelines and tickets, not problems | High — focuses on delivery, not discovery | Pair with a coach; redefine the role |
| The Mini-CEO | Makes decisions unilaterally, ignores data | Medium — might ship right things by luck | Introduce experimentation discipline |
| The Strategic PM | Owns outcomes, discovers problems, tests solutions | Lowest — this is the target | Support and protect this behavior |
Strategy Deployment: Vision to Action
Core concept: Strategy is a cascade, not a directive. It flows from vision (where we are going) through strategic intents (what challenges block us) to product initiatives (what problems to solve) to options (how teams will solve them). Each level sets constraints; it does not prescribe solutions.
Why it works: The build trap exists partly because the cascade is broken. Without strategic intents, teams cannot say no to stakeholder requests. Without product initiatives, teams either drift or build whatever is loudest. With the cascade explicit, every team has a clear context for their work and a defensible reason to focus.
Perri's strategy deployment model:
┌──────────────────────┐
│ COMPANY VISION │ Where are we going? (5+ years)
│ (aspirational north) │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ STRATEGIC INTENTS │ What challenges must we overcome
│ (company-level) │ to get there? (2-5 years)
└──────────┬───────────┘
▼
┌──────────────────────┐
│ PRODUCT INITIATIVES │ What problems do our products
│ (product-level) │ need to solve? (quarterly)
└──────────┬───────────┘
▼
┌──────────────────────┐
│ OPTIONS │ What solutions might work?
│ (team-level) │ (weekly experiments)
└──────────────────────┘
Key insights:
- Each level sets the constraint for the level below, not the specific solution
- Teams have autonomy at the Options level — they choose HOW to achieve the initiative
- If you can't trace a feature back up to a strategic intent, question why it exists
- Strategy is deployed, not delegated — leadership must articulate each level clearly
Product applications:
| Context | Application | Example |
|---|---|---|
| Roadmap planning | Check that every item traces to a strategic intent | "This feature maps to initiative 'reduce onboarding friction' which maps to intent 'become the easiest tool to start with'" |
| Saying no | Use the strategy hierarchy to decline requests | "This request doesn't map to any current product initiative. Let's revisit when priorities change." |
| Team misalignment | Identify where the strategy chain breaks | "Teams have options, but nobody articulated the product initiative — everyone's solving different problems" |
Copy patterns:
- "Vision: [aspirational north]. Strategic intent: [challenge to overcome]. Product initiative: [problem to solve]. Options: [solutions to test]."
- "This feature traces back to: initiative '[X]' → intent '[Y]' → vision '[Z]'. If it doesn't trace, it doesn't ship."
- "We don't tell teams what to build. We tell them what outcome to achieve and trust them to find the best path."
Ethical boundary: Strategy deployment must be genuine, not performative. If leadership assigns outcomes but then dictates specific features, the deployment is theater. Teams need real autonomy at the options level for this framework to work.
See: references/strategy-deployment.md
Outcome-Based Roadmaps
Core concept: A roadmap is a sequence of outcomes to achieve, not features to ship. The feature is the proposed solution; it should remain negotiable until the team has tested its assumptions. The outcome — what customer behavior or business metric will change — is what the team commits to.
Why it works: Feature roadmaps lock in solutions before the team has learned anything. They reward shipping over impact and turn the PM into a delivery coordinator. Outcome roadmaps preserve optionality: the team can substitute a better solution as discovery surfaces evidence, while still being accountable for the change in the metric that matters.
Replace feature roadmaps with outcome roadmaps:
| Feature Roadmap (build trap) | Outcome Roadmap (healthy) |
|---|---|
| Q1: Build SSO integration | Q1: Reduce enterprise onboarding time from 2 weeks to 2 days |
| Q2: Add reporting dashboard | Q2: Increase monthly active usage among managers by 30% |
| Q3: Mobile app | Q3: Enable 50% of field teams to complete workflows outside the office |
Key insights:
- The outcome must be measurable. "Improve onboarding" is not an outcome; "reduce onboarding time from 2 weeks to 2 days" is.
- A good outcome is owned by one team. If multiple teams must coordinate, the outcome is too coarse.
- Replace one feature with one outcome at a time. Convert the whole roadmap at once and stakeholders rebel.
- Set the outcome before committing to a solution. Reverse-engineering the outcome after picking the feature is theater.
How to convert:
- For each planned feature, ask: "Why are we building this? What outcome should it drive?"
- Replace the feature with the outcome.
- Let the team discover the best solution — it might not be the originally planned feature.
- Define success metrics and a measurement plan before starting work.
Product applications:
| Context | Application | Example |
|---|---|---|
| Quarterly planning | Frame each quarterly bet as an outcome with a metric delta | "Q1: lift trial-to-paid conversion from 17% to 25%." |
| Stakeholder management | Translate feature requests into the outcome they would presumably drive | "You want SSO. The outcome is enterprise onboarding under 2 days. Let us bring back the best path to that." |
| Killing a feature | Use the outcome it was supposed to drive as the evidence | "We shipped X to drive Y. Y has not moved in 6 months. We are deprecating X." |
Copy patterns:
- "Q1 outcome: [measurable customer behavior change]. We will know we succeeded when [metric] moves from [X] to [Y]."
- "We replaced 'Build SSO' with 'Reduce enterprise onboarding from 2 weeks to 2 days.' SSO might be the solution — or something better might emerge."
- "Our roadmap shows where we are going, not how we will get there."
Ethical boundary: Outcome roadmaps require honest metrics. Never choose metrics that are easy to move but don't reflect real customer value. "Increase page views" is a vanity outcome if it doesn't correlate with customer success.
See: references/outcome-roadmaps.md
Pre-Mortem: Build Trap Detector
Before committing to a quarterly plan or major roadmap, run this pre-mortem. It specifically targets build-trap patterns.
Pre-mortem prompt:
"It is the end of the quarter. We shipped everything on the roadmap.
But none of it mattered — metrics didn't move, customers aren't
happier, and leadership is frustrated. What went wrong?"
Build-trap-specific failure scenarios:
| Pattern | Pre-mortem question | Failure scenario |
|---|---|---|
| Feature factory | Did we build what was requested instead of what was needed? | "Sales asked for a dashboard. We built it. Nobody uses it because the real problem was data quality, not visibility." |
| No discovery | Did we skip talking to customers? | "We assumed we knew the problem. We were wrong. Three months of work missed the mark." |
| Vanity metrics | Are we measuring the right thing? | "DAU went up because of a notification we added. But retention and NPS dropped — we annoyed users." |
| Strategy gap | Can every team connect their work to a strategic intent? | "Two teams built overlapping features because nobody articulated the product initiative." |
| Zombie features | Are we maintaining features nobody uses? | "40% of engineering time goes to features with <5% adoption. We're too busy maintaining the past to build the future." |
For each scenario:
- How likely is this right now? (be honest)
- What evidence do we have? (look at current data)
- What would we do differently? (change the plan now, not after the quarter)
Common Mistakes
| Mistake | Why It Fails | Fix |
|---|---|---|
| Renaming features as outcomes | "Launch SSO" is not an outcome, it's a feature in disguise | Outcomes must be measurable changes in behavior or metrics |
| Giving teams outcomes but no autonomy | "Increase retention by 15%... by building these 5 features" defeats the purpose | Set the outcome, then step back and let the team discover solutions |
| Blaming PMs for the build trap | It's an organizational problem, not an individual one | Leadership must change how strategy is deployed and how success is measured |
| Measuring activity, not impact | "We shipped 47 features" says nothing about value | Track: outcome achieved, time to learn, experiments run |
| Doing discovery once, then building for months | Discovery must be continuous, not a phase | Build weekly customer touchpoints into the team's rhythm |
| Big-bang roadmap reveals | Annual planning locks in assumptions for 12 months | Use quarterly outcome-setting with monthly check-ins |
Quick Diagnostic
| Question | If No | Action |
|---|---|---|
| Can every team state the outcome they're optimizing for? | Teams are taking orders, not owning outcomes | Define one measurable outcome per team |
| Do you track whether shipped features actually moved metrics? | You don't know if your work matters | Add post-launch measurement for every significant release |
| Can a PM say "no" to a stakeholder request? | PMs are waiters, not strategists | Give PMs outcome authority and back them up |
| Can you trace every roadmap item to a strategic intent? | Strategy deployment is broken | Map the hierarchy: vision → intents → initiatives → options |
| Have you killed a feature this quarter? | You only add, never subtract — complexity grows | Review adoption data monthly; deprecate what doesn't work |
Reference Files
- Build Trap Diagnostic — Detailed diagnostic questionnaire, signal-detection techniques, maturity model for product organizations, and case studies of teams escaping the build trap
- PM Archetypes — The four archetypes in depth, self-assessment tools, coaching strategies for each archetype, and organizational conditions that create waiters vs. strategists
- Strategy Deployment — Vision-to-options cascade, how to write each level, alignment workshops, and common breakdowns in the deployment chain
- Outcome Roadmaps — Feature-to-outcome conversion process, outcome writing templates, success metric selection, and how to communicate outcome roadmaps to stakeholders who expect feature lists
Further Reading
About the Author
Melissa Perri is the CEO of Produx Labs, a product management consultancy, and the author of "Escaping the Build Trap." She teaches product management at Harvard Business School and has helped organizations including Athena Health, Spotify, and Capital One transform their product practices.