product-discovery

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