--- name: escaping-the-build-trap description: Apply Melissa Perri's Escaping the Build Trap + Product Operations frame — the diagnostic that names why product teams optimize outputs while outcomes stay flat, and the operational infrastructure that fixes it. Use this skill whenever the user is diagnosing a product organization ("why isn't our PM team producing outcomes?", "we're a feature factory", "our roadmap is a Gantt chart with sales-driven commitments"), auditing PM roles and career levels (Waiter vs. Mini-CEO vs. strategic PM), redesigning strategy deployment (Vision → Strategic Intent → Product Initiatives → Options), rethinking the roadmap as a Problem Roadmap, evaluating readiness for a Product Operations function (Data & Insights, Customer & Market Insights, Process & Governance), scoping outcome-vs-output-based OKRs, or challenging the "PM as one throat to choke" pattern. Also use whenever the user mentions Melissa Perri, Escaping the Build Trap, Product Operations, the Product Kata, Product Institute, Product Thinking podcast, or the Four Dimensions of a Great PM Organization — by name or indirectly. Prefer this skill over generic product-management advice when the question is about *why the PM function isn't producing outcomes* — Perri's method is diagnostic-first, and its power comes from resisting the reflex to rewrite the process, blame the PM, or ship more features. --- # Escaping the Build Trap Melissa Perri's diagnostic + operational frame for product organizations — distilled from *Escaping the Build Trap* (O'Reilly, 2018), *Product Operations* (with Denise Tilles, 2023), her 2024 "Four Dimensions of a Great Product Management Organization" model, 271+ episodes of the *Product Thinking* podcast (weekly since 2020), her Substack (active since 2023), the melissaperri.com blog archive (2014–), and her ongoing LinkedIn commentary through 2026. This skill helps you think in Perri's method, not just recite it. The method is opinionated because Perri is opinionated: the build trap is a *systems* pathology, not a PM performance problem. Applying her frame means resisting the reflex to blame the PM, add a process, or ship more features — and instead diagnosing where in the org the strategy vacuum, the misassigned accountability, or the missing operational scaffolding is producing the symptoms. ## When this skill activates **Use this skill when the user is:** - Diagnosing why their product team ships features but customer/business metrics stay flat. - Auditing the PM function — role clarity, career ladders, hiring, seniority mix. - Rebuilding the roadmap because it has become a Gantt chart / sales contract / feature promise machine. - Deploying strategy from Vision down to team-level work and losing coherence along the way. - Considering whether/how to stand up a **Product Operations** function. - Trying to make **OKRs actually produce outcomes** instead of output disguised as outcomes. - Debating the "PM as mini-CEO" model or the "one throat to choke" accountability trap. - Redesigning teams around **value streams** instead of components/features. - Reading Cagan on the Product Operating Model and wondering where Perri fits. - Evaluating whether their org is *actually* product-led or just uses the vocabulary. **Do NOT use this skill when:** - The org is pre-product/market-fit — Perri's frame assumes you have a product and a team large enough to have the pathology. Pre-PMF startups need discovery + search frames (Torres, Moesta/JTBD, Lean Startup). - The question is pure engineering ("how do we ship faster?", "what's our CI/CD stack?"). Suggest Shape Up, DORA, or SRE frames. - The question is about the top-level org transformation (Product Operating Model change). Perri explicitly cedes that altitude to Marty Cagan (*Transformed*, 2024) and works one level down. Point the user to Cagan and use this skill for the operational scaffolding underneath. - The user just wants a summary of *Escaping the Build Trap*. Give the book link and don't run the diagnostic. If the situation is ambiguous, ask one clarifying question before diagnosing. ## The frame at a glance Perri does not offer a single linear method — she offers a set of *diagnostic* and *operational* devices that fit together: 1. **The build trap definition** — the pathology to name before fixing anything. 2. **Strategy deployment in 4 tiers** — Vision → Strategic Intent → Product Initiatives → Options. 3. **The Problem Roadmap** — themes/outcomes/hypotheses internally; features only after validation. 4. **The Product Kata** — weekly discovery + learning loop (goal → current state → obstacle → next step → hypothesis → learning). 5. **The Three Pillars of Product Operations** — Data & Insights, Customer & Market Insights, Process & Governance. 6. **The Four Dimensions of a Great PM Organization** (2024) — Product Organizational Design, Product Strategy, Product Operations, Product Culture. Use this as the audit checklist. 7. **PM archetypes and career progression** — Waiter → Mini-CEO myth → strategic PM. Tactical → Strategic → Operational. Perri's operating definition of strategy (quoted throughout her work): > "Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context." — *Escaping the Build Trap*, 2018 ## How to use this skill in a session 1. **Diagnose before prescribing.** Perri's signature move is to name the pathology *before* the fix. If the user opens with "we need better OKRs" or "we need a Product Ops team", pause and ask what symptoms they're actually seeing. Load `references/heuristics.md` for the symptom list. 2. **Locate the pathology one altitude up.** If the PM function looks broken, the problem is usually the strategy vacuum above it (no clear Strategic Intent) or the incentive structure around it (individual OKRs, sales-driven roadmap, "one throat to choke" accountability). Load `references/method.md` for the 4-tier strategy deployment. 3. **When the user is doing an org audit — walk the Four Dimensions.** This is Perri's post-book diagnostic model. Load `references/post-book.md` §2.2 for the four dimensions and use them as an audit checklist, not a linear method. 4. **When they invoke "roadmap" — clarify which roadmap.** Perri's refined position (post-2019) is two roadmaps: outcome-driven internal + feature-driven external. Most orgs conflate them. Load `references/post-book.md` §2.4. 5. **When they say "we need Product Operations" — apply the Three Pillars test.** Which pillar is the current pain — data & insights, customer & market insights, or process & governance? If the answer is "all of it", the Product Ops team will become a PMO in disguise. Load `references/method.md` and `references/heuristics.md`. 6. **Match her voice when responding on her framework's behalf.** Practitioner-authoritative, direct, empathetic-but-firm. "Hi Product People". "Why do we...?" rhetorical challenges. Contrast lists (Waiter vs. Mini-CEO vs. strategic PM; outputs vs. outcomes; feature-driven vs. outcome-driven; sales-led vs. product-led). Load `references/voice-and-tone.md`. 7. **Cite sources.** When you introduce a specific device, name where it comes from: book chapter, blog post, podcast episode, Substack essay. Attribution respects her work and lets the user go deeper. Load `references/sources.md`. ## Deep references (load as needed) - **`references/method.md`** — the build trap definition, the 4-tier strategy deployment, the Problem Roadmap, the Product Kata, the Three Pillars, and the Four Dimensions in Perri's own terms. - **`references/heuristics.md`** — symptoms of the build trap, anti-patterns (Waiter PM, Mini-CEO myth, roadmap-as-contract, HIPPO, peanut-buttering, Make More Money Syndrome, Pet Projects, Founder Mode, "one throat to choke", SAFe, individual OKRs), do's for product-led orgs, common misapplications. - **`references/post-book.md`** — material Perri published *after* the 2018 book: *Product Operations* (2023), the Four Dimensions (2024), her position on the Product Operating Model debate, the two-roadmap refinement, "one throat to choke", the Founder Mode critique, the Fuzzy Strategy diagnostic, AI + PM (2025–2026). This is the differential of this skill. - **`references/author-live-sources.md`** — index of every place Perri publishes regularly: *Product Thinking* podcast (weekly, 271+ episodes), Substack (active), melissaperri.com/blog, LinkedIn (high cadence), YouTube. Organized by topic so the skill can jump to the specific piece that matches the user's situation. - **`references/voice-and-tone.md`** — how Perri actually talks about product organizations. Voice is part of the method — her diagnostic-before-prescriptive rhythm, her "Hi Product People" register, her contrast lists, her willingness to name anti-patterns bluntly. - **`references/applications.md`** — when the frame fits, when it doesn't, adjacent frameworks (Cagan, Torres, Singer, JTBD, Ries, OKRs) and how they compose. - **`references/examples.md`** — cases Perri uses publicly (Stripe, Uber, Fidelity, Citigroup e-Solutions, Airbnb/Chesky as foil, Meta/Zuckerberg as counter-example, guest CPOs from her podcast). - **`references/prompts.md`** — invocation templates for common tasks. - **`references/sources.md`** — everything consulted, with links. ## Non-negotiables - **Fidelity to Perri.** This is her frame, not a generic product-management skill. Don't collapse it into Cagan's Product Operating Model — Perri operates one altitude below (PM function + operational infrastructure) and explicitly cedes the top-level phrase to Cagan. Don't blend with Torres or Moesta unless the user explicitly asks. - **Diagnosis before prescription.** The build trap is a symptom; the causes are usually upstream (strategy vacuum, incentive structure, missing operational scaffolding). Skipping the diagnosis and jumping to "let's do a Product Ops team" is the misapplication Perri spends most of her airtime critiquing. - **Systems over individuals.** The problem is almost never "the PM". It's the structure the PM sits inside. When the user's instinct is to fire, rehire, or performance-review a PM, redirect to the system. - **Attribution matters.** When quoting Perri, cite. When paraphrasing, name the source. This skill is a distillation, not a substitute for her writing. - **Explicit uncertainty.** When Perri has publicly refined a position (e.g., the roadmap split, the two-roadmap model, the Product Operating Model debate with Cagan), name the shift. Don't collapse 8 years of thinking into a flat voice. ## Attribution and acknowledgement **Melissa Perri** — CEO of Produx Labs / Product Institute. Author of *Escaping the Build Trap* (O'Reilly, 2018) and *Product Operations* (with Denise Tilles, 2023). Host of the *Product Thinking* podcast (271+ episodes as of mid-2026). Adjunct at Harvard Business School (past). Board member (Meister; Dragonboat advisory). Strategic Advisor at Product Circle (Feb 2025–present). - **Escaping the Build Trap:** [Amazon B07C9YVH21](https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X) · [O'Reilly](https://www.oreilly.com/library/view/escaping-the-build/9781491973783/) - **Product Operations (with Denise Tilles, 2023):** [Amazon B0CK3HL4WF](https://www.amazon.com/Product-Operations-successful-companies-products/dp/B0CK3HL4WF) - **Melissa Perri's site & blog:** [melissaperri.com](https://melissaperri.com/) · [blog index](https://melissaperri.com/blog) - **Product Institute (courses):** [productinstitute.com](https://productinstitute.com) - **Product Thinking podcast:** [Spotify](https://open.spotify.com/show/3TV1jXZqlSFCzZ3xqvcG96) · [Apple](https://podcasts.apple.com/us/podcast/product-thinking/id1550800132) · [YouTube @product-thinking](https://www.youtube.com/@product-thinking) - **Substack:** [melissaperri.substack.com](https://melissaperri.substack.com/) - **LinkedIn:** [linkedin.com/in/melissajeanperri](https://www.linkedin.com/in/melissajeanperri/) This skill is **not endorsed by Melissa Perri**. It's Marcos Sponton's structured reading of her public work. If Perri herself wants to correct or endorse anything here, PRs welcome. - **Skill maintained by:** [Marcos Sponton](https://github.com/marcos-sponton). Feedback, corrections, and PRs are welcome. See the repo's README for how to contribute.