# Pant Roadmap Review > Pressure-test a product roadmap and rehearse roadmap review conversations. Use for strategic coherence, outcomes, sequencing, capacity, tradeoffs, dependencies, adoption, and evidence; not sprint or backlog review. - Skill: `deanpeters/pant-roadmap-review` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds@latest add deanpeters/pant-roadmap-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/deanpeters/pant-roadmap-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: CC-BY-NC-SA-4.0 - Author: Dean Peters (https://skillmd.com/u/deanpeters) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/deanpeters/pant-roadmap-review --- # PANT Roadmap Review ## Purpose Test whether a roadmap communicates a defensible allocation of product investment toward outcomes—or merely presents features, dates, and inherited commitments. Apply the bundled runtime contracts. No other PANT skill is required. ## When to Use Use for roadmap documents, now-next-later views, portfolio investment views, roadmap presentations, roadmap refreshes, and conversations in which sequencing or commitment is being challenged. ## When Not to Use Use `pant-strategy-review` when the primary weakness is the absence of a strategic diagnosis or choices. Use `pant-executive-decision-review` when the roadmap is only supporting evidence for a specific executive ask. Use `pant-tactical-plan-approval` for implementation detail after direction is settled. Do not turn this into backlog grooming. ## Supported Modes and Entry Paths - **Feedback:** Apply [feedback mode](references/runtime/feedback-mode.md) and the roadmap output below. - **Dialogue:** Apply [dialogue mode](references/runtime/dialogue-mode.md), asking one roadmap question at a time. - **Direct:** Start from the supplied roadmap or brief without intake. - **Guided:** Explain the roadmap decision test, then ask one consequential question at a time. - **Best effort:** State assumptions about horizon, audience, capacity, and commitment; begin with reduced confidence. ## Decision Being Prepared For Prepare a decision about what product outcomes or opportunities deserve investment, in what sequence, under which constraints, and with what conditions for adaptation. Distinguish directional intent from a delivery commitment. ## Typical Audiences Product and technology leaders, executives, portfolio councils, delivery leaders, go-to-market partners, customer-facing teams, and product teams. Model their authority and incentives rather than caricaturing their titles. ## Inputs Best input includes the roadmap, intended outcomes, product strategy, evidence, capacity assumptions, dependencies, committed dates, and audience. Minimum context is any proposed sequence of product work. Do not ask users to repeat supplied material. Direct example: > Use `pant-roadmap-review` in feedback mode. Test whether this roadmap is outcome-oriented, strategically coherent, feasible, explicit about tradeoffs, and capable of adapting when evidence changes. Sparse example: > Our leadership team says the roadmap is just a feature list. Walk me through fixing it. ## Quick Start 1. Identify the roadmap decision, horizon, and audience. 2. Read [roadmap decision logic](references/roadmap-decision-logic.md). 3. Establish intended outcomes and the evidence linking investments to them. 4. Test choices, exclusions, sequence, capacity, dependencies, adoption, and adaptation conditions. 5. Begin with the most consequential weakness; do not require a completed template. ## Review Workflow 1. **Name the roadmap's job.** Clarify the decision or alignment it must enable. 2. **Find what survives.** Preserve supported outcomes, explicit choices, credible constraints, and honest uncertainty. 3. **Separate layers.** Distinguish strategy, roadmap investment, discovery, delivery plan, and backlog detail. 4. **Test outcome logic.** Inspect the causal connection from work to changed behavior and business or mission consequence. 5. **Test choice and tradeoff.** Identify what is not funded, displaced, delayed, or deliberately left uncertain. 6. **Test sequence.** Examine learning order, dependencies, irreversible commitments, capacity, and time-critical constraints. 7. **Test the whole value path.** Include discovery, delivery, enablement, adoption, operations, and measurement—not coding alone. 8. **Test adaptability.** Require decision points, signals, and conditions that would change the roadmap. 9. **Classify evidence.** Apply the bundled evidence and concern models; reject authority, urgency, and precision as substitutes for proof. 10. **Issue a contextual verdict.** Judge readiness for this audience and roadmap decision only. Escape roadmap mechanics when the real blocker is missing strategy, unsupported market economics, or an unowned implementation plan. Route or combine only when specialization materially improves the work. ## Dialogue Protocol Open with the highest-priority unresolved roadmap question. Ask one question at a time, use each answer, track contradictions, and narrow concerns when evidence warrants it. Honor all controls in the bundled dialogue contract. At resistant or hostile-room pressure, challenge hidden commitments and weak tradeoffs more persistently without inventing constraints or becoming abusive. ## Output Use the shared feedback order and add a **Roadmap decision brief**: - Roadmap decision, horizon, and audience - Intended outcomes and strongest supporting evidence - Explicit choices, exclusions, and opportunity costs - Sequence rationale, dependencies, and capacity assumptions - Adoption and operating implications - Adaptation signals and decision points - Three consequential review questions - Contextual readiness verdict For guided users, explain whether each problem belongs to strategy, roadmap, plan, or backlog. Use [template.md](template.md) for a reusable artifact. ## Failure Modes - Treating a release plan or feature inventory as a roadmap - Demanding precise dates where discovery uncertainty is material - Calling themes outcomes without a causal explanation - Ignoring displaced investments, enablement, or ongoing ownership - Treating customer requests or executive opinions as automatic strategy - Rewarding roadmap cosmetics while the allocation logic remains weak - Continuing roadmap questions after missing strategy becomes the dominant problem - Manufacturing objections to a bounded, evidence-linked roadmap ## Evaluation Requirements Evaluate neighboring triggers; strong and weak roadmaps; minimal and rich context; all entry paths; feedback and dialogue; outcome logic; sequence; opportunity cost; capacity; adaptation; framework escape; persuasion; non-abusive pressure; and contextual verdicts. ## Supporting Files - [Roadmap review template](template.md) - [Roadmap decision logic](references/roadmap-decision-logic.md) - [Sources and adaptations](references/sources.md) - [Bundled runtime contract](references/runtime/antagonist-contract.md) - [Worked example](examples/worked-example.md) - [Weak example](examples/weak-example.md) ## Provenance Informed by the repository's Phase 0 research synthesis and *The Dangerous Animals of Product Management*. PANT adapts outcome, evidence, tradeoff, and encounter-pattern principles into a portable roadmap pressure test; it does not reproduce a proprietary roadmap method.