product-strategy

---
name: product-strategy
version: 0.1.0
description: >
  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.
tags: [product-strategy, roadmap, prioritization, rice, vision, planning, strategy]
category: product
recommended_skills: [product-discovery, competitive-analysis, product-analytics, user-stories]
platforms:
  - claude-code
  - gemini-cli
  - openai-codex
license: MIT
maintainers:
  - github: maddhruv
---

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

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

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

| 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

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.

---

## 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:
> ```
> npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>
> ```
> Skip entirely if `recommended_skills` is empty or all companions are already installed.