When to Stop Interviewing: A Sample Size Rule of Thumb

Several empirical anchors exist, and they cluster more tightly than the internet's arguments suggest. A systematic review of empirical saturation tests found that 9 to 17 interviews, or 4 to 8 focus group discussions, reached saturation across the studies reviewed, with most studies involving relatively homogeneous populations and narrowly defined objectives Hennink and Kaiser, Social Science & Medicine.

That range holds up against practitioner guidance. A widely cited summary of interview sample sizes places 5 to 8 interviews as the minimum for tightly defined exploratory work, 10 to 15 as the standard discovery range, and 20 to 30 when you are studying multiple distinct segments sample size guidance from Koji. The Harvard Rock Center's own pro tip for early discovery is five interviews per persona, with consistency in how each one is run Customer Discovery Basics. Five is where convergence starts, not where it finishes.

The variable that explains the spread is homogeneity. The more similar your interviewees are in role, company size, and workflow, the faster the tally converges. A tightly defined segment such as operations managers at mid-sized logistics firms will behave very differently from "anyone who touches spreadsheets." Narrow the segment before you start counting, then expect the count to run at the low end of the range.

One caution from the same body of work: data saturation and theoretical saturation are different milestones, and theoretical saturation (a robust explanation of why the problem exists) typically requires more interviews than simply hearing no new themes sample size guidance from Koji. For a go or no-go product decision, data saturation plus a clear causal story is usually enough. For choosing which of three possible solutions to build, push a few interviews further into the "why is it hard" territory.

Treat the table as planning input, not as a finish line. The stopping rule below is what actually ends the work.

Stop interviewing in a segment when both conditions hold:

1. Three consecutive interviews in that segment produced zero problems that were not already in the tally.
2. Your running tally shows the top three problems account for more than 70 percent of all problem mentions in that segment.

The three-interview window is a simple control for luck. A single quiet interview can happen because you booked the wrong person, or because they were distracted. Three in a row with nothing new is a much stronger signal, and it is cheap: you were going to run those interviews anyway to reach the tail of the 10 to 15 range.

The 70 percent threshold answers a different question: how concentrated is the pain? If your top three problems cover 70 percent of mentions, the remaining mentions are scattered across many low-frequency issues, which is exactly what you would expect from a real market rather than a manufactured one. If your top three cover only 45 percent, you are either in the wrong segment, your interview script is drifting between topics, or you have not interviewed enough people for patterns to form.

Worked example. A founder selling to independent pharmacy owners runs 11 interviews. Her tally:

Top three: 8 + 6 + 3 = 17 mentions, or 71 percent of 24. Interviews 9, 10, and 11 added no new problems. Both conditions hold, so she stops and moves to solution testing. Had the top three summed to 14 mentions (58 percent), she would keep going, because the long tail would still be producing candidate problems worth understanding.

An important discipline point: count mentions, not interviewees. One person can raise the same problem twice in different words, and two people can describe the same underlying issue differently. Resolve duplicates during coding, which is why a transcript and a fixed problem-label list matter more than a spreadsheet of vibes.

The rule only works if your data is countable. That means one problem vocabulary per segment and consistent notes. The Rock Center recommends running interviews with two or three people, one asking and the others observing and taking notes Customer Discovery Basics. A note-taker whose only job is labeling problems makes the tally reliable, because the person asking the questions is busy listening.

The question set determines what lands in the tally. A compact, field-tested sequence from customer discovery practice moves from context to consequences to action: what challenges they face with the topic, how they deal with it today, why it matters, what is hardest about it, why it is hard, how often it happens, and what they have already done to find a better solution Customer Discovery Done Well. That last question is the strongest filter you have: if someone has taken no action to solve a problem, it is unlikely to be a problem worth building for Customer Discovery Done Well.

Concrete questions about past behavior beat opinions about the future every time, which is the core of the Mom Test's rules: talk about their life rather than your idea, ask about specific past events rather than hypotheticals, and talk less than they do The Mom Test. The practical version: ignore "would you buy" answers entirely and focus on what people already spend money and time on. Notes from practitioners put a useful number on the listening ratio, suggesting the customer should speak for at least 80 percent of the conversation a summary of The Mom Test.

A minimal working structure: keep one line per problem, one row per interview, and a running count. Here is the entire data model.

segment: pharmacy_owner
problems = {}

def record(interview_id, problem_label):
    p = problems.setdefault(problem_label, {"label": problem_label, "mentions": 0, "interviews": []})
    p["mentions"] += 1
    p["interviews"].append(interview_id)

