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)