Skillsroadmap-planning
R

roadmap-planning

Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.

Roadmap Planning - Product Strategy Roadmap Planning Workflow

Skill Overview

Roadmap Planning guides product managers through five stages—input collection, Epic definition, RICE prioritization, release sequencing, and stakeholder communication—to transform scattered feature requests into an outcome-oriented product roadmap that can pass executive review.

Use Cases

  1. You have a dozen competing initiatives and need to prioritize them before planning for the next quarter, producing a roadmap the executive team will genuinely approve.
  2. You need to plan the product roadmap for the next six months (or two quarters), allocate work appropriately across multiple teams, and confirm that the technical dependencies are realistically feasible.
  3. Your existing roadmap is merely a list of features (“dark mode,” “SSO,” “advanced reporting”), and you want to transform it into an outcome-oriented roadmap with hypotheses, success metrics, and a strategic narrative.

Core Features

  1. Five-stage structured process: From collecting business goals (OKRs), customer pain points, technical constraints, and stakeholder needs, to defining Epics with hypothesis statements and success metrics, then scoring and ranking them with RICE, sequencing them into quarters or a Now/Next/Later structure based on dependencies, and finally generating presentation materials and aligning stakeholders. It fully covers a 1–2 week planning cycle.
  2. Transparent prioritization: Includes recommendations for choosing an appropriate prioritization framework (such as RICE, ICE, or a value/effort matrix). Score items first, then adjust based on strategic alignment—for example, enterprise SSO may receive a modest RICE score but support an enterprise expansion strategy, so its priority can be raised. This avoids decisions based solely on the opinions of the highest-paid person in the room.
  3. Dependency mapping and communication templates: Explicitly map technical dependencies between Epics before prioritization (for example, “advanced reporting” depends on “data pipeline upgrades”) and validate feasibility with engineering. Produce either a quarterly roadmap or a Now/Next/Later structure, along with a presentation framework for “what is not on the roadmap,” reducing misunderstandings that could turn plans into perceived commitments.

Frequently Asked Questions

Is a product roadmap an external commitment? Can it be adjusted along the way?

No. This skill explicitly positions the roadmap as a strategic plan rather than a contract. When presenting it, explain to stakeholders that “this is a plan and will evolve as we learn,” and refine it quarterly based on new information. This helps avoid the inability to change direction caused by waterfall thinking.

What framework does it use to prioritize requests?

First, the prioritization advisor recommends an appropriate framework (RICE, ICE, a value/effort matrix, and so on). Each Epic is then scored, followed by a strategic alignment adjustment. Every Epic must first have a hypothesis statement (“We believe that building [X] for [audience] will achieve [outcome]”) and success metrics, so the scoring has a clear basis.

How is this skill different from scheduling work with a Gantt chart?

A Gantt chart only answers “when will we do what?” This workflow answers “why do this instead of that?” Each Epic is tied to business outcomes and success metrics; items are prioritized before being sequenced, and dependencies are explicitly mapped. It is suitable for quarterly or semiannual planning and stakeholder alignment, but is not intended to replace day-to-day sprint-level task planning.