mcpField
R
roadmap-presentation

roadmap-presentation

github.com/mohitagw15856Productivity1.5k51 installsUpdated 5d ago
Repository

About roadmap-presentation

A product-management skill for shaping roadmaps into strategy narratives rather than feature-and-date lists. It adapts the format and level of detail to executives, cross-functional teams, engineers, or customers.

Key features

  1. 01Audience-calibrated roadmap formats
  2. 02Now / Next / Later planning
  3. 03Strategic context and narrative
  4. 04Explicit deprioritization rationale
  5. 05Success metrics by theme
  6. 06Confidence levels for roadmap horizons

Use cases

  1. 01Presenting strategy to executives
  2. 02Aligning cross-functional teams on dependencies
  3. 03Sharing customer-facing roadmap themes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill roadmap-presentation

After installing, type/roadmap-presentationin Claude Code to confirm it loaded.

Details

From the project README

Roadmap Presentation Skill

Build roadmaps that tell a strategy story — not just a list of features with dates. Every roadmap output is audience-calibrated: executives get outcomes, teams get specificity, customers get value.

Required Inputs

Ask the user for these if not provided:

  • Audience (executive/board, cross-functional, engineering, customers — changes format significantly)
  • Prioritised initiative list with rough timelines or quarters
  • Company OKRs or strategic goals (to anchor the narrative)
  • Period covered (Q1, H1, full year, etc.)

Audience Calibration

Always ask who the audience is before building:

AudienceThey care aboutFormat
Executive / BoardBusiness outcomes, revenue, risk, strategic alignmentOutcome-led, 3 columns (Now / Next / Later), no sprint detail
Cross-functional stakeholdersDependencies, timelines, their team's involvementTheme-based, with dependency callouts
Engineering teamSpecificity, sequencing, technical constraintsDetailed, with epics and rough sizing
Customers / ExternalValue delivered, no internal detailBenefits-focused, no dates — "Coming soon / In progress / Done"

The Now / Next / Later Framework

Standard output structure:

NOW (Current quarter — high confidence, committed)

  • What we're building and why
  • Expected outcomes

NEXT (Following quarter — medium confidence, directional)

  • Themes and initiatives
  • Key hypotheses being tested

LATER (6–12 months — low confidence, aspirational)

  • Strategic bets
  • Dependencies that need to resolve first

⚠️ Never put specific dates on "Later" items. Use quarters or halves.


Roadmap Narrative Template

Every roadmap needs a narrative, not just a timeline. Structure it as:

  1. Where we are — current product state and key metrics
  2. The problem we're solving — what's holding customers or the business back
  3. Our strategic bets — the themes that guide this roadmap
  4. What we're building — Now / Next / Later breakdown
  5. How we'll know it's working — success metrics per theme
  6. What we're not doing — explicit deprioritisation with rationale

Output Format

Product Roadmap — [Product Area] — [Quarter/Year]

Audience: [Executive / Team / Customer] Roadmap Owner: [PM Name] Last Updated: [Date] Confidence Level: Now = High | Next = Medium | Later = Low


Strategic Context:

[2–3 sentences: what company/product goal does this roadmap serve?]

Guiding Themes This Period:

  1. [Theme 1] — [1-line rationale]
  2. [Theme 2] — [1-line rationale]
  3. [Theme 3] — [1-line rationale]

NOW — [Quarter]

ThemeInitiativeOutcome ExpectedTeamStatus
[Theme][What we're building][Metric it moves][Owner]In Progress / Starting

NEXT — [Quarter]

ThemeInitiativeHypothesisDependencies
[Theme][What we plan to build][If we build X, we expect Y][What needs to be true first]

LATER — [H2 / Next Year]

ThemeStrategic BetWhy Later
[Theme][What we might build][What's blocking or uncertain]

What We're NOT Building (and Why):

  • [Requested initiative] — Deprioritised because: [reason]
  • [Requested initiative] — Deprioritised because: [reason]

Success Metrics for This Roadmap:

MetricNow TargetEnd of Year Target
[Metric][X][Y]

Guidelines

  • Never let a roadmap become a commitment list — frame everything outside "Now" as directional
  • Always include a "not doing" section — it prevents the roadmap from becoming a wish list in disguise
  • For executive audiences: lead with the outcome the roadmap delivers to the business, not the features
  • Recommend a roadmap review cadence: monthly for Now items, quarterly for Next/Later
  • If dates are demanded for Later items: use quarters (Q3 2026), not specific dates

Quality Checks

  • Format matches the audience (executives don't get sprint-level detail)
  • NOW items are committed with owners; NEXT items are directional; LATER items are aspirational
  • "What We're NOT Building" section has at least 2 items with rationale
  • Success metrics are specified per theme (not just a list of features)
  • Language is free of internal jargon — tested by asking: "could an external stakeholder understand this?"

Anti-Patterns

  • Do not put specific dates on NEXT or LATER items — use quarters or halves to signal appropriate confidence levels
  • Do not show the same level of detail to executives and engineers — calibrate depth to audience or you lose both
  • Do not omit the "What We're NOT Building" section — a roadmap without explicit deprioritisation becomes a wish list
  • Do not present LATER items as commitments — frame everything outside NOW as directional, not promised
  • Do not skip the success metrics section — without it, stakeholders cannot evaluate whether the roadmap is working

Comments

Markdown supported