git:20260729.5b86b60 to git:20260729.4a3a4d0

---

name: outcome-roadmap

description: "Transform an output-focused roadmap into an outcome-focused one that communicates strategic intent. Rewrites initiatives as outcome statements reflecting user and business impacts. Use when shifting to outcome roadmaps, making a roadmap more strategic, or rewriting feature lists as outcomes."

---

## Codex host binding

- Treat references to Claude slash workflows as the equivalently named Codex skill.

- Resolve bundled paths from the installed GreatPM plugin root.

- Ignore Claude-only model aliases, colors, turn limits, and tool allowlists.

- Preserve GreatPM human gates, governance, state, and reporting contracts.

# Transform Roadmap to Outcome-Focused Format

## Purpose

You are an experienced product manager helping $ARGUMENTS shift from output-focused roadmaps (which emphasize features) to outcome-focused roadmaps (which emphasize customer and business impact). This skill rewrites initiatives as outcome statements that inspire and measure what matters.

## Context

Output-focused roadmaps create false precision and misalign teams around features rather than results. Outcome-focused roadmaps clarify the customer problems being solved and the business value expected, enabling flexible execution and strategic thinking.

## Instructions

1. **Gather Information**: If the user provides a current roadmap, read it carefully. If they mention strategy documents or company objectives, use web search to understand how the roadmap should align with broader goals.

2. **Think Step by Step**:

- For each initiative, ask: "What outcome are we trying to achieve?"

- What customer problem are we solving?

- What business metric will improve?

- How will this impact the customer experience or business?

- Is there a better, different way to achieve the same outcome?

3. **Transformation Process**: For each initiative on the roadmap:

- **Identify the Output**: What feature or project is planned?

- **Uncover the Outcome**: Why are we building it? What changes for customers or business?

- **Rewrite as Outcome Statement**: Use this format:

```

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

```

4. **Example Transformation**:

- **Output (Old)**: Q2: Build advanced search filters, implement AI recommendations, redesign dashboard

- **Outcome (New)**:

- Q2: Enable customers to find products 50% faster through intuitive discovery

- Q2: Increase average order value by 20% through personalized AI recommendations

- Q2: Help operators monitor all systems with 80% reduction in dashboard load time

5. **Structure Output**: Present the transformed roadmap with:

- Original initiatives listed by quarter/phase

- Outcome statements for each initiative

- Key metrics that will indicate success

- Dependencies or sequencing notes

6. **Include Strategic Context**: For the overall roadmap, add:

- How outcomes align with company strategy

- Key assumptions about customer needs

- Flexible release windows (quarters, not specific dates)

7. **Save the Output**: If substantial, save as a markdown document: `Outcome-Roadmap-[year].md`

## Notes

- An outcome should be testable and measurable

- Multiple outputs may achieve one outcome; focus on the outcome, not the feature list

- Outcome roadmaps are more resilient to change—embrace flexibility

- If unsure what outcome a feature drives, ask: "So what?" until you reach real customer/business value

## Worked example — Acme.ai Q3 roadmap (failed vs good outcome)

**Output-focused starting point (what a feature list looks like):**

> Q3: Build SMS-parsing import, add multi-account sync, ship spending-insights tab.

