Use this skill when defining product vision, building roadmaps, prioritizing features, or choosing frameworks like RICE, ICE, or MoSCoW. Triggers on product vision, roadmapping, prioritization, RICE scoring, product strategy, feature prioritization, OKRs for product, and any task requiring product direction or planning decisions.
Use this skill when defining product vision, building roadmaps, prioritizing features, or choosing frameworks like RICE, ICE, or MoSCoW. Triggers on product vision, roadmapping, prioritization, RICE scoring, product strategy, feature prioritization, OKRs for product, and any task requiring product direction or planning decisions.
When this skill is activated, always start your first response with the 🧢 emoji.
Product Strategy
A practical framework for defining product vision, building roadmaps, and making
prioritization decisions that compound over time. Product strategy is the connective
tissue between a company's business goals and the day-to-day work of a product team.
Without it, teams ship features that users don't value, roadmaps become wish lists, and
product-market fit erodes without anyone noticing. This skill covers the full strategy
lifecycle: crafting a vision, building outcome-based roadmaps, scoring and sequencing
work with prioritization frameworks, setting OKRs, and communicating direction to
stakeholders. Agents can use this to draft strategy documents, evaluate feature trade-offs,
run scoring sessions, and structure planning artifacts.
When to use this skill
Trigger this skill when the user:
Needs to write or refine a product vision or strategy document
Wants to build or restructure a product roadmap
Is deciding which features to build next or how to sequence work
Asks about RICE, ICE, MoSCoW, or Kano scoring
Needs to write product OKRs or connect features to business outcomes
Is preparing a roadmap presentation for stakeholders or executives
Wants to make a build vs. buy vs. partner decision
Is evaluating product-market fit signals or pivoting direction
Asks about north star metrics or success metrics for a product area
Do NOT trigger this skill for:
Sprint planning mechanics or ticket estimation (use an agile-scrum skill)
Pricing model decisions (use a pricing-strategy skill)
Key principles
Strategy is about saying no - A roadmap that includes every request is not a
strategy, it is a backlog. Every "yes" to one initiative is implicitly "no" to five
others. The clearest signal of a weak strategy is an inability to decline requests
from stakeholders with conviction and data.
Outcome-based roadmaps, not feature lists - Roadmaps organized by features
(build search, add dark mode, create reports) measure output. Roadmaps organized by
outcomes (reduce time-to-value by 40%, increase weekly active usage, improve
onboarding completion) measure impact. Ship outcomes; features are the means, not
the end.
Prioritize ruthlessly - Most teams have 10x more ideas than capacity. The job
of a product leader is not to find ways to do everything - it is to find the 20%
of work that delivers 80% of the impact and protect the team's focus on it.
Validate before building - The most expensive mistake in product is building
something nobody wants. Every assumption in a roadmap should have a cheapest
possible test: a landing page, a prototype, a sales call, a survey. Build only after
validation reduces uncertainty to an acceptable level.
Align product to business goals - Product teams that operate in isolation from
business metrics (revenue, retention, activation) eventually lose organizational
trust and budget. Every major initiative should trace directly to a business outcome
the company cares about. If you cannot draw the line, reconsider the initiative.
Core concepts
Vision / Strategy / Roadmap hierarchy
Vision is the 3-5 year aspirational destination: "What does the world look like
if we succeed?" It is qualitative, inspiring, and stable. It changes rarely.
Strategy is the 12-18 month plan for how you get there: which customer segments,
which problems, which bets. It is directional, not exhaustive.
Roadmap is the quarterly execution plan: which outcomes to drive, which
initiatives to fund, what ships when. It is concrete and frequently updated.
A common mistake is writing a roadmap without a strategy, or a strategy without a
vision. The hierarchy must exist for prioritization decisions to be defensible.
Prioritization frameworks
RICE (Reach, Impact, Confidence, Effort) and ICE (Impact, Confidence, Ease) are
quantitative scoring models that convert gut-feel debates into structured comparisons.
MoSCoW (Must Have, Should Have, Could Have, Won't Have) is a categorization system
used most often for release scoping. Kano maps features to customer satisfaction curves
to distinguish must-haves from delighters. See references/prioritization-frameworks.md
for detailed scoring guides, formulas, and examples.
Product-market fit signals
Strong PMF is characterized by: >40% of users saying they would be "very disappointed"
if the product disappeared (Sean Ellis test), high organic/word-of-mouth growth, strong
retention curves that flatten rather than decay to zero, and sales cycles that shorten
as you refine the pitch. Weak PMF shows as: feature-request-driven roadmaps, high churn
despite onboarding improvements, and a sales team that cannot articulate who the
product is for.
North star metric
A single metric that best captures the core value your product delivers to customers.
It must be a leading indicator of long-term revenue (not revenue itself), it must be
actionable by the product team, and it must be understandable by everyone in the
company. Examples: Slack (messages sent per user per day), Airbnb (nights booked),
Spotify (time spent listening). Choose one. Two north stars create two competing
roadmaps.
Common tasks
Write a product vision statement
A strong vision answers: who are we serving, what problem do we solve, and what does
the world look like when we win?
Template:
For [target customer], who [has this problem or need],
[Product name] is a [product category] that [key benefit / why it's valuable].
Unlike [primary alternative], our product [key differentiator].
## Our Vision
In [timeframe], [company/product] will be [aspirational description of the future state].
[Target customers] will [be able to do / experience] [specific outcome] that was
previously impossible or painful.
We will know we have succeeded when [measurable signal]:
- [Signal 1]
- [Signal 2]
- [Signal 3]
Good vision statements are short (fits on one slide), memorable (team can recite it),
and opinionated (excludes some customers and use cases intentionally).
Build an outcome-based roadmap
Step 1 - Identify themes from strategy
Map each strategic bet to a roadmap theme. A theme is a broad problem area, not a
feature. Examples: "Reduce time-to-first-value," "Improve team collaboration," "Unlock
enterprise segment."
Step 2 - Define outcomes per theme
For each theme, write one measurable outcome: the metric that would move if this theme
is executed well. Outcome = metric + direction + magnitude + timeframe.
Example: "Increase 7-day activation rate from 42% to 60% by Q3."
Roadmap template:
Theme
Outcome target
Key initiatives
Quarter
Status
Activation
7-day activation 42% -> 60%
Onboarding redesign, empty state improvements
Q2
In progress
Collaboration
Teams with 3+ active members +30%
Shared workspaces, @ mentions
Q3
Planned
Enterprise
10 enterprise logos signed
SSO, audit logs, admin dashboard
Q3-Q4
Discovery
Step 3 - Sequence by dependency and impact
Order themes by: does this unblock something else? If yes, pull it earlier. Then order
remaining themes by expected impact on the north star metric.
Prioritize with RICE, ICE, or MoSCoW
Use RICE for quarterly planning with multiple competing initiatives. Use ICE for rapid
triage of a long backlog. Use MoSCoW for scoping a specific release.
RICE scoring:
Score = (Reach x Impact x Confidence) / Effort
- Reach: how many users affected per quarter (number)
- Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
- Confidence: 100% = high, 80% = medium, 50% = low
- Effort: person-months required
ICE scoring (faster, less precise):
Score = Impact x Confidence x Ease (each 1-10)
MoSCoW categorization:
Must Have - release fails without this (legal, core function, blocking user flow)
Should Have - important but not blocking; include if capacity allows
Could Have - nice to have; cut first when scope is tight
Won't Have - explicitly out of scope this cycle (park, do not delete)
For detailed scoring examples and comparison tables, see
references/prioritization-frameworks.md.
Set product OKRs
Product OKRs translate strategy into measurable quarterly commitments.
Structure:
Objective: [Qualitative, inspiring, directional - no metric]
KR1: [Metric] from [baseline] to [target] by [date]
KR2: [Metric] from [baseline] to [target] by [date]
KR3: [Metric] from [baseline] to [target] by [date]
Rules for strong KRs:
Measure outcomes, not outputs ("activation rate increases to 60%" not "ship new
onboarding flow")
Baseline must be known before the quarter starts - never set a KR on a metric you
do not currently measure
70% attainment is success; 100% means the target was too conservative
Max 3 KRs per objective; max 3 objectives per team per quarter
Common anti-pattern: Writing KRs as task lists ("Launch feature X," "Complete Y
project"). These are milestones, not results. Rewrite as: "Feature X drives metric M
to level N."
Create a product strategy document
A one-page product strategy document that stakeholders can read in 5 minutes:
## Product Strategy - [Year / Half]### Context
[1-2 sentences: company stage, market conditions, and what has changed since last cycle]
### Where we play
[Target customer segments and use cases we are optimizing for this period]
### Where we do not play
[Explicit exclusions - segments, use cases, or problems out of scope]
### Strategic bets1. [Bet 1]: [Hypothesis] - if we do X, we expect Y outcome because Z
2. [Bet 2]: [Hypothesis]
3. [Bet 3]: [Hypothesis]
### Key metrics- North star: [metric and current baseline]
- Supporting metrics: [2-3 metrics that feed the north star]
### Risks and assumptions- [Assumption 1] - we will validate by [date] using [method]
- [Assumption 2] - we will validate by [date] using [method]
Make build vs. buy decisions
When evaluating whether to build, buy, or partner for a capability:
Criterion
Build
Buy
Partner
Core differentiator?
Yes
No
No
Time to market critical?
No
Yes
Yes
Internal expertise exists?
Yes
No
Available externally
Long-term maintenance cost
High
Vendor dependent
Shared
Customization required?
Full control
Limited
Negotiable
Decision heuristic:
If the capability is a core differentiator AND you have the expertise: build
If the capability is commodity AND a mature solution exists: buy
If speed matters more than control AND a capable partner exists: partner
Never build what the market commoditizes; never buy what creates lock-in on your
core differentiator
Communicate roadmap to stakeholders
Different audiences require different roadmap formats.
For executives: One-page view. Themes and outcomes only. No feature names. Answers:
"What business problems are we solving and when will we see results?"
For engineering and design: Outcome-first with supporting initiatives. Includes
known dependencies, risks, and confidence level. Answers: "What are we building and
why does it matter?"
For customers: Public roadmap with near-term themes only. Commitments, not dates.
Avoid feature-level specifics that constrain design. Answers: "Is this team moving in
a direction I trust?"
For sales and customer success: Near-term deliverables with anticipated dates.
Include enterprise-specific items. Answers: "What can I promise to prospects this
quarter?"
Anti-patterns
Anti-pattern
Why it fails
What to do instead
Roadmap as a feature wish list
Treats output as success; teams ship but metrics do not move
Reframe each initiative as an outcome with a target metric
Prioritizing by loudest stakeholder
Recency and seniority bias override user impact and data
Score every request with RICE or ICE before any commitment
Annual roadmap with no updates
Markets change; a frozen roadmap becomes fiction by Q3
Review and reforecast roadmap quarterly; update stakeholders
Skipping discovery to ship faster
Builds the wrong thing faster; sunk cost forces bad decisions
Run a 1-2 week discovery sprint before committing to any major initiative
Copying competitor features
Optimizes for the competitor's strategy, not your users
Start with your own user research; competitor features are signals, not specs
Treating OKRs as a task list
Measures effort, not impact; creates busywork culture
Write KRs as metric movements, not deliverables; review weekly
Gotchas
RICE scores treated as absolute truth - RICE produces a number, but the inputs (Reach, Confidence, Effort) are estimates. Teams often stop debating once the spreadsheet exists. Treat RICE as a structured conversation starter, not a decision oracle - challenge the inputs, not just the outputs.
Vision written for the all-hands, not the team - Inspirational vision statements that sound good in a company meeting often give zero guidance on what to build. A vision that can't help a PM decline a feature request has failed its job.
OKRs that are actually task lists - The most common mistake is writing KRs as deliverables ("ship search feature") rather than metric movements. When asked to write OKRs, explicitly check every KR: can you achieve it without the metric moving? If yes, rewrite it.
Roadmap shared at the feature level with executives - Executives reading feature-level roadmaps immediately start adding items. Share outcomes-only views with execs; reserve feature-level detail for engineering and design.
"Won't Have" items deleted instead of parked - MoSCoW's Won't Have bucket is a deliberate parking lot. Deleting items means they reappear as new requests next quarter. Always keep the Won't Have list visible and reference it when similar requests arrive.
References
For detailed scoring guides, formulas, and worked examples:
references/prioritization-frameworks.md - RICE, ICE, MoSCoW, and Kano with
step-by-step examples, comparison tables, and guidance on when to use each
Only load the references file when the task requires scoring or framework selection -
it is detailed and will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
