Help us improve
Share bugs, ideas, or general feedback.
From great_cto
Transforms feature-list roadmaps into outcome-focused ones by rewriting initiatives as user and business impact statements. Use when a roadmap lists outputs instead of results.
npx claudepluginhub avelikiy/great_ctoHow this skill is triggered — by the user, by Claude, or both
Slash command
/great_cto:outcome-roadmapWhen to use
Apply when: - CTO provides a feature list and asks "what should we do next quarter" - pm agent receives a roadmap full of features, not outcomes - stakeholders need to understand why we're building things, not just what - a roadmap review reveals it lists outputs (features) but not outcomes (results) Guards — do NOT apply when: - The input already states outcomes with metrics - This is a single-feature PRD (use /prd instead)
docs/plans/**docs/requirements/**This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Converts a feature-focused roadmap into an outcome-focused one.
Transforms output-focused roadmaps into outcome-focused ones by rewriting initiatives as measurable statements of user/business impact. Useful for strategic alignment or feature list rewrites.
Transforms a prioritized initiative list into a strategic roadmap narrative with themes, quarter progression, executive summary, and 'what's not on the roadmap' section. For communicating product direction to non-technical stakeholders.
Share bugs, ideas, or general feedback.
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.
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 filters | Q2: Enable customers to find products 50% faster through intuitive discovery |
| Q2: AI recommendations | Q2: Increase average order value 20% through personalised recommendations |
| Q3: Dashboard redesign | Q3: Help operators monitor all systems with 80% less time spent on dashboards |
| Q3: SSO integration | Q3: Remove auth friction for enterprise admins so we can close 3+ enterprise deals |
| Q4: Mobile app | Q4: Enable users to complete core workflows on mobile so 7-day retention increases from 20% to 35% |
If the user provides a roadmap file, read it. If they describe it verbally, extract the initiative list.
For each initiative, ask internally:
For each item in the roadmap:
"So what?" chain example:
If the roadmap has 5+ items, group related outcomes into themes:
## 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>
Before presenting, check:
❌ "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".
When the pm agent receives a feature list without a PRD: