Roadmap Planning

Roadmap Planning

Take a pile of ideas, requests, and ongoing work. Produce a defensible plan for what to ship, when, and why. The output is a roadmap document plus the prioritization work that made it credible.

When to use

• Planning the next quarter or the next year
• Sequencing work where some items depend on others
• Balancing new builds, improvements, and maintenance
• Saying no (or "not yet") to specific requests with a defensible reason
• Aligning a team around a single shared plan
• Communicating the plan to stakeholders outside the team
• Replanning after a strategy shift, a missed quarter, or new constraints

When NOT to use

• Specifying a single feature for development (use pm-spec-writing)
• Validating whether the idea is worth building (use ux-research)
• Designing the feature itself (use design-standards)
• Writing the launch plan for a single initiative (use launch-runbook)
• Reviewing what shipped vs what was promised (use after-action-report)

Required inputs

• The team's strategy or top-level goals (1 to 5 OKRs, themes, or pillars)
• The backlog: every candidate item, with at least a one-sentence description
• The team's capacity (people × time)
• Known constraints (deadlines, dependencies, hiring, budget)
• The planning horizon (a quarter, two quarters, a year)

If the strategy is missing, the roadmap will be a list of features, not a plan. Push back and get the strategy first. A roadmap without strategy is just a queue.

The framework: 5 layers