How many customer discovery interviews do I need before I can decide?

There's no fixed rule, but patterns usually emerge after about 10 to 15 interviews within a single, well-defined customer segment. If you're still hearing wildly different problems after that, your segment is probably too broad or the problem isn't sharp enough. Synthesize in small batches so you notice the patterns as they form.

What's the difference between customer discovery and a sales pitch?

Discovery is about learning what people already do and struggle with; a pitch is about getting them to like your idea. In discovery you avoid describing your solution at all, ask about specific past behavior, and let the user talk roughly 80% of the time. If you leave feeling flattered, you likely pitched instead of learned.

Why shouldn't I trust people who say they'd use my product?

Because saying yes is free and people are generally kind. Humans are poor at predicting their own future behavior, so 'I'd definitely use that' rarely translates into actual usage or payment. Trust actions instead: existing workarounds, money already spent, or a concrete commitment like a pre-order or an introduction.

What questions should I ask in a customer discovery interview?

Ask grounded, past-tense questions: 'Walk me through the last time you dealt with X,' 'How do you handle that today?', 'What have you already tried, and why didn't it work?', and 'How much time or money did that cost you?' Avoid hypothetical, yes/no, or leading questions like 'Would you use a tool that...'.

How do I find the right people to interview?

Write a one-sentence description of who has the problem, then screen against it so you don't waste calls on the wrong person. Recruit through relevant online communities, your network, warm intros, and targeted cold outreach. Frame the ask as a short, no-pitch conversation to learn about how they handle a specific problem.

Customer Discovery: How to Talk to Users

What Customer Discovery Actually Is (and Isn't)

Customer discovery is the practice of talking to real people to understand their problems, workflows, and decisions before you commit to building a solution. The goal is learning, not selling. If you walk out of an interview feeling validated and excited, you probably ran a sales pitch by accident.

The most common failure mode is treating an interview as a demo. Founders describe their idea in glowing terms, the polite human across the table says 'oh that's cool, I'd totally use that,' and the founder records it as evidence. It isn't. People are bad at predicting their own future behavior and good at being kind. Discovery is designed to route around both of those facts by digging into what someone has already done, where real effort and money leave a trail you can verify.

How to Talk to Users Without Leading Them

The single most useful framing comes from Rob Fitzpatrick's book The Mom Test: ask questions so grounded in specifics that even your mom couldn't lie to you to make you feel good. Instead of 'Do you think this is a good idea?' you ask about their life and let the problem reveal itself.

Anchor every question in concrete, recent past behavior. 'Walk me through the last time you tried to do X.' 'What did you do right before that?' 'How did you solve it in the end?' These force the person to narrate reality rather than imagine a flattering hypothetical. Compare two questions: 'Would you pay for a tool that organizes your receipts?' invites a free yes. 'How do you handle expense receipts today, and what happened the last time tax season came around?' surfaces the actual pain, the current workaround, and whether they care enough to have done anything about it.

Avoid yes/no questions, avoid pitching, and resist the urge to explain your idea. Once people know what you're building, they start answering the question they think you want answered.

Recruiting the Right People to Interview

An interview with the wrong person produces confident, useless data. Before recruiting, write down a one-sentence description of who has the problem you care about, then screen against it. If you're building scheduling software for dental clinics, talking to a software engineer who 'books a lot of appointments' is noise.

Where to find people depends on the segment. For consumer problems, your own extended network, relevant subreddits, Discord servers, and Facebook groups work well. For B2B, cold outreach on LinkedIn, warm intros, and industry Slack communities are reliable. Offer a clear, short ask: '15 minutes to learn about how you handle X, no pitch, no selling.' Be honest that you're researching a problem, not demoing a product.

A practical example: a founder exploring a tool for freelance bookkeepers posted in two bookkeeping communities asking to learn about month-end close headaches. She booked nine calls in a week, and three of them independently described the same painful reconciliation step. That repetition, from strangers with no reason to flatter her, was the first real signal.

Running the Interview: Listen More Than You Talk

A good discovery interview is roughly 80% the user talking and 20% you. If you're talking more than that, you're pitching or rescuing awkward silences that you should let breathe. Silence is where people add the detail they were about to skip.

Open with rapport and context: 'Tell me a bit about your role and how a typical week looks.' Then move to the problem area with past-tense, story-based prompts. When someone mentions a pain point, dig: 'How often does that happen?' 'What did it cost you, in time or money?' 'What have you already tried?' 'Why didn't that work?' The 'what have you tried' question is gold, because a problem someone has spent money or effort trying to fix is a problem worth solving. A problem nobody has lifted a finger about is usually just a mild annoyance.

Record or take notes verbatim where you can, capturing the person's own words. Their phrasing becomes your future landing page copy and your honest read on whether the pain is acute or theoretical.

Spotting Real Signal vs. Polite Compliments

Compliments are the booby prize of customer discovery. 'That's a great idea,' 'I'd definitely use that,' and 'let me know when it launches' feel like progress and mean nothing. They're cheap, they cost the speaker nothing, and they're often just kindness.

Real signal is anything that costs the person something. Have they already cobbled together a spreadsheet, paid for a half-working competitor, or assigned a person to do the job manually? Did they ask 'when can I have it?' and then offer to introduce you to their boss or pre-pay? Concrete commitments, time, money, reputation, or a follow-up action are what separate a real problem from a nice-to-have.

A useful discipline: after each interview, mark whether you heard a fact (something that happened) or an opinion (something they predicted or felt). Build your conclusions on the facts column. This is also where an outside gut-check helps. Running your discovery notes or your one-line problem statement through a brutally honest tool like PitchRoast can flag where you've quietly mistaken a compliment for evidence, before you spend three months building on it.

How Many Interviews and What to Do With Them

There's no magic number, but most founders start hearing the same stories after roughly 10 to 15 interviews per segment. When the third or fourth person describes the same workaround unprompted, you're onto something. When everyone gives you a different problem, you either have the wrong segment or the problem isn't sharp enough yet.

Synthesize in batches rather than waiting until the end. After every five or so conversations, write down the recurring problems, the exact language people used, the workarounds, and any moments where someone took a real action. Look for patterns across people, not the one juicy quote that confirms your hope. Confirmation bias is the quiet killer here, so actively hunt for evidence that your idea is wrong.

Discovery isn't a phase you finish; it's a habit. Even after you ship, the same skills, asking about past behavior, listening more than you talk, and trusting actions over words, keep your product pointed at a problem people actually have.