Discovery Frameworks

Discovery Frameworks

Continuous Discovery Cadence

Weekly touchpoints with customers — not quarterly research sprints.

Weekly Discovery Rhythm

Interview Recruiting Pipeline

• Maintain a pool of 10–20 willing participants
• Recruit from: in-app prompts, CS team, community, power users
• Incentivize: gift cards, early access, recognition
• Always interviewing: don't wait until you have a decision to make

Opportunity Solution Tree (OST)

Visual framework connecting outcomes → opportunities → solutions → experiments.

Outcome (desired business result)
├── Opportunity 1 (customer need / pain / desire)
│   ├── Solution A
│   │   └── Experiment: fake door test
│   └── Solution B
│       └── Experiment: prototype test
├── Opportunity 2
│   ├── Solution C
│   │   └── Experiment: concierge test
│   └── Solution D
│       └── Experiment: A/B test
└── Opportunity 3
    └── Solution E
        └── Experiment: wizard of oz

Building the OST

1. Start with the product outcome (not a feature)
2. Interview to surface opportunities (pains, needs, desires)
3. Brainstorm multiple solutions per opportunity (min 3)
4. Design cheapest experiment to test each solution
5. Work top-down: don't jump to solutions before mapping opportunities

Outcome Selection Criteria

• Measurable (has a metric)
• Within team's influence (not weather, market forces)
• Leads to business result (not vanity metric)
• Appropriate scope (not the entire company strategy)

Assumption Mapping

Every solution rests on assumptions. Surface and test them before building.

Four Assumption Types

Assumption Mapping Process

1. Write solution on whiteboard
2. Brainstorm all assumptions (10–20 per solution)
3. Plot on 2×2: Importance (x) × Certainty (y)
4. Focus testing on: High importance + Low certainty (top-left)
5. Document evidence for each assumption as you learn

Assumption Priority Matrix

High certainty  |  Not testing |  Monitor
                |              |
Low certainty   |  TEST FIRST  |  Test if time
                |  (critical)  |
                +----High------+----Low-----
                     Importance

Experiment Types

Fake Door Test

Test demand before building anything.

How: Show a button/link for a feature that doesn't exist yet
Measure: Click-through rate
Learn: Is there demand?
Risk: User frustration if CTA leads nowhere — always show "coming soon" message
Conversion benchmark: > 5–10% CTR suggests real interest

Concierge Test

Deliver the solution manually to validate value before automating.

How: Do the thing a human would do that software would eventually do
Measure: Do customers find it valuable? Will they pay?
Learn: Is the solution worth building?
Example: Manual curation of recommendations before building ML model
Scale: Works for 5–20 customers; not a long-term strategy

Wizard of Oz Test

Product appears to work automatically; humans operate it behind the scenes.

How: Build believable UI; humans fulfill the "automated" output
Measure: Do customers use it? Are they satisfied?
Learn: Does the solution deliver the expected value?
Risk: Team cost at scale — time-box to 2–4 weeks

Smoke Test / Landing Page Test

Measure intent before building.

How: Create landing page describing the solution; add waitlist/buy CTA
Measure: Email signups, "buy" clicks
Learn: Is there pull for this solution?
Risk: Marketing cost; measure intent, not just curiosity

Evidence Strength Scoring

Not all evidence is equal. Score before deciding to build.

Evidence Accumulation

Decision to build requires:

• ≥ 3 independent customer signals
• At least 1 behavioral signal (not just stated preference)
• Evidence from target customer segment (not edge cases)

Discovery vs Delivery Balance

Anti-Pattern: Big Bang Discovery

• Research for 3 months → build for 6 months → launch → wrong
• Root cause: too much time between learning and validating

Continuous Model

Week 1-2: Interview, identify top opportunity
Week 2-3: Map solutions, design cheapest experiment
Week 3-4: Run experiment, measure
Week 4: Learn → iterate or move to next opportunity
Repeat

Discovery Debt Signals

• Team ships features without talking to customers first
• PM writes specs without evidence section
• Roadmap decided top-down without customer input
• "We already know what customers want" mindset

Discovery Anti-Patterns