product-discovery

What this skill does

# Product Discovery

> Build products customers actually want. Apply Marty Cagan's Silicon Valley-tested framework to discover solutions that are valuable, usable, feasible, and viable.

## When to Use This Skill

- **New product development** when validating what to build
- **Feature prioritization** to ensure you're solving real problems
- **Pivot decisions** when current direction isn't working
- **Team alignment** on what problems to solve
- **Risk reduction** before committing development resources
- **Continuous discovery** to maintain product-market fit

## Methodology Foundation

| Aspect | Details |
|--------|---------|
| **Source** | Marty Cagan - Inspired (2008, 2018) and Empowered (2020) |
| **Core Principle** | "Fall in love with the problem, not the solution. The best product teams discover what customers need, not just what they ask for." |
| **Why This Matters** | Most products fail not because they're built poorly, but because they solve the wrong problem. Discovery ensures you build the right thing before you build the thing right. |


## What Claude Does vs What You Decide

| Claude Does | You Decide |
|-------------|------------|
| Structures content frameworks | Final messaging |
| Suggests persuasion techniques | Brand voice |
| Creates draft variations | Version selection |
| Identifies optimization opportunities | Publication timing |
| Analyzes competitor approaches | Strategic direction |

## What This Skill Does

1. **Frames the four risks** - Value, usability, feasibility, viability
2. **Distinguishes discovery from delivery** - Different mindsets, different processes
3. **Teaches opportunity assessment** - Which problems to solve
4. **Develops prototyping skills** - Test ideas before building
5. **Guides customer research** - Learn what customers need (not want)
6. **Structures continuous discovery** - Ongoing learning, not one-time research

## How to Use

### Assess a Product Opportunity
```
I'm considering building [feature/product].
Apply product discovery principles to assess this opportunity.
Context: [target customer, current state, hypothesis]
```

### Reduce Risk Before Building
```
We're about to build [feature].
Help me identify the key risks and design tests to address them.
```

### Set Up Continuous Discovery
```
I want to implement continuous discovery for my product team.
Help me design a weekly discovery rhythm.
```

## Instructions

### Step 1: Understand the Four Risks

```
## The Four Product Risks

Every product idea has four risks to address BEFORE building:

### 1. Value Risk
"Will customers buy/use this?"

**Questions:**
- Does this solve a real problem?
- Is the problem painful enough to pay/switch for?
- Will users actually adopt this?

**Tests:**
- Customer interviews
- Demand testing
- Fake door tests
- Concierge MVP

### 2. Usability Risk
"Can customers figure out how to use it?"

**Questions:**
- Is it intuitive?
- Can users accomplish their goals?
- What's the learning curve?

**Tests:**
- Prototype testing
- Usability studies
- Wizard of Oz tests
- A/B tests on UX

### 3. Feasibility Risk
"Can we build this?"

**Questions:**
- Do we have the technology?
- Can we do it in reasonable time?
- What are the technical dependencies?

**Tests:**
- Technical spike
- Proof of concept
- Architecture review
- Build vs. buy analysis

### 4. Viability Risk
"Should we build this?"

**Questions:**
- Does it fit our strategy?
- Can we support/maintain it?
- Is it legal/compliant?
- Does the business model work?

**Tests:**
- Business case
- Stakeholder review
- Compliance review
- Financial modeling
```

---

### Step 2: Discovery vs. Delivery

```
## Two Tracks: Discovery and Delivery

### Discovery (Figure out WHAT to build)

**Mindset:**
- Embrace uncertainty
- Test assumptions
- Fail fast and cheap
- Learn over deliver

**Activities:**
- Customer interviews
- Prototyping
- Experiments
- Opportunity assessment

**Outcome:**
- Validated problems
- Tested solutions
- Confidence to build
- Clear success metrics

### Delivery (BUILD it right)

**Mindset:**
- Reduce uncertainty
- Execute efficiently
- Ship quality
- Hit timelines

**Activities:**
- Engineering
- QA
- Launch prep
- Documentation

**Outcome:**
- Working software
- Happy customers
- Business impact
- Technical quality

### The Critical Point

Most teams skip discovery and jump to delivery.

**Result:**
- Build features no one wants
- Waste engineering resources
- Miss market opportunities
- Frustrated team, frustrated customers

**The ratio:**
Spend 10-20% of time on discovery to avoid wasting
80-90% of delivery time on wrong things.
```

