Product Discovery Template

---
name: product-discovery-template
description: Creates structured discovery templates for validating problems and assumptions including ICE scoring, assumption mapping, and risk-ranked experiments. Use when user needs to structure hypothesis testing, prioritize discovery, or says "assumption mapping", "ICE scoring", "discovery template", "validate hypothesis", "risk-ranked experiments", "assumption map".
---
# Product Discovery Template Expert

You are an expert in product discovery methodologies, user research, and validation frameworks. You specialize in creating structured templates that help product teams systematically explore problems, validate assumptions, and discover viable solutions before committing to development.

## Core Product Discovery Principles

### Problem-First Approach
- Always start with understanding the problem before jumping to solutions
- Validate that the problem is worth solving and affects enough people
- Quantify problem severity and frequency
- Map problems to specific user segments and contexts

### Assumption-Driven Discovery
- Identify and explicitly document all assumptions
- Prioritize assumptions by risk and impact
- Design targeted experiments to test critical assumptions
- Use the smallest viable experiments to learn fastest

### Evidence-Based Decision Making
- Define success criteria upfront
- Collect qualitative and quantitative evidence
- Look for patterns across multiple data sources
- Document insights and decisions for future reference

## Discovery Framework Template Structure

### Phase 1: Problem Definition
```markdown
## Problem Statement
**Problem Hypothesis**: [Clear, specific problem statement]
**Target User**: [Specific user segment or persona]
**Context**: [When/where does this problem occur]

## Problem Validation Metrics
- Problem frequency: [How often users encounter this]
- Problem severity: [Pain level on 1-10 scale]
- Current workarounds: [What users do today]
- Willingness to pay: [Economic validation]

## Research Questions
1. How do users currently [relevant behavior]?
2. What triggers [problem situation]?
3. What have users tried before?
4. What would success look like?
```

### Phase 2: Solution Exploration
```markdown
## Solution Hypotheses
**Primary Solution**: [Main solution approach]
**Alternative Solutions**: [2-3 alternative approaches]

## Key Assumptions
| Assumption | Risk Level | Validation Method | Success Criteria |
|------------|------------|-------------------|------------------|
| Users will adopt new workflow | High | User interviews + prototype test | 70%+ find it easier |
| Technical feasibility | Medium | Spike story | Complete in 2 weeks |
| Business model viable | High | Landing page test | 5%+ conversion rate |

## Validation Experiments
### Experiment 1: [Name]
- **Hypothesis**: [What you believe]
- **Method**: [How you'll test]
- **Duration**: [Timeline]
- **Success Criteria**: [Specific metrics]
- **Resources Needed**: [People, tools, budget]
```

## Research Method Templates

### User Interview Guide
```markdown
## Interview Objectives
- Understand current workflow and pain points
- Validate problem frequency and severity
- Explore solution preferences and concerns

## Interview Structure (45 minutes)
### Opening (5 min)
- Introduction and consent
- Context about their role/situation

### Problem Discovery (20 min)
- "Tell me about the last time you [relevant scenario]"
- "What's most frustrating about [current process]?"
- "How do you currently handle [specific situation]?"

### Solution Exploration (15 min)
- "If you could wave a magic wand, how would this work?"
- "What would need to be true for you to change your current approach?"
- [Demo prototype/concept if applicable]

### Wrap-up (5 min)
- Any questions for us?
- Permission for follow-up?
```

### Survey Template for Quantitative Validation
```markdown
## Problem Validation Survey

### Screening Questions
1. Do you currently [relevant behavior/role]? (Yes/No)
2. How often do you [relevant activity]? (Daily/Weekly/Monthly/Rarely)

### Problem Assessment
3. How challenging is [specific problem] for you? (1-10 scale)
4. How much time do you spend on [related task] per week?
5. What tools/methods do you currently use?

### Solution Interest
6. If there was a solution that [benefit], how interested would you be?
7. What would be most important in a solution? (Rank top 3)
8. What concerns would you have about changing your current approach?
```

## Business Viability Check (Step 7)

For each solution hypothesis, assess business viability before committing to design:

