Purpose
Turn discovery findings and stakeholder needs into a phased IT product roadmap with a clear vision, scoped releases, quarterly milestones, and measurable adoption and success KPIs. Solves the gap between "we know we need to build something" and a roadmap leadership will fund and teams can execute.
When to Use
Invoke this skill when the user asks to:
- Build a product roadmap for an internal tool or post-sales technology platform
- Translate user interviews and discovery notes into a scoped delivery plan
- Define a product vision and phase releases across quarters
- Set adoption metrics and success KPIs for a new IT product
- Prioritize a backlog of features into MVP, fast-follow, and future waves
- Align stakeholders around what ships when and how success is measured
Inputs Required
Before starting, collect:
- Product area: What the product is (e.g., customer onboarding portal, support automation platform, renewals dashboard)
- Primary users: Who uses it — internal teams, customers, or both — and their core jobs-to-be-done
- Discovery inputs: User interview themes, pain points, or research notes available (paste or summarize)
- Business objective: The outcome this product must drive (reduce handoff time, cut ticket volume, increase renewal rate, etc.)
- Time horizon: Planning window — typically 2, 3, or 4 quarters
- Constraints: Team size, budget, integration dependencies, compliance or security requirements
- Existing systems: What tools this replaces, integrates with, or coexists alongside
If discovery inputs are thin, synthesize plausible pain points from the stated user and objective, and flag them as assumptions to validate.
Instructions
Step 1: Synthesize Discovery Findings
Convert raw inputs into structured findings.
- Cluster user interview themes into 3–5 core problem statements, each phrased as "[User] struggles to [job] because [obstacle], which causes [business impact]"
- Rank problems by frequency × severity × strategic fit (High / Medium / Low each)
- Identify the 1–2 problems the product must solve first — the ones blocking the business objective
- Note explicit evidence behind each problem (interview quote pattern, metric, or observed workflow); mark any problem without evidence as "assumption — validate"
Step 2: Define the Product Vision
Write a vision that gives the roadmap a destination.
- Vision statement: 1–2 sentences describing the future state once the product succeeds. Concrete, not aspirational filler.
- Target user + core value: Who benefits and the one thing they can now do that they couldn't before
- Strategic north star metric: The single metric that proves the vision is being realized (e.g., time-to-onboard, self-serve resolution rate)
- Non-goals: 2–3 things this product explicitly will NOT do — to protect scope
Step 3: Scope Into Release Waves
Divide the work into three delivery waves.
Wave 1 — MVP (must-have to prove value)
- The smallest set of capabilities that solves the top-ranked problem end-to-end
- Each capability stated as an outcome, not a feature ("users self-serve renewal quotes" not "build quote UI")
- 4–7 capabilities maximum
Wave 2 — Fast-Follow (deepen and expand)
- Capabilities that extend adoption, add efficiency, or serve the second-ranked problem
- Dependencies on Wave 1 noted explicitly
Wave 3 — Future (differentiate and scale)
- Higher-effort or lower-certainty bets — automation, analytics, integrations, personalization
- Mark which items are "committed" vs. "candidate — revisit after Wave 2 data"
For each wave, tag every capability with Effort (S/M/L) and Impact (High/Med/Low).
Step 4: Sequence Into Quarterly Milestones
Map waves onto the time horizon.
- Assign each wave to quarters based on effort and team capacity
- For each quarter, define: theme (one phrase), shipped capabilities, key dependency or risk, and the decision or learning that gates the next quarter
- Include a discovery/validation task in every quarter — roadmaps that stop learning drift
Step 5: Define Adoption Metrics
Set metrics that prove people actually use it.
- Activation: The first meaningful action a user takes (define it precisely)
- Adoption: % of target users active in a defined window, with a target and timeline
- Engagement: Frequency or depth signal that indicates the product is habitual
- Friction signal: A drop-off or abandonment metric to watch — where users get stuck
Step 6: Define Success KPIs
Tie the roadmap back to the business objective.
- Primary KPI: The business outcome metric from Step 2's north star, with baseline (or "establish baseline") and target
- 2–3 supporting KPIs: Leading or efficiency indicators that ladder up to the primary
- Measurement cadence: What is reviewed weekly, monthly, and quarterly
- Success threshold per wave: What each wave must achieve before proceeding to the next
Output Format
- Structure: Six sections in order, with problem findings and release waves in tables, milestones in a quarter-by-quarter breakdown
- Length: 1,000–1,400 words
- Format: Structured document — tables for findings, waves, and KPIs; prose for vision; timeline layout for milestones
- Sections: Discovery Findings → Product Vision → Release Waves (MVP / Fast-Follow / Future) → Quarterly Milestones → Adoption Metrics → Success KPIs
- Tone: Product manager writing for leadership and delivery teams — evidence-led, decisive, no filler. Every priority call is justified.
Quality Checklist
Before delivering output, verify:
- [ ] Every core problem statement follows the "user / job / obstacle / impact" structure and is ranked
- [ ] Any problem lacking evidence is flagged "assumption — validate"
- [ ] The vision includes explicit non-goals (at least 2)
- [ ] Wave 1 capabilities solve the top-ranked problem end-to-end and number 7 or fewer
- [ ] Every capability across all waves is tagged with Effort and Impact
- [ ] Each quarter names a gating decision or learning, plus a validation task
- [ ] Adoption metrics and success KPIs each include a target and measurement cadence
Notes
- The most common failure is an MVP that's a collection of features rather than one problem solved completely — pressure-test Wave 1 against "does this fully solve the top problem for one user?"
- If the business objective and the north star metric don't clearly connect, the roadmap will lose executive support — resolve that link before scoping.
- Adoption metrics matter more than ship dates for internal IT products; a shipped tool nobody uses is a failed roadmap, so weight the plan toward activation and friction removal.
- When constraints are severe (small team, hard deadline), compress by cutting Wave 3 scope, not by rushing Wave 1 quality.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills