By name: pm-roadmap-frameworks description: "Internal skill. Use cc-p4p-router for all PM tasks." allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
PM Roadmap Frameworks
Overview
Expert knowledge for product roadmap planning, prioritization, and communication. Provides frameworks for building roadmaps that are strategic, realistic, and actionable.
The Iron Law
NO ROADMAP WITHOUT SCORING CRITERIA AND EXPLICIT TRADEOFFS
Every roadmap item must be scored with a framework. Every prioritization must show what was traded off. Roadmaps without scoring are wish lists. Roadmaps without tradeoffs are fantasies.
When to Use
- Building or updating a product roadmap
- Prioritizing features or initiatives
- Choosing between competing priorities
- Communicating roadmap changes to stakeholders
- Mapping dependencies across teams
Roadmap Formats
Now / Next / Later
The simplest and often most effective format:
- Now (current sprint/month): Committed work. High confidence. Team is actively building.
- Next (1-3 months): Planned work. Good confidence in what, less in exactly when.
- Later (3-6+ months): Directional. Strategic bets, flexible scope and timing.
When to use: Most teams, most of the time. Avoids false precision on dates. Good for external/leadership communication.
Quarterly Themes
Organize around 2-3 themes per quarter:
- Each theme = strategic investment area (e.g., "Enterprise readiness", "Activation improvements")
- Under each theme, list specific initiatives
- Themes map to company/team OKRs
- Makes it easy to explain WHY you're building what you're building
When to use: Showing strategic alignment. Planning meetings. Executive communication.
OKR-Aligned Roadmap
Map items directly to Objectives and Key Results:
- Start with team's OKRs
- Under each Key Result, list initiatives that move that metric
- Include expected impact per initiative
- Creates clear accountability
When to use: OKR-driven organizations. Ensuring every initiative has measurable "why".
Timeline / Gantt View
Calendar-based with start dates, end dates, durations:
- Shows parallelism and sequencing
- Good for identifying resource conflicts and dependencies
- NOT good for external communication (creates false precision)
When to use: Execution planning with engineering. Scheduling conflicts. Never for external comms.
Prioritization Frameworks
RICE Score
RICE = (Reach x Impact x Confidence) / Effort
| Dimension | Definition | Scale |
|---|---|---|
| Reach | Users affected in time period | Concrete number (e.g., 500/quarter) |
| Impact | Needle movement per user | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
| Confidence | Estimate reliability | 100%=data-backed, 80%=some evidence, 50%=gut feel |
| Effort | Person-months of work | Include eng, design, all functions |
When to use: Quantitative, defensible prioritization. Large backlogs. Less good for strategic bets where impact is hard to estimate.
MoSCoW
| Category | Definition | Rule |
|---|---|---|
| Must | Non-negotiable. Roadmap fails without these. | Would we not ship without this? |
| Should | Important but not critical for launch. | High-priority fast follows. |
| Could | Desirable if capacity allows. | Won't delay if cut. |
| Won't | Explicitly out of scope this period. | Important for clarity. |
When to use: Scoping a release/quarter. Forcing prioritization conversations with stakeholders.
ICE Score
ICE = Impact x Confidence x Ease (each scored 1-10)
| Dimension | Definition |
|---|---|
| Impact | How much will this move the target metric? |
| Confidence | How sure are we about the impact? |
| Ease | How easy to implement? (inverse of effort -- higher=easier) |
When to use: Quick prioritization. Early-stage products. Not enough data for RICE.
Value vs Effort Matrix
Plot on 2x2:
| Low Effort | High Effort | |
|---|---|---|
| High Value | Quick Wins -- Do first | Big Bets -- Plan carefully |
| Low Value | Fill-ins -- Spare capacity | Money Pits -- Don't do |
When to use: Visual prioritization in team sessions. Building shared understanding.
Dependency Mapping
Identifying Dependencies
| Type | Example |
|---|---|
| Technical | Feature B requires infrastructure from Feature A |
| Team | Needs work from another team (design, platform, data) |
| External | Waiting on vendor, partner, or third-party |
| Knowledge | Need research results before starting |
| Sequential | Must ship A before starting B |
Managing Dependencies
- List all dependencies explicitly in roadmap
- Assign owner to each
- Set "need by" date
- Build buffer -- dependencies are highest-risk items
- Flag cross-team dependencies early
- Have contingency plan for slips
Reducing Dependencies
- Build simpler version that avoids the dependency
- Parallelize using interface contracts or mocks
- Sequence differently to move dependency earlier
- Absorb work into your team to remove coordination
Capacity Planning
Estimating Capacity
- Start with team size x time period
- Subtract overhead: meetings, on-call, interviews, PTO
- Rule of thumb: 60-70% time on planned feature work
- Factor ramp time for new members
Healthy Allocation
| Category | % | Description |
|---|---|---|
| Planned features | 70% | Roadmap items advancing strategic goals |
| Technical health | 20% | Tech debt, reliability, performance |
| Unplanned | 10% | Buffer for urgent issues, quick wins |
Adjust based on context:
- New product: more features, less tech debt
- Mature product: more tech debt investment
- Post-incident: more reliability
- Rapid growth: more scalability
Capacity vs Ambition
- If roadmap exceeds capacity: cut scope, don't pretend people can do more
- When adding: ask "What comes off?"
- Commit to fewer things and deliver reliably
Communicating Changes
When Roadmap Changes
- New strategic priority from leadership
- Customer feedback changes priorities
- Technical discovery changes estimates
- Dependency slip from another team
- Resource change (team grows/shrinks)
How to Communicate
- Acknowledge the change directly
- Explain the reason (new information)
- Show the tradeoff (what was deprioritized)
- Show the new plan
- Acknowledge impact on affected stakeholders
Avoiding Whiplash
- Don't change for every new input -- have threshold
- Batch updates at natural cadences unless truly urgent
- Distinguish "strategic reprioritization" from "normal execution refinement"
- Track change frequency -- frequent changes may signal unclear strategy
Red Flags — STOP
- Prioritizing without a framework → STOP. Pick RICE, MoSCoW, or ICE. Gut feel is not a method.
- All items in "Now" bucket → STOP. If everything is Now, nothing is prioritized.
- No dependencies mapped → STOP. Untracked dependencies are the #1 roadmap killer.
- Roadmap exceeds capacity with no cuts → STOP. Cut scope or extend timeline. Don't pretend.
- Using Timeline/Gantt for external comms → STOP. Creates false precision. Use Now/Next/Later.
- Items have no strategic alignment → STOP. Every item must trace to a goal or OKR.
Rationalization Prevention
| Excuse | Reality |
|---|---|
| "We don't need a framework, I know what's important" | Frameworks force conversations, not just decisions. Stakeholders need to see your reasoning. |
| "We'll fit it all in" | Capacity is finite. Adding without removing is lying to your team. |
| "Dependencies will work themselves out" | They won't. Track them or get surprised. |
| "We can't score this, it's strategic" | Strategic items need scoring too — use Confidence to express uncertainty. |
| "Dates don't matter, we're agile" | Stakeholders need directional timing. Now/Next/Later avoids false precision. |
| "Let's just start and see" | Starting without priorities means working on the wrong thing first. |
| "The team knows what to do" | Implicit priorities cause conflicting work. Make it explicit. |
| "We'll reprioritize next quarter" | If priorities are wrong now, waiting costs a quarter of effort. |