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 and the roadmap output below.
- Dialogue: Apply dialogue mode, 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
- Identify the roadmap decision, horizon, and audience.
- Read roadmap decision logic.
- Establish intended outcomes and the evidence linking investments to them.
- Test choices, exclusions, sequence, capacity, dependencies, adoption, and adaptation conditions.
- Begin with the most consequential weakness; do not require a completed template.
Review Workflow
- Name the roadmap's job. Clarify the decision or alignment it must enable.
- Find what survives. Preserve supported outcomes, explicit choices, credible constraints, and honest uncertainty.
- Separate layers. Distinguish strategy, roadmap investment, discovery, delivery plan, and backlog detail.
- Test outcome logic. Inspect the causal connection from work to changed behavior and business or mission consequence.
- Test choice and tradeoff. Identify what is not funded, displaced, delayed, or deliberately left uncertain.
- Test sequence. Examine learning order, dependencies, irreversible commitments, capacity, and time-critical constraints.
- Test the whole value path. Include discovery, delivery, enablement, adoption, operations, and measurement—not coding alone.
- Test adaptability. Require decision points, signals, and conditions that would change the roadmap.
- Classify evidence. Apply the bundled evidence and concern models; reject authority, urgency, and precision as substitutes for proof.
- 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 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
- Roadmap decision logic
- Sources and adaptations
- Bundled runtime contract
- Worked example
- Weak example
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.
1---2name: pant-roadmap-review3description: 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.4license: CC-BY-NC-SA-4.05---67# PANT Roadmap Review89## Purpose1011Test 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.1213## When to Use1415Use for roadmap documents, now-next-later views, portfolio investment views, roadmap presentations, roadmap refreshes, and conversations in which sequencing or commitment is being challenged.1617## When Not to Use1819Use `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.2021## Supported Modes and Entry Paths2223- **Feedback:** Apply [feedback mode](references/runtime/feedback-mode.md) and the roadmap output below.24- **Dialogue:** Apply [dialogue mode](references/runtime/dialogue-mode.md), asking one roadmap question at a time.25- **Direct:** Start from the supplied roadmap or brief without intake.26- **Guided:** Explain the roadmap decision test, then ask one consequential question at a time.27- **Best effort:** State assumptions about horizon, audience, capacity, and commitment; begin with reduced confidence.2829## Decision Being Prepared For3031Prepare 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.3233## Typical Audiences3435Product 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.3637## Inputs3839Best 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.4041Direct example:4243> 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.4445Sparse example:4647> Our leadership team says the roadmap is just a feature list. Walk me through fixing it.4849## Quick Start50511. Identify the roadmap decision, horizon, and audience.522. Read [roadmap decision logic](references/roadmap-decision-logic.md).533. Establish intended outcomes and the evidence linking investments to them.544. Test choices, exclusions, sequence, capacity, dependencies, adoption, and adaptation conditions.555. Begin with the most consequential weakness; do not require a completed template.5657## Review Workflow58591. **Name the roadmap's job.** Clarify the decision or alignment it must enable.602. **Find what survives.** Preserve supported outcomes, explicit choices, credible constraints, and honest uncertainty.613. **Separate layers.** Distinguish strategy, roadmap investment, discovery, delivery plan, and backlog detail.624. **Test outcome logic.** Inspect the causal connection from work to changed behavior and business or mission consequence.635. **Test choice and tradeoff.** Identify what is not funded, displaced, delayed, or deliberately left uncertain.646. **Test sequence.** Examine learning order, dependencies, irreversible commitments, capacity, and time-critical constraints.657. **Test the whole value path.** Include discovery, delivery, enablement, adoption, operations, and measurement—not coding alone.668. **Test adaptability.** Require decision points, signals, and conditions that would change the roadmap.679. **Classify evidence.** Apply the bundled evidence and concern models; reject authority, urgency, and precision as substitutes for proof.6810. **Issue a contextual verdict.** Judge readiness for this audience and roadmap decision only.6970Escape 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.7172## Dialogue Protocol7374Open 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.7576## Output7778Use the shared feedback order and add a **Roadmap decision brief**:7980- Roadmap decision, horizon, and audience81- Intended outcomes and strongest supporting evidence82- Explicit choices, exclusions, and opportunity costs83- Sequence rationale, dependencies, and capacity assumptions84- Adoption and operating implications85- Adaptation signals and decision points86- Three consequential review questions87- Contextual readiness verdict8889For guided users, explain whether each problem belongs to strategy, roadmap, plan, or backlog. Use [template.md](template.md) for a reusable artifact.9091## Failure Modes9293- Treating a release plan or feature inventory as a roadmap94- Demanding precise dates where discovery uncertainty is material95- Calling themes outcomes without a causal explanation96- Ignoring displaced investments, enablement, or ongoing ownership97- Treating customer requests or executive opinions as automatic strategy98- Rewarding roadmap cosmetics while the allocation logic remains weak99- Continuing roadmap questions after missing strategy becomes the dominant problem100- Manufacturing objections to a bounded, evidence-linked roadmap101102## Evaluation Requirements103104Evaluate 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.105106## Supporting Files107108- [Roadmap review template](template.md)109- [Roadmap decision logic](references/roadmap-decision-logic.md)110- [Sources and adaptations](references/sources.md)111- [Bundled runtime contract](references/runtime/antagonist-contract.md)112- [Worked example](examples/worked-example.md)113- [Weak example](examples/weak-example.md)114115## Provenance116117Informed 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.