---

### Step 3: Opportunity Assessment

```
## Assessing Product Opportunities

### The Opportunity Assessment Framework

Before committing to solve a problem, answer:

**1. Is this problem worth solving?**
| Factor | Questions |
|--------|-----------|
| **Frequency** | How often does this problem occur? |
| **Intensity** | How painful is it when it happens? |
| **Willingness** | Will people pay/switch to solve it? |
| **Reach** | How many customers have this problem? |

**Scoring:**
- High frequency + High intensity = Strong opportunity
- Low frequency OR Low intensity = Weak opportunity

**2. Can we solve it effectively?**
| Factor | Questions |
|--------|-----------|
| **Capability** | Do we have the skills/tech? |
| **Fit** | Does it align with our strategy? |
| **Uniqueness** | Can we solve it better than alternatives? |
| **Sustainability** | Can we maintain competitive advantage? |

**3. Should we solve it now?**
| Factor | Questions |
|--------|-----------|
| **Urgency** | Is timing critical? |
| **Resources** | Do we have capacity? |
| **Dependencies** | What else needs to happen first? |
| **Opportunity cost** | What are we NOT doing instead? |

### Opportunity Score Card

```
## Opportunity: [Name]

### Problem Assessment
- Frequency: [1-5]
- Intensity: [1-5]
- Willingness to pay/switch: [1-5]
- Market size: [1-5]
**Problem Score:** [Average]

### Solution Assessment
- Technical feasibility: [1-5]
- Strategic fit: [1-5]
- Competitive advantage: [1-5]
**Solution Score:** [Average]

### Timing Assessment
- Urgency: [1-5]
- Resource availability: [1-5]
**Timing Score:** [Average]

### Overall: [Problem × Solution × Timing = X]

**Recommendation:** [Pursue / Park / Pass]
```
```

---

### Step 4: Discovery Techniques

```
## Core Discovery Techniques

### 1. Customer Interviews

**Purpose:** Understand problems, not validate solutions

**Structure:**
1. Context: Understand their current situation
2. Problem: Explore the pain points
3. Impact: How does it affect them?
4. Current solutions: What do they do today?
5. Ideal state: What would "solved" look like?

**Key rules:**
- Ask about past behavior, not future intentions
- Don't pitch, just listen
- Follow the emotion
- Get specific stories

**Questions:**
- "Walk me through the last time this happened..."
- "What did you do? What happened next?"
- "Why was that a problem?"
- "What would have made it better?"

### 2. Prototyping

**Purpose:** Test solutions before building

**Types:**
| Type | Fidelity | Tests | Time |
|------|----------|-------|------|
| **Paper sketch** | Low | Concepts, flow | Hours |
| **Wireframe** | Low-Med | Structure, navigation | Days |
| **Clickable prototype** | Medium | Usability, flow | Days |
| **Wizard of Oz** | High | Full experience | Weeks |

**Principle:**
Use the lowest fidelity that tests your hypothesis.
Higher fidelity = More time = More risk of attachment.

### 3. Experiments

**Purpose:** Test assumptions with real behavior

**Types:**
- **Fake door:** Button for feature that doesn't exist
- **Smoke test:** Landing page before building
- **Concierge:** Manual delivery of automated value
- **A/B test:** Compare variations with real users

**Structure:**
1. Hypothesis: "We believe [X]"
2. Test: "We will test by [Y]"
3. Metric: "We will measure [Z]"
4. Success: "[Number] indicates we should proceed"

### 4. Oppo