def saturation_report(last_n=3):
    total = sum(p["mentions"] for p in problems.values())
    ranked = sorted(problems.values(), key=lambda p: p["mentions"], reverse=True)
    top3 = sum(p["mentions"] for p in ranked[:3])
    return {
        "total_mentions": total,
        "top3_share": round(top3 / total, 2) if total else 0,
        "new_problems_in_last_n": len([p for p in problems.values() if set(p["interviews"]) & set(last_n_ids)])
    }

Nothing here is sophisticated, and that is the point. The value comes from writing the rule down before the twelfth interview, when the temptation to stop for non-research reasons is strongest.

Numbers alone do not justify stopping. Use this checklist to confirm that the remaining uncertainty is about execution, not about whether the opportunity exists.

The action-evidence row deserves emphasis. Discovery is not about how painful a problem sounds; it is about whether the problem is big enough across enough constituents to make it worth building for Customer Discovery Basics. Interviewees who have taken no steps to solve a problem are telling you it does not hurt enough. Interviewees who built a spreadsheet workaround at midnight are telling you the opposite, and those are the mentions that should dominate your top three.

Frequency belongs in the same judgment. Customer discovery practice distinguishes problems worth solving by two traits: frequent and intense Customer Discovery Done Well. Ask directly how often the problem comes up and what it costs when it does. A daily annoyance that takes 20 minutes each time is a different business than a quarterly compliance scramble, even if both are described with equal emotion in an interview.

One more gate: the "decision test." If you cannot complete the sentence "we will build X for this segment because the tally says so," you have not finished. Stopping is only legitimate when it converts into a decision, whether that is a build, a pivot to a different segment, or a no-go.

The most common failure is a drifting script. If interview one covers procurement and interview eleven covers hiring, the tally never concentrates because you keep changing the subject. This is the quiet cost of treating interviews as chats rather than a structured instrument. A consistent script per segment is what makes the eleventh interview comparable to the first.

The second failure is sampling from your own network. The Rock Center explicitly warns about false positives, both from interviewers hearing what they want and from interviewees saying what they think you want to hear, and notes that talking to enthusiasts can yield stronger signals than mainstream buyers actually hold Customer Discovery Basics. A tally built entirely from early adopters will show an artificially concentrated set of problems and fire the stopping rule before you have heard from the people who actually pay.

Warm introductions are the fix for reach, and they are free. Close every interview by asking who else in their company or field you should speak with, then send a short follow-up email with a blurb they can paste into an introduction customer discovery interview tips from NSF I-Corps. This does two things: it fills the last few slots in the segment with people who resemble your existing contacts, and it does so quickly enough that the three-interview window is not delayed by a week of cold outreach.

The third failure is outsourcing the conversation itself. Automating interviews by paying participants turns discovery into a survey, and it destroys one of the most informative signals available: whether anyone cares enough to talk to you for free Rob Fitzpatrick on AI and customer interviews. Machine-assisted interviewing works better with existing customers who already have a reason to engage, but for early-stage learning with non-customers it is the wrong instrument Rob Fitzpatrick on AI and customer interviews. AI is genuinely useful before and after the interview, for generating and rehearsing open-ended questions and for extracting themes from feedback at scale NSF I-Corps guidance on AI for customer discovery. Use it to sharpen the script and code the notes, not to replace the human on the call.

Finally, be careful about dumping whole transcripts into a knowledge base and asking for lessons learned. Fitzpatrick's objection is that this muddles biased and poor-quality data with good data in the same corpus Rob Fitzpatrick on AI and customer interviews. Whole transcripts are useful for pulling exact quotes; the tally should be built from your own labeled notes.

The moment the stopping conditions hold is the moment the work changes shape. Three things are worth writing down while the segment is fresh.

First, a one-page evidence sheet per segment: the top three problems with mention counts, the three-interview quiet window, the share figure, and two verbatim quotes per problem. This is what you show a co-founder, an advisor, or an investor who asks why you are building what you are building. It also survives team turnover.

Second, the reopen conditions. Write down what would send you back into interviews for this segment: a competitor launch, a price objection you cannot explain, or a new persona entering the buying process. Discovery is iterative rather than a one-time event, because circumstances and needs keep changing Customer Discovery Basics. A closed segment can reopen; it just needs a reason.

Third, the transition to testing. Interviews validate that the problem exists; low-fidelity tests validate that your solution lands. The Rock Center recommends several rounds of lo-fi testing, each varying one element, rather than testing many variables at once Customer Discovery Basics. This is where a working prototype earns its keep, and where routing a first build through a specialist who can turn the evidence sheet into a site, an app, or an internal tool saves weeks: Quanta takes the described product and hands it to a specialist to build with you.

If your next step after saturation involves reasoning over several model types on the same evidence, such as transcribing calls, clustering problem labels, and drafting the evidence sheet, one API key for text, audio and embeddings keeps that pipeline simple; Quanta Inference is at https://quantaintelligence.ai/inference.