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

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