THE ONLY ENTRY POINT FOR CC-P4P. This skill MUST be activated for ANY product management task - never skip. Use this skill when: writing specs, synthesizing research, planning roadmaps, drafting stakeholder updates, defining metrics, or ANY PM request. Triggers: spec, prd, feature, requirement, user story, acceptance criteria, research, interview, feedback, survey, competitive, persona, insight, roadmap, priority, plan, timeline, rice, moscow, okr, quarter, update, status, stakeholder, announcement, launch, report, metric, kpi, dashboard, retention, conversion, north star, product, pm, brainstorm. CRITICAL: Execute workflow immediately. Never just describe capabilities.
Internal skill. Use cc-p4p-router for all PM tasks.
Internal skill. Use cc-p4p-router for all PM tasks.
Internal skill. Use cc-p4p-router for all PM tasks.
Internal skill. Use cc-p4p-router for all PM tasks.
Internal skill. Use cc-p4p-router for all PM tasks.
| name | pm-roadmap-frameworks |
| description | Internal skill. Use cc-p4p-router for all PM tasks. |
| allowed-tools | Read, Write, Edit, Bash, AskUserQuestion |
Expert knowledge for product roadmap planning, prioritization, and communication. Provides frameworks for building roadmaps that are strategic, realistic, and actionable.
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.
The simplest and often most effective format:
When to use: Most teams, most of the time. Avoids false precision on dates. Good for external/leadership communication.
Organize around 2-3 themes per quarter:
When to use: Showing strategic alignment. Planning meetings. Executive communication.
Map items directly to Objectives and Key Results:
When to use: OKR-driven organizations. Ensuring every initiative has measurable "why".
Calendar-based with start dates, end dates, durations:
When to use: Execution planning with engineering. Scheduling conflicts. Never for external comms.
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.
| 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 = 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.
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.
| 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 |
| 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:
| 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. |