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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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].

Extended narrative vision (for internal strategy docs):

## 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:

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 bets
1. [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:

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

Gotchas

1. 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.

2. 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.

3. 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.

4. 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.

5. "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.