roadmap-decision

name	roadmap-decision
description	Make roadmap decisions by connecting product outcomes, evidence, sequencing, dependencies, capacity, uncertainty, and explicit commitments.

Roadmap Decision

Use when deciding which product outcomes belong in a planning horizon and how they should be sequenced or communicated.

Procedure

1. Define the planning horizon and audience. A team execution roadmap, public direction, and leadership investment view may require different levels of detail and certainty.
2. Start from product outcomes, problems, or strategic bets rather than a calendar of feature names. For each item state the result sought and why it matters now.
3. Gather evidence and assumptions supporting each candidate: user research, usage data, customer needs, technical constraints, strategic goals, risks, and learning already completed.
4. Separate committed work from directional or exploratory work. Do not present low-confidence ideas with the same certainty as near-term scope that has been validated and staffed.
5. Sequence according to dependencies, enabling capabilities, learning order, deadlines, and capacity. Avoid false precision in dates when scope or feasibility is not mature enough to support it.
6. Account for maintenance, reliability, security, migration, and operational work that consumes real capacity even when it is less visible than new features.
7. Identify assumptions that could reorder the roadmap and schedule discovery or decision checkpoints before making expensive downstream commitments.
8. Resolve competing items using the product prioritization method appropriate to the horizon, then check whether the resulting roadmap forms a coherent strategy rather than a pile of unrelated requests.
9. Record what is deliberately not planned in the horizon and why. This protects focus and makes later changes understandable.
10. Revisit the roadmap when material evidence, capacity, constraints, or strategy changes. Preserve enough decision context to explain why priorities moved.

Decision rules

• A roadmap communicates direction and sequencing; it is not automatically a delivery-date contract.
• Confidence should decrease with distance and unresolved dependencies.
• Do not pad a roadmap merely to represent every request.
• Technical feasibility and capacity come from engineering owners; Product Manager integrates those constraints into product sequencing.
• Discovery can be roadmap work when reducing uncertainty is the highest-value next outcome.

Quality gate

The roadmap decision is ready when items connect to outcomes and evidence, commitment levels are explicit, sequencing reflects dependencies and capacity, uncertainty is visible, excluded work is intentional, and the roadmap can guide decisions without pretending to know more than the organization actually knows.