Imported from tomaszstaniak/pm-ai-skills (escaping-build-trap/SKILL.md). Install upstream with npx skills add tomaszstaniak/pm-ai-skills --skill escaping-build-trap. Copyright stays with the author (CC-BY-SA-4.0).

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:

The Build Trap Diagnostic

Is your organization in the build trap? Check these signals:

The Four Product Manager Archetypes

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:

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:

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:

1. For each planned feature, ask: "Why are we building this? What outcome should it drive?"
2. Replace the feature with the outcome.
3. Let the team discover the best solution — it might not be the originally planned feature.
4. Define success metrics and a measurement plan before starting work.

Product applications:

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:

For each scenario:

1. How likely is this right now? (be honest)
2. What evidence do we have? (look at current data)
3. What would we do differently? (change the plan now, not after the quarter)

Common Mistakes

Quick Diagnostic

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

• Escaping the Build Trap by Melissa Perri

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.