Run Customer Discovery

---
name: run-customer-discovery
description: Use when validating a startup idea, product hypothesis, or new feature by conducting structured interviews with target customers before building
source: Steve Blank "The Four Steps to the Epiphany" (2005); Ries "The Lean Startup" (2011); IDEO design thinking customer research methodology
tags: [entrepreneurship, customer-discovery, lean-startup, product, research]
related: [apply-lean-startup-methodology]
verified: true
---

# Run Customer Discovery

Conduct structured customer interviews to validate or invalidate core business assumptions before writing code or spending capital.

## Why This Is Best Practice

**Adopted by:** Y Combinator-advised startups, IDEO design thinking practitioners, Lean Startup methodology adopters, Google Ventures design sprint teams
**Impact:** CB Insights analysis of startup failures found 35% failed due to "no market need" — a problem that customer discovery directly prevents. Steve Blank documented 10+ companies that pivoted from failing to successful after 50+ customer discovery interviews revealed a different problem than assumed.
**Why best:** Building before validating is the most expensive mistake in product development. Customer discovery is the minimum viable test for whether a problem is real, frequent, and worth solving.

Sources: Blank "The Four Steps to the Epiphany" (2005); Ries "The Lean Startup" (2011); IDEO "Design Thinking" field guide; Fitzpatrick "The Mom Test" (2013)

## Steps

1. **Document your hypotheses first** — before talking to anyone, write down your explicit assumptions: who the customer is, what problem they have, how they currently solve it, and what they would pay for a better solution. This prevents confirmation bias in analysis.

2. **Define your target customer profile** — specify 3–5 demographic, behavioral, and situational characteristics of your ideal early adopter. Be specific enough to know who NOT to interview.

3. **Recruit 15–20 interviewees** — reach the target profile through: LinkedIn outreach, founder networks, relevant Slack communities, Twitter/X, and warm introductions. Do not interview friends and family who will tell you what you want to hear.

4. **Prepare a question script** — write 8–12 open-ended questions focused on past behavior, not hypothetical future behavior. Ask "Tell me about the last time you…" not "Would you use a product that…"

5. **Open with context-setting** — explain you are researching a problem space, NOT pitching a product. Tell them you want to learn, not sell. This unlocks honest feedback.

6. **Ask about the problem, not your solution** — spend 70% of interview time on the problem: frequency, severity, current workarounds, and cost of the problem. Never describe your solution unless they ask directly.

7. **Use "The Mom Test" questions** — ask only questions that a supportive parent couldn't give a false positive on. "How much do you pay for solutions to this problem today?" is a Mom Test question. "Would you pay for our product?" is not.

8. **Probe for specifics** — when someone describes a pain point, ask: "How often does that happen?" "What did you do about it?" "How much did that cost you?" "Can you show me?" Vague answers signal weak problems.

9. **Listen for pull, not politeness** — the signal is not "this is interesting." The signal is: unsolicited offers to pay, requests to be a beta user, referrals to other people with the same problem, or visible frustration with current solutions.

10. **Debrief and synthesize after each session** — write up key quotes and insights immediately after each interview. After all interviews, cluster findings by theme. Count how many interviewees independently raised each problem without prompting.

## Rules

- Never pitch your solution in discovery interviews — it contaminates the data.
- Talk to at least 10 people before drawing conclusions; 5 is not enough to distinguish patterns from noise.
- Record with permission, or bring a note-taker — memory degrades within hours and selectively retains confirming evidence.
- Seek out disconfirming evidence explicitly — ask "Who would this NOT work for?" and "What's the worst thing about this approach?"
- Separate problem discovery from solution validation — these are two distinct research phases with different questions.

## Common Mistakes

- **Asking hypothetical questions** — "Would you pay $50/month?" gets yes from people who never will; ask what they pay today.
- **Interviewing only willing participants** — the people who agree to interviews are often enthusiasts; force yourself to reach skeptics.
- **Pitching and watching for approval** — founders unconsciously frame questions to get validation; use verbatim scripted questions.
- **Declaring success after 5 interviews** — 5 interviews can identify themes; 15–20 are needed to establish frequency and pattern.

## When NOT to Use

- When the problem is well-documented with existing market evidence (use competitive analysis instead)
- When you already have paying customers and usage data (shift to quantitative product analytics)
- When legal/regulatory constraints prevent direct customer contact (use proxy research: industry reports, expert interviews)