Product Discovery System
"Discovery without delivery = analysis paralysis. Delivery without discovery = feature factory."
This skill covers the Discovery System — continuously discovering which problems matter and which solutions might work. It maintains a living map of customer opportunities and tests solution ideas before committing engineering resources.
Part of: Modern Product Operating Model — a collection of composable product skills.
Related skills: product-strategy, product-architecture, product-delivery, ai-native-product, product-leadership
When to Use This Skill
Use this skill when:
- Setting up a weekly discovery rhythm
- Building or updating an Opportunity Solution Tree (OST)
- Creating interview snapshots after customer conversations
- Exploring multiple solution approaches
- Designing and running assumption tests
- Synthesizing insights across multiple interviews
- Running an Opportunity Council meeting
Cadence: Weekly rhythm | Owner: Product Trio (PM + Designer + Tech Lead)
The Problem This Solves
Most teams either:
- Do discovery once, then execute for months on stale assumptions
- Skip discovery entirely and build what stakeholders request
- Do discovery but don't connect it to what actually gets built
The Discovery System creates a weekly rhythm that keeps you close to customers and ensures evidence—not opinions—drives decisions.
Philosophy
Core Beliefs
- Weekly rhythm over big research projects — 2-3 interviews per week beats quarterly research sprints
- The crossfunctional discovery — Handoffs kill learning
- Opportunities are problems, not solutions — "Users need faster onboarding" not "Add a wizard"
- Multiple solutions per opportunity — Always explore 3+ options before committing
- Test in hours and days, not weeks — If your test takes a month, you're testing too much
What This Framework Rejects
- Discovery theater (interviews that don't change roadmap)
- Solution-first thinking
- PM does interviews alone, hands notes to designers
- Building the first idea that comes to mind
- Waiting for perfect data before deciding
Framework Components
1. Continuous Discovery Habits
The Weekly Rhythm (Minimum Viable Discovery)
| Activity | Frequency | Purpose | |----------|-----------|---------| | Customer interviews | 2-3 per week | Stay connected to real problems | | Synthesis session | 1 per week | Update opportunity map | | Assumption test | 1 per week | Validate before building |
Who Does Discovery: The Product Trio
| Role | Contribution | |------|--------------| | Product Manager | Owns outcome, facilitates, synthesizes | | Product Designer | Owns experience, visualizes, prototypes | | Tech Lead | Owns feasibility, estimates, identifies constraints |
Principle: The trio does discovery together. If the PM does interviews alone and hands notes to designers, you've already lost 50% of the insight.
0→1 Mode:
- Founder does interviews personally
- 10-15 interviews before patterns emerge
- Daily cadence if possible
- Bias toward speed over rigor
Scaling Mode:
- Research ops supports logistics
- Systematic interview quotas by segment
- Centralized insight repository
- Quarterly synthesis reports
2. Interview Snapshots
After each interview, create a snapshot (not a transcript). Capture the essence, not every word.
Snapshot Format:
INTERVIEW SNAPSHOT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Date: [Date]
Participant: [Role, Company type, Context]
Interviewer(s): [Names]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KEY OPPORTUNITIES (Unmet needs discovered)
• [Opportunity #1]
• [Opportunity #2]
• [Opportunity #3]
KEY QUOTE (In their words)
"[Memorable statement that captures their experience]"
QUICK FACTS
• [Relevant context about their situation]
• [Current workflow or tools]
• [Constraints or requirements]
JOBS TO BE DONE (If surfaced)
• Functional: [Task they're trying to accomplish]
• Emotional: [How they want to feel]
• Social: [How they want to be perceived]
SURPRISES
• [Anything unexpected]
• [Assumptions challenged]
FOLLOW-UPS
• [Questions for next interview]
• [Things to validate]AI Integration for Snapshots:
- Use AI to draft snapshot from notes
- Always review — AI misses 20-40% of important context
- Never let AI replace the act of listening
3. Opportunity Solution Tree (OST)
The OST is your living map connecting outcomes to opportunities to solutions to tests.
Structure:
OUTCOME
(Metric we're trying to move)
│
┌──────────────┼──────────────┐
│ │ │
OPPORTUNITY OPPORTUNITY OPPORTUNITY
(Unmet need) (Unmet need) (Unmet need)
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ │ │ │ │ │
SOLUTION SOLUTION SOLUTION SOLUTION SOLUTION SOLUTION
(Idea) (Idea) (Idea) (Idea) (Idea) (Idea)
│ │
┌──┴──┐ ┌──┴──┐
│ │ │ │
TEST TEST TEST TESTOST Rules:
| Rule | Why | |------|-----| | One outcome per tree | Don't try to solve everything at once | | Opportunities are problems, not solutions | "Users struggle to..." not "Add a feature..." | | Multiple solutions per opportunity | Always explore 3+ before committing | | Evidence-backed | Each opportunity has interview/data support | | Living document | Update weekly as you learn |
Good Opportunity Statements:
- "Users struggle to understand which metrics matter during their first week"
- "Managers can't quickly see which team members need attention"
- "New users don't know what to do after signup"
Bad Opportunity Statements (These are solutions):
- "We need a dashboard"
- "Add an onboarding wizard"
- "Send email reminders"
Target Opportunity Selection:
Use compare-and-contrast to select focus:
| Opportunity | Pain Severity | Frequency | Strategic Fit | Evidence Strength | |-------------|---------------|-----------|---------------|-------------------| | A | High | Daily | Core | 8 interviews | | B | Medium | Weekly | Adjacent | 3 interviews | | C | High | Monthly | Core | 12 interviews |
Principle: Choose ONE target opportunity at a time. Complete focus beats scattered effort.
4. Solution Exploration
For every target opportunity, generate at least 3 solution approaches before committing.
The Three Solution Types:
| Type | Description | Example | |------|-------------|---------| | The obvious solution | What everyone expects | "Add an onboarding wizard" | | The 10x harder solution | If effort were no constraint | "AI-powered personalized setup" | | The non-product solution | Pricing, process, partnership, or service | "White-glove onboarding call" |
Solution Categories:
| Category | When to Consider | |----------|------------------| | Product changes | Features, UX improvements | | Pricing/packaging changes | How value is captured | | Enablement changes | Documentation, training, support | | Process changes | How work gets done internally | | Partnership solutions | Integrate vs. build |
Principle: The best solution to a product problem is often not a product change.
Thin-Slice MVP:
Don't build the whole solution. Build the smallest thing that tests your riskiest assumption.
| Full Solution | Thin Slice | |---------------|------------| | "Complete onboarding wizard with 10 steps, progress tracking, and personalization" | "Single welcome screen that asks one question and shows one recommendation" | | "Full analytics dashboard with customizable widgets" | "One pre-built view showing the top 3 metrics" | | "AI-powered recommendation engine" | "Rule-based suggestions for top 5 use cases" |
5. Assumption Testing
Every solution ha