mcpField
O
outcome-roadmap

outcome-roadmap

github.com/avelikiyProductivity10841 installsUpdated today
Repository

About outcome-roadmap

A product-management skill that turns feature lists into outcome-focused roadmap statements, using customer value and business impact to clarify why initiatives matter. It is intended for teams and PM agents preparing and refining roadmaps.

Key features

  1. 01Rewrite features as customer and business outcomes
  2. 02Apply a consistent outcome statement formula
  3. 03Group outcomes into strategic themes
  4. 04Validate metrics and strategic alignment
  5. 05Feed outcomes into PM task planning

Use cases

  1. 01Convert a feature roadmap into outcome statements
  2. 02Add measurable goals to planned initiatives
  3. 03Organize five or more outcomes by theme

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/avelikiy/great_cto --skill outcome-roadmap

After installing, type/outcome-roadmapin Claude Code to confirm it loaded.

Details

From the project README

Outcome Roadmap — from features to results

Converts a feature-focused roadmap into an outcome-focused one.

Core principle: Teams build features, but customers and businesses care about outcomes. An outcome roadmap communicates WHAT CHANGES, not what gets built.

The transformation formula

For every initiative on the roadmap, apply:

Enable [customer segment] to [desired customer outcome] so that [business impact]

Examples:

Output (old)Outcome (new)
Q2: Build advanced search filtersQ2: Enable customers to find products 50% faster through intuitive discovery
Q2: AI recommendationsQ2: Increase average order value 20% through personalised recommendations
Q3: Dashboard redesignQ3: Help operators monitor all systems with 80% less time spent on dashboards
Q3: SSO integrationQ3: Remove auth friction for enterprise admins so we can close 3+ enterprise deals
Q4: Mobile appQ4: Enable users to complete core workflows on mobile so 7-day retention increases from 20% to 35%

How to apply

Step 1 — Read the existing roadmap

If the user provides a roadmap file, read it. If they describe it verbally, extract the initiative list.

For each initiative, ask internally:

  • What feature / project is planned?
  • Why are we building it? What changes for customers or the business?
  • What metric will improve, and by how much?
  • Is there a better, different way to achieve the same outcome?
Step 2 — Rewrite each initiative as an outcome

For each item in the roadmap:

  1. Identify the output: What feature or project is planned?
  2. Uncover the outcome: Why are we building it? Keep asking "So what?" until you reach real customer or business value.
  3. Rewrite: Use the formula above. Include a metric if possible.

"So what?" chain example:

  • "We're adding search filters" → So what?
  • "Users can narrow results" → So what?
  • "Users find what they're looking for faster" → So what?
  • "Users convert at higher rates because they find products before abandoning" ✅ That's the outcome.
Step 3 — Group by strategic theme (optional)

If the roadmap has 5+ items, group related outcomes into themes:

  • Retention (outcomes that reduce churn)
  • Acquisition (outcomes that improve conversion)
  • Monetisation (outcomes that increase revenue per user)
  • Ops efficiency (outcomes that reduce internal cost/time)
Step 4 — Output format
## Outcome Roadmap — <Product> <Quarter/Year>

### Strategic context
<1–2 sentences on what the team is optimising for this period>

### Q<N> Outcomes

| Initiative | Outcome Statement | Primary Metric | Target |
|------------|------------------|----------------|--------|
| <original feature name> | Enable [segment] to [outcome] so that [business impact] | <metric> | <target> |

### What we're NOT doing this quarter (and why)
- <deprioritised initiative>: <reason — not enough signal / too early / wrong priority>

### Key assumptions
- <assumption this roadmap depends on — if it's wrong, the outcomes change>
Step 5 — Validate

Before presenting, check:

  • Every outcome has a measurable component (%, number, ratio, frequency)
  • "So what?" has been applied to every item — no pure feature descriptions remain
  • At least one "Not doing" item is stated — otherwise scope is unbounded
  • Outcomes align with stated OKRs or strategic goals in PROJECT.md

Anti-patterns

❌ "We will build X" — that's an output, not an outcome.

❌ "Improve UX" — unmeasurable. Rewrite as: "Reduce time to complete checkout from 4min to 90sec".

❌ Outcome without a metric — if you can't measure it, you can't know if you achieved it.

❌ Outcomes that require building a specific solution — "Enable users to access features via mobile app" locks the solution. Better: "Enable users to complete core workflows on any device".

Integration with pm agent

When the pm agent receives a feature list without a PRD:

  1. Check if the list looks like outputs (feature names) or outcomes (result statements)
  2. If outputs → apply this skill to transform before decomposing into tasks
  3. Pass the outcome statements into the PLAN doc as the "Why" for each task group

Comments

Markdown supported