Customer Discovery Interviews That Avoid False Positives

The single largest source of false positives is question phrasing. Hypothetical and opinion questions ("Would you use a tool that...?", "Do you think this is a good idea?") invite polite agreement. Behavioral questions about the past produce real information about real behavior (Skimle).

The Harvard Innovation Labs points to the Mom Test as the corrective: instead of asking whether someone would buy, ask what challenges they face in that area, so the answers stay tied to their experience rather than their opinion of your idea (Harvard Innovation Labs). The startup lexicon on customer discovery draws the same contrast directly: "Walk me through how you currently handle X" rather than "Would you use a product that does X?" (Startups.com).

Leading questions are a specific mechanical failure. A question like "How much do you like our product?" presupposes that the respondent likes it, while "What are your thoughts on our product?" does not (Innovation Within). The same logic applies to problems: "How frustrating is it when your reports fail to sync?" assumes frustration and a broken sync. "Tell me about the last time you needed a report and what happened" assumes nothing.

Three rewrites that do most of the work:

Note the pattern: every replacement asks for a specific instance, and none of them mention your product. If a participant volunteers enthusiasm for your idea, write it down and set it aside, because it is not evidence of anything except their manners.

Two more habits from practitioners. Prepare a script so you do not improvise your way into pitching (Studio Zao), and include at least one question that has the potential to destroy your currently imagined business (Studio Zao). A script here is not a rigid questionnaire. It is a list of five to eight prompts you can return to when the conversation drifts toward feature requests.

A short opening that sets expectations, borrowed from outreach templates and the "we are here to learn, not to sell" framing:

"Thanks for the time. I am researching how [role] handles [problem area].
I have nothing to sell you and I am not showing a product today.
I want to hear about how you do things now, including what is annoying.
Is it okay if I take notes, and can I quote you without your name?"

A perfect script run on the wrong sample still produces a false positive. Selection bias, where the sample does not represent the intended audience, skews results before the first question is asked (Innovation Within). The most common version: founders interview their friends, who are supportive, want the idea to succeed, and are demographically nothing like the target customer (Skimle).

The fix is to interview for variation. Teresa Torres recommends talking to power users, first-time users, engaged users and disengaged users, and defining "customer" as anyone who matches your target profile, including prospects and people who have never heard of your company (Product Talk). She also notes that people rarely get to be truly listened to, so well-run interviews are usually welcome rather than annoying (Product Talk).

Recruiting realistically takes work. A practical starting point is messaging 30 to 40 people who match the profile, being explicit that there is no pitch, and expecting a 15 to 25% response rate (Skimle). Communities, Slack workspaces and forums can supply participants too, but most have rules against direct recruiting, so engage genuinely first and reach out privately (Skimle). Adam Robinson describes opening more than 300 discovery conversations before building his product, using a public one-line description of the problem as the entry point (Adam Robinson).

How many is enough? The guidance varies: 15 to 20 conversations over three to four weeks is a reasonable discovery cadence (Skimle), while the practitioner rule of thumb is 30 to 50 problem-focused interviews before significant product investment, because below 10 to 15 you cannot separate signal from noise (Startups.com). The honest rule is saturation: keep going until three consecutive interviews from the target segment produce no new categories of problem, and count your segments before you count your interviews.

Bias enters through the questions, the sample, the interviewer's tone and the analysis (Innovation Within). Run this checklist before and after every session.

Before the session

• The script contains no hypothetical purchase questions and no mention of your solution before the final five minutes, if at all.
• You can name the specific behavior each question is trying to surface.
• The participant matches the target profile and has no personal stake in your success.
• Someone other than the person who most wants the idea to be true is taking notes.

During the session

• The participant talks 70 to 80% of the time; if you are finishing their sentences, you are leading (Skimle).
• You pause after each answer before asking the next question, because the most candid remark often arrives after a few seconds of silence (Skimle).
• When a participant drifts into feature suggestions, you return them to the problem: what is the frustration, and how do they handle it today (Studio Zao).
• Two people maximum in the room, one talking and one writing (Studio Zao).

After the session

• You recorded one thing you heard that you did not expect, or you flag the interview as low-information.
• Every interpretation in your notes is separated from the verbatim quote it came from.
• You have not marked any answer as "validation" without a concrete past action attached to it.

The last item is the sharpest test. "I would use that" does not predict a purchase, but "I have spent $5K on workarounds" does (Startups.com). Where a participant describes money, time or status already being spent to solve the problem, you have a real signal. Where they describe a vague preference, you have a pleasant conversation.

Most false positives are born in the notes, not the interview. If the notes record "user loved the idea" and not the sentence they actually said, the rest of the team inherits your interpretation as fact.

The minimal discipline is a three-column log. Timestamp, verbatim quote, and interpretation, kept in separate columns so they cannot blend.

Two rules make the log useful. First, replace names with codes (P1, P2) in any shared document, and keep the key elsewhere. Second, write a one-paragraph memo within an hour of the interview, before other conversations blur the details. Studio Zao's observation that you come back from interviews with real faces in your minds, and recall people's words when making decisions later, is a reason to capture the words themselves while they are fresh (Studio Zao).

Then count. After each batch of five interviews, tally how many participants described the problem unprompted, how many described a current cost (money, hours, headcount), and how many described an active search for a solution. The Harvard Innovation Labs frames discovery around exactly these questions: does the customer recognize the problem, is it a priority, are they actively looking, and do they have budget (Harvard Innovation Labs). Your tallies turn interviews into something a skeptic can audit.

A worked example. Suppose you run 20 interviews. Sixteen mention the problem when asked generally. Nine describe a specific recent instance with detail. Four can name what they currently spend on workarounds. One has looked at alternatives in the past quarter. The script was clean and the sample was diverse, so the honest reading is not "16 of 20 have the problem." It is "the problem is recognizable, the acute version is real for fewer than half, and intent to act is thin." That is a very different input to a build decision, and it came from the same 20 conversations, recorded properly.

Getting disconfirming evidence is a success, not a setback: it is better to be proven wrong at this stage than after you have spent millions on development and a marketing campaign (Studio Zao). The failure mode is not hearing "no." It is explaining away the "no" while you are still dialing the next participant.

If your cognitive style tends to argue with inconvenient data, count the interviews out loud with a small meetup or a standup, where someone else reads the log and asks why four of twenty could not name a cost. A frequent structure is one interviewer and one note-taker, with the note-taker reading their verbatim log to the team afterward so the actual words survive. If you are running discovery alone and cannot find a consistent second reader, a call with an independent operator is worth the time; Quanta Consulting offers a free 30-minute discovery call for exactly this kind of checkpoint (Quanta Consulting). The tell that your process is working is not that you hear good news. It is that you occasionally close a notebook thinking the idea is weaker than you believed in the morning.

Interviews are not proof of anything on their own: talking to people is useful for learning but not validating, and validating an idea requires acquisition and activation data, not just conversation (Scott McLeod). What interviews can do is tell you which experiment to run next, and whether it is worth running at all. They can also show you the door, honestly: a fake door test shows whether people will attempt to use a feature, while discovery interviews uncover problems you did not know existed (Koji's guide). If you want a stripped-down example of an experiment pairing clicks with a follow-up conversation, fake door write-ups describe exactly that pairing (Koji's guide). The two work best as partners: interviews tell you what to build the door for, and behavioral data tells you whether anyone walks through it.

A final habit. In your first week of discovery, end every session with the question "What should I have asked that I didn't?" The answers are frequently better than your script. They also give you a way to check your own sample: if three people tell you the same thing should have been asked, that is the next conversation, not a niche.