Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.
Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.
intent
Guide product managers through strategic roadmap planning by orchestrating prioritization, epic definition, stakeholder alignment, and release sequencing skills into a structured process. Use this to move from disconnected feature requests to a cohesive, outcome-driven roadmap that aligns stakeholders, sequences work logically, and communicates strategic intent—avoiding "feature factory" roadmaps that lack strategic narrative or customer-centric framing.
type
workflow
theme
strategy-positioning
best_for
["Building a strategic roadmap that survives exec review","Prioritizing competing initiatives across multiple teams","Planning and sequencing work for the next quarter or half-year"]
scenarios
["I have 15 competing initiatives and need to build a Q2 roadmap my exec team will actually approve","I'm planning our 6-month product roadmap and need to sequence work across 3 teams"]
estimated_time
45-90 min
Purpose
Guide product managers through strategic roadmap planning by orchestrating prioritization, epic definition, stakeholder alignment, and release sequencing skills into a structured process. Use this to move from disconnected feature requests to a cohesive, outcome-driven roadmap that aligns stakeholders, sequences work logically, and communicates strategic intent—avoiding "feature factory" roadmaps that lack strategic narrative or customer-centric framing.
This is not a Gantt chart—it's a strategic communication tool that shows what you're building, why it matters, and how it ladders up to business outcomes.
Input
Works best with: The product and planning horizon (next quarter, next year).
Also useful: Strategy or OKRs to ladder to, the candidate initiative list, team capacity, and known stakeholder pressures.
Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.
Arriving empty-handed? That works too. The workflow starts by establishing strategic context, then moves through prioritization, epic definition, and sequencing.
Example invocation:Plan a 2-quarter roadmap for our mobile app: here are our 3 OKRs and a list of 12 candidate initiatives.
Key Concepts
What is Strategic Roadmap Planning?
Roadmap planning is the process of:
Gathering inputs — Customer problems, business goals, technical constraints
Defining initiatives — Epics with clear hypotheses and success metrics
Prioritizing — Rank initiatives by impact, effort, strategic fit
Sequencing — Organize into releases/quarters with logical dependencies
Communicating — Present roadmap to stakeholders with strategic narrative
Types of Roadmaps
Now/Next/Later Roadmap:
Now: Current quarter (committed)
Next: Following quarter (high confidence)
Later: Future exploration (low confidence)
Best for: Agile teams, uncertainty, continuous discovery
Theme-Based Roadmap:
Organize by strategic themes (e.g., "Retention," "Enterprise Expansion," "Mobile Experience")
Best for: Communicating to execs, showing strategic intent
Timeline Roadmap (Quarters):
Q1: Epics A, B; Q2: Epics C, D; Q3: Epics E, F
Best for: Resource planning, stakeholder communication
Feature-Based Roadmap (Anti-Pattern):
Lists features without context (e.g., "Dark mode," "SSO," "Advanced reporting")
Why it fails: No strategic narrative, no customer problems framed
Why This Works
Outcome-driven: Ties initiatives to business/customer outcomes
Stakeholder alignment: Transparent process reduces political friction
Strategic clarity: Shows not just "what" but "why"
Flexible: Adapts as you learn from discovery/delivery
Anti-Patterns (What This Is NOT)
Not a commitment: Roadmaps are strategic plans, not contracts
Not a feature list: Roadmaps frame problems, not just solutions
Not waterfall: Roadmaps evolve quarterly based on learning
When to Use This
Annual or quarterly planning cycles
After product strategy session (translate strategy to roadmap)
Onboarding new stakeholders (align on direction)
Reframing existing roadmap (shift from feature-driven to outcome-driven)
When NOT to Use This
For tactical sprint planning (use backlog instead)
When strategy is unclear (run product-strategy-session first)
When stakeholders expect date commitments (address expectations first)
Facilitation Source of Truth
When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.
It defines:
session heads-up + entry mode (Guided, Context dump, Best guess)
one-question turns with plain-language prompts
progress labels (for example, Context Qx/8 and Scoring Qx/5)
interruption handling and pause/resume behavior
numbered recommendations at decision points
quick-select numbered response options for regular questions (include Other (specify) when useful)
This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.
Application
Use template.md for the full fill-in structure.
This workflow orchestrates 5 phases over 1-2 weeks, using multiple component and interactive skills.
Phase 1: Gather Inputs (Day 1-2)
Goal: Collect business goals, customer problems, technical constraints, stakeholder requests.
Activities
1. Review Business Goals (OKRs, Strategic Initiatives)
Source: Company OKRs, exec strategy memos, board decks
Questions:
What are the company's top 3 priorities this year?
What metrics must we move? (revenue, retention, acquisition, efficiency)
Are there strategic bets? (new markets, partnerships, product lines)
Output: 3-5 business outcomes to optimize for
2. Review Customer Problems (Discovery Insights)
Source: Discovery interviews, support tickets, NPS feedback, churn surveys
Use: Insights from skills/discovery-process/SKILL.md (if recently completed)
Output: List of stakeholder requests (not yet committed)
Outputs from Phase 1
Business outcomes: 3-5 OKRs or strategic goals
Customer problems: 3-5 validated pain points
Technical investments: Platform/tech debt items
Stakeholder requests: Feature requests from internal teams
Phase 2: Define Initiatives (Epics) (Day 3-4)
Goal: Turn inputs into epics with hypotheses, success metrics, and effort estimates.
Activities
1. Define Epic Hypotheses
Use:skills/epic-hypothesis/SKILL.md (component)
For each initiative: Write hypothesis statement
Format: "We believe that [building X] for [persona] will achieve [outcome] because [assumption]."
Participants: PM
Duration: 60 minutes per epic
Output: 10-15 epic hypotheses
Example Epics (SaaS Product):
Epic 1: Guided Onboarding
Hypothesis: We believe that adding a step-by-step onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.
Success Metric: Activation rate (% completing first action within 24 hours)
Target: 40% → 60%
Epic 2: Enterprise SSO
Hypothesis: We believe that adding SSO for enterprise accounts will increase enterprise deals closed from 2/quarter to 5/quarter because enterprise buyers require SSO for security compliance.
Success Metric: Enterprise deals closed per quarter
Target: 2 → 5
Epic 3: Mobile-Optimized Workflows
Hypothesis: We believe that optimizing core workflows for mobile will increase mobile DAU from 5% to 20% because mobile-first users currently can't complete workflows on the go.
Success Metric: Mobile DAU as % of total DAU
Target: 5% → 20%