product-discovery

name	product-discovery
description	Methodology for discovering and specifying new software products. Use when starting greenfield projects, exploring new ideas, or defining MVP scope.

Product Discovery Skill

Transform vague ideas into actionable specifications through structured questioning.

Core Methodology

Questioning Frameworks

Five Whys - Reach root problems:

1. "Why is this a problem?" → Surface answer
2. "Why does that matter?" → Deeper impact
3. Continue until you reach the core motivation

MECE (Mutually Exclusive, Collectively Exhaustive):

• Cover all aspects without overlap
• Users, features, constraints, success criteria

Socratic Probing:

• Never accept surface-level answers
• "Can you give me a specific example?"
• "What would happen if...?"

Discovery Phases

Phase 1: Vision

Key Questions:

• "What moment made you think 'someone should build this'?"
• "If this existed perfectly, walk me through using it tomorrow"
• "Fast forward one year - what changed in the world?"

Phase 2: Core Problem

Key Questions:

• "If you could only solve ONE aspect, which unlocks the most value?"
• "What's the smallest thing that would make one person genuinely grateful?"
• "What part do you understand best? What's still fuzzy?"

Scope Control:

• "If you had budget for only 3 features, which would they be?"
• "Now pick just ONE to prove the concept"

Phase 3: Users

Key Questions:

• "Think of one specific person who needs this. What's their name? Their story?"
• "What do they do immediately before/after using your software?"
• "Which user type would be easiest to satisfy? Hardest?"

Phase 4: Technical

Key Questions:

• "What could you hardcode for MVP that becomes dynamic later?"
• "Which technical decisions can wait until concept is validated?"
• "What existing tools could you leverage instead of building?"

Phase 5: Validation

Key Questions:

• "How would you know, objectively, that MVP is working?"
• "What number would make you confident to continue? What would make you pivot?"
• "What feedback would change your direction most dramatically?"

Phase 6: Scoping

Effort-Based Framing (NOT time-based):

Scope Level	Definition
Core MVP	Solves ONE problem for ONE user type
Expanded MVP	Multiple features, still single user focus
Full Vision	Complete feature set, all user types

Facilitation Techniques

When They're Stuck

• Offer contrasts: "Would you rather have X or Y? Why?"
• Provide examples: "Some approach this as a marketplace, others as a tool..."
• Break it down: "Let's start with just the first step"

When They're Overcomplicating

• "That's a powerful feature. For MVP, what's the simplest version?"
• "Let's put that in the 'full vision' bucket for now"
• "On a scale of 1-10, how much value vs how much effort?"

When They're Too Vague

• "Walk me through the exact steps someone would take"
• "What would the screen look like at this moment?"
• "When you say 'fast', what specific measurement?"

Document Templates

SPEC.md (What to Build)

# [Project Name] Specification

## Problem Statement
[Core problem, why it matters, who has it]

## Target Users
- **Primary:** [Specific user type and needs]
- **Secondary:** [If applicable]

## MVP Scope (Core)
### Must Have
1. [Essential capability 1]
2. [Essential capability 2]

### Explicitly Excluded
- [Deferral 1 with reasoning]

## Success Criteria
- [ ] [Measurable outcome 1]
- [ ] [User can accomplish X]

## Full Vision
[Complete feature list for later phases]

## Scenarios
### Scenario 1: [Name]
- Given: [Context]
- When: [Action]
- Then: [Outcome]

DESIGN.md (How to Build It)

# [Project Name] Technical Design

## Architecture Overview
[High-level system structure]

## Technology Choices
| Layer | Choice | Reasoning |
|-------|--------|-----------|
| Frontend | [Tech] | [Why] |
| Backend | [Tech] | [Why] |
| Database | [Tech] | [Why] |

## Data Models
### [Entity]
- field: type (constraints)

## Key Decisions
### [Decision]
- **Choice:** [What was decided]
- **Reasoning:** [Why]
- **Trade-offs:** [What we accept]

## Technical Risks
| Risk | Mitigation |
|------|------------|
| [Risk] | [How we handle it] |

PLAN.md (Implementation Roadmap)

# [Project Name] Implementation Plan

## MVP Scope
[Reference to SPEC.md MVP section]

## Implementation Order
### Phase 1: Foundation
- [ ] [Task 1]
- [ ] [Task 2]

### Phase 2: Core Features
- [ ] [Task 3]
- [ ] [Task 4]

### Phase 3: Polish & Launch
- [ ] [Task 5]
- [ ] Launch preparation

## Go/No-Go Criteria
### Continue if:
- [ ] [Success metric achieved]

### Pivot if:
- [ ] [Failure condition]

## Post-MVP Phases
### Phase 2 (After validation)
- [Feature additions]

Specification Principles

• Behaviors over implementation - What the system does, not how
• Examples over abstractions - Concrete scenarios that illustrate
• Constraints as features - Limitations that shape the solution
• Edge cases as teachers - Unusual situations that clarify boundaries

These specs become context for AI implementation - clarity here multiplies effectiveness later.

---

Version

• v1.0.0 (2025-12-05): Initial documented version