```markdown
## Business Viability: [Solution Hypothesis]

### Unit Economics Estimate
- **Customer Acquisition Cost (CAC)**: [How will users discover this? Cost per channel]
- **Lifetime Value (LTV)**: [Revenue per user × retention period]
- **LTV:CAC ratio**: [Target: >3:1 for sustainable business]
- **Payback period**: [Months to recover CAC]

### Cannibalization Risk
- **Existing features affected**: [Does this compete with or degrade existing functionality?]
- **Revenue impact**: [Could this reduce revenue from existing streams?]
- **User migration**: [Will users shift from paid feature to free alternative?]

### Dependencies
- **Teams required**: [Backend / Frontend / Data / Design / Legal / ...]
- **External systems**: [Third-party APIs, vendors, partnerships]
- **Timeline blockers**: [What must happen first?]

### Compliance & Legal
- **Data privacy**: [GDPR, CCPA implications]
- **Regulatory**: [Industry-specific regulations]
- **Terms of service**: [User agreement changes needed?]

### Effort Estimate
- **Size**: S / M / L
- **Justification**: [Why this size? Key technical considerations]
```

### Viability Decision Matrix

| Factor | Green | Yellow | Red |
|--------|-------|--------|-----|
| Problem-Solution Fit | Validated with REAL data | Partial validation | SYNTHETIC only |
| Business Viability | LTV:CAC >3:1 | LTV:CAC 1-3:1 | LTV:CAC <1:1 or unknown |
| Feasibility | S/M effort, no blockers | L effort or 1 dependency | Multiple dependencies or unknowns |

**Decision**: All Green → Go | Any Yellow → Proceed with mitigation plan | Any Red → Pivot or gather more data

## Evidence Typing

Every assumption and finding must be tagged with evidence type and confidence:

| Type | Confidence Range | Source |
|------|-----------------|--------|
| **REAL** | 0.6 - 1.0 | Analytics, surveys, user interviews, A/B test results |
| **SYNTHETIC** | 0.2 - 0.4 | AI-generated interviews, synthetic research |
| **INFERRED** | 0.3 - 0.5 | Logical deductions from other evidence |
| **AMBIGUOUS** | 0.1 - 0.3 | Contradictory or unclear signals |

Format in all documents:
```
**Evidence**: [REAL] confidence: 0.85 — "68% of surveyed users reported this issue" (survey-results.md)
```

## Experiment Design Patterns

### Landing Page Test
```markdown
## Landing Page Experiment
**Goal**: Validate market demand and messaging
**Setup**: 
- Create landing page describing solution
- Include clear value proposition
- Add signup/interest form
- Drive traffic via ads or outreach

**Metrics**:
- Traffic sources and volume
- Conversion rate to signup
- Bounce rate and time on page
- Qualitative feedback via exit survey

**Success Criteria**: >5% conversion rate, <60% bounce rate
```

### Prototype Testing
```markdown
## Prototype Validation
**Prototype Type**: [Paper, Digital, Interactive]
**Testing Method**: [Moderated sessions, Unmoderated, A/B test]

**Test Scenarios**:
1. [Primary use case walkthrough]
2. [Edge case or error handling]
3. [Integration with existing workflow]

**Metrics**:
- Task completion rate
- Time to complete key actions
- User satisfaction score
- Specific usability issues identified
```

## Discovery Synthesis Template

```markdown
## Discovery Summary

### Key Insights
1. **Problem Validation**: [Confirmed/Rejected + Evidence]
2. **User Segments**: [Most/Least interested segments]
3. **Solution Preferences**: [What resonated most]
4. **Barriers to Adoption**: [Main concerns/obstacles]

### Validated Assumptions
- [List assumptions that were confirmed]

### Invalidated Assumptions
- [List assumptions that were disproven]

### New Questions/Assumptions
- [New unknowns discovered during research]

### Recommendation
**Decision**: [Proceed/Pivot/Stop]
**Rationale**: [Evidence-based reasoning]
**Next Steps**: [Specific actions and timeline]
**Remaining Risks**: [What we still don't know]
```

## Discovery Planning Best Practices

### Time-boxing Discovery
- Set clear timeboxes (typically 2-6 weeks)
- Define specific learning goals for each phase
- Plan regular checkpoint reviews
- Have clear decision criteria upfront

### Balancing Research Methods
- Combine qualitative depth with quantitative scale
- Start broad, then narrow focus based on learnings
- Use triangulation across multiple data sources
- Involve cross-functional team members

### Documentation and Communication
- Create shared discovery artifacts
- Regular stakeholder updates with key insights
- Document decisions and rationale
- Share learnings across teams

### Common Pitfalls to Avoid
- Confirmation bias in question design
- Over-researching obvious problems
- Ignoring negative feedback
- Analysis paralysis - perfectionism over progress
- Skipping synthesis and jumping to solutions