**The naive "outcome" rewrite — which is still a fake outcome (DON'T ship this):**

> Q3: *Enable users to better manage their finances through smart insights.*

Why this fails the bar:

- **Unmeasurable.** "Better manage their finances" has no metric, no baseline, no

target. You cannot tell at end-of-quarter whether you hit it.

- **Outcome theater.** It *sounds* outcome-y ("enable users to…") but it's an

un-instrumented aspiration. It's a feature list wearing an outcome costume.

- **No instrumentation today.** Acme doesn't currently track "financial

management quality," so this outcome can't be observed even if achieved.

**The real outcome version (ship this):**

> Q3: **Increase the share of new users who reach their first auto-categorized

> view within 3 minutes from 35% → 60%** — because that activation moment is the

> #1 predictor of week-1 retention.

>

> *Possible deliverables (options, not commitments):* SMS-parse pre-fill,

> faster PDF parse, WhatsApp-OTP fallback. Whichever moves activation fastest wins.

Why this passes:

- **Measurable today.** "% reaching first categorized view in <3 min" is an event

Acme can instrument now (see `metrics-design`), with a real baseline (35%).

- **Decoupled from the feature.** Three different deliverables could hit it; the

roadmap commits to the *number*, not the build.

- **Falsifiable.** At end-of-Q3 you know unambiguously whether 60% was reached.

The discipline: if you can't state the metric, the baseline, the target, and the

instrumentation that already exists, you don't have an outcome — you have a slogan.

## When NOT to use this skill

- **Pre-PMF / early discovery.** When you don't yet know *which* outcomes matter,

forcing outcome statements produces confident fiction. At this stage a feature/

experiment roadmap ("test these 3 bets") is the honest level — you're searching

for the outcome, not optimizing it. Switch to outcomes once discovery names the

metric that matters.

- **The outcome can't be measured yet.** An outcome with no instrumentation is

unfalsifiable. Either build the tracking first (`metrics-design`) or roadmap the

instrumentation itself as the deliverable — don't roadmap an outcome you can't observe.

- **Hard external commitments / dependencies.** Compliance deadlines, partner

integrations, App Store requirements are genuinely output-shaped ("ship RBI

e-mandate flow by date X"). Don't contort a deadline into an outcome; list it as

the commitment it is.

- **Tiny team, one obvious next thing.** If there's a single forced next build,

an outcome roadmap is overhead. Just build it.

## Pitfalls / failure modes

1. **Fake outcomes / outcome theater.** The headline trap. Statements that *sound*

like outcomes ("delight users", "enable better decisions") but carry no metric,

baseline, or target. Test: can you write the success number and read it off a

dashboard? If not, it's a slogan. This is the single most common roadmap PM failure.

2. **Ghost outcomes (no instrumentation).** An outcome that's measurable in

principle but not actually tracked in the product. You'll reach end-of-quarter

with no way to know if you hit it. Pair every outcome with the event/metric that

already exists, or roadmap the instrumentation first.

3. **Vanity-metric outcomes.** "Increase total signups by 40%" when signups don't

tie to value or revenue. The number can move while the business doesn't. Tie

outcomes to North Star / retention / revenue, not to flattering counts.

4. **"Enable users to…" padding.** Wrapping a feature in outcome grammar without

doing the work. "Enable users to upload statements" is just "build upload" with

a costume. The real outcome is what changes *because* they can upload.

5. **Output smuggled back in as the success metric.** Listing "shipped SMS-parse"

as the KR. Shipping is an output; the outcome is what shipping caused (activation

↑). If your success criterion is "did we build it," you've reverted to an output roadmap.

6. **Date-precise outcome roadmaps.** Pinning outcomes to exact dates re-imports the

false precision outcome roadmaps exist to escape. Use quarters / Now-Next-Later

windows, not "Aug 14."

## Relationship to other great-pm skills

- **`impact-mapping`** — the upstream derivation. Impact mapping traces Goal →

Actor → Impact → Deliverable; an outcome-roadmap outcome *is* the goal/impact

layer, and the deliverables under it are exactly impact-mapping's bottom tier.

When unsure which deliverables serve an outcome, run an impact map first.

- **`metrics-design`** — the gate that keeps outcomes honest. Every outcome must be

measurable *today*; metrics-design defines the North Star, the instrumentation

events, and the thresholds that turn a slogan into a falsifiable outcome.

- **`brainstorm-okrs`** — an outcome roadmap and an OKR set are two views of the

same thing: the outcome becomes the Objective; its target metric becomes the Key

Result. Use brainstorm-okrs to pressure-test for sandbagging and output-disguised-as-outcome.

- **`prioritization-methods`** — once outcomes are set, the candidate deliverables

under each are ranked here to decide sequencing.

---

### Further Reading

- [Product Vision vs Strategy vs Objectives vs Roadmap: The Advanced Edition](https://www.productcompass.pm/p/product-vision-strategy-goals-and)

- [Objectives and Key Results (OKRs) 101](https://www.productcompass.pm/p/okrs-101-advanced-techniques)

- [Business Outcomes vs Product Outcomes vs Customer Outcomes](https://www.productcompass.pm/p/business-outcomes-vs-product-outcomes)