kienbui1995 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