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. ...