roadmap-planning

Roadmap Planning

When to Use

When deciding what to build over the next quarter, communicating priorities to stakeholders, or aligning the team on direction.

Core Jobs

1. Gather Inputs

• User feedback and support tickets (top pain points)
• Business goals for the quarter (revenue, retention, activation)
• Engineering capacity (subtract 20–30% for incidents/tech debt)
• Stakeholder requests (log them, don't auto-prioritize)

2. Prioritize with ICE

Score each initiative:

• Impact (1–10): How much does this move the key metric?
• Confidence (1–10): How sure are we this will work?
• Ease (1–10): How fast/cheap to build?
• ICE Score = (I + C + E) / 3 — rank by score, then apply judgment

3. Build the Now/Next/Later Structure

• Now (this quarter, committed): Fully scoped, resources assigned
• Next (next quarter, directional): Validated problem, not yet scoped
• Later (future, aspirational): Interesting ideas, not yet prioritized
• Not doing (explicit): Things rejected and why — prevents re-litigation

4. Communicate to Stakeholders

• Lead with the "why" (business goal this serves)
• Show the Now/Next/Later view, not a Gantt chart
• Acknowledge what's NOT on the roadmap and why
• Set a review cadence (monthly check-in recommended)

Key Outputs

• ICE-scored backlog
• Now/Next/Later roadmap (1-pager)
• Stakeholder update (written, async-first)

Anti-Patterns

• Committing to dates without capacity analysis
• Roadmap as a feature wish list, not a strategy
• Not saying "no" explicitly — ambiguity creates false expectations
• Updating roadmap in isolation without team input