roadmap-planning skill

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:

1. Gathering inputs — Customer problems, business goals, technical constraints
2. Defining initiatives — Epics with clear hypotheses and success metrics
3. Prioritizing — Rank initiatives by impact, effort, strategic fit
4. Sequencing — Organize into releases/quarters with logical dependencies
5. 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)
• Questions:
• What are the top 3-5 customer pain points?
• Which problems affect the most customers?
• Which problems have highest intensity?
• Output: 3-5 validated customer problems

3. Review Technical Constraints & Opportunities

• Source: Engineering leadership, tech debt assessments
• Questions:
• Are there technical blockers? (scaling, performance, security)
• Are there enabling investments? (platform upgrades, API rewrites)
• What's the technical roadmap? (migrations, deprecations)
• Output: List of technical investments required

4. Review Stakeholder Requests

• Source: Sales, marketing, customer success, execs
• Questions:
• What are sales asking for? (enterprise features, integrations)
• What's marketing requesting? (growth initiatives, positioning)
• What's customer success flagging? (churn risks, expansion blockers)
• 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%

2. Estimate Effort (T-Shirt Sizing)

• Participants: PM + engineering lead
• Duration: 90 minutes
• Method:
• Small (S): 1-2 weeks (1-2 engineers)
• Medium (M): 3-4 weeks (2-3 engineers)
• Large (L): 2-3 months (3-5 engineers)
• Extra Large (XL): 3+ months (5+ engineers)
• Output: Effort estimate per epic

3. Map to Business Outcomes