Every version of this question gets answered with a number. Five, because a famous usability rule says so. Nine, because a saturation study says so. Twenty, because someone’s manager once said so. The number is never the useful part. What a team actually needs is a way to decide, on a Tuesday afternoon after the sixth conversation, whether booking a seventh is worth anyone’s time — and a constant can’t tell you that.
How many customer interviews are enough?
Enough is not a number, it’s a condition: you are done when two consecutive interviews add no new theme. For one segment and one clear question that usually lands between five and ten. Broader questions, unfamiliar problems, and multiple segments push it higher — sometimes far higher.
The published guidance is more consistent than it looks. Nielsen Norman Group is the source of the small-sample tradition most product teams inherited — a handful of participants surfaces most of what a single, well-scoped study will surface. The qualitative-research literature on saturation draws a sharper line: code saturation, the point where no new codes appear, tends to arrive around nine interviews, while meaning saturation — understanding each theme well enough to explain it — takes closer to sixteen to twenty-four. Practitioner guides such as the user research sample-size guide published by userinterviews.com land in the same band, fifteen to twenty-five for thematic saturation on one segment.
Read those together and the disagreement dissolves. The low numbers answer “have I heard the problem?” The high numbers answer “do I understand the problem well enough to design against it?” Both are correct for different jobs, which is exactly why quoting either one as the answer misleads.
What is saturation, and how do you know you’ve hit it?
Saturation is measurable on your own transcripts, and the measurement takes about five minutes per interview. Do it while the conversation is still fresh, not at the end of the round.
- After each interview, write down the distinct themes it produced. A theme is a recurring problem, cause, workaround, or constraint — not a quote and not a feature request.
- Mark each theme as new or already recorded.
- Keep a running count of new themes per interview.
- Stop when two interviews in a row produce zero new themes.
- If interview eight still produces three new themes, do not book more interviews yet. Look at your question instead.
That last step is the one most teams skip. A tally that refuses to flatten is rarely a sample-size problem. It usually means the question is too broad (“how do people do planning?”), or the participants are too dissimilar to belong in one round, or the interviewer is steering differently each time. Adding a ninth conversation to a badly framed round buys you a ninth unrelated anecdote. If your conversations are drifting, the structure in customer interviews without the awkwardness will do more for saturation than three extra participants.
Segmentation is the single biggest driver of how many interviews you need, and it is multiplicative rather than additive. Two genuinely different user types are two rounds, each with its own tally. Ten interviews spread thinly across three segments is not a study; it is three underpowered studies wearing a trench coat.
The number depends on the decision, not the method
The other thing page one leaves out: interviews are an input to a decision, and decisions differ enormously in how much evidence they need. Killing an idea is cheap to get right and easy to reverse. Setting a price is neither.
| Decision you’re making | Typical interviews | How you know you’re done |
|---|---|---|
| Kill or park an idea | 3–5 | Nobody describes the problem without being prompted. One round of blank looks is a sufficient answer. |
| Validate a problem you already believe exists | 5–8 | The same trigger, workaround, and cost show up unprompted in most conversations; two in a row add nothing new. |
| Discover an unknown problem in a new area | 12–20+ | New themes keep arriving until they don’t. Expect a long tail, and expect to re-scope the question mid-round. |
| Set or change pricing | 15–25, split by segment and plan | Willingness-to-pay reasoning repeats within each segment. Saturation in one segment tells you nothing about another. |
| Anything spanning multiple segments | Run the counts above per segment | Each segment reaches its own two-interview flat line. Never pool the tallies. |
Use the table as a starting budget, not a target. The tally still decides when you stop; the decision type just tells you how surprised to be if you finish early.
When five interviews genuinely is enough
Five is a good number more often than the saturation literature implies, and pretending otherwise is how research turns into theater.
Five is enough when the decision is reversible. If you can ship behind a flag and watch what happens, the interviews only need to stop you from building something nobody described. Five is enough when you are killing rather than building — one round of people failing to recognize the problem is a decisive result, and the cost of being wrong is a discarded idea. Five is enough when you already know the segment intimately and are checking one narrow mechanic inside a workflow you have studied for a year.
And sometimes the right number is zero. Interviews are the wrong instrument when the question is “how many” rather than “why” — that is a survey or an analytics query, and five conversations will hand you five anecdotes with no way to weigh them. The split is laid out in surveys vs interviews. They are also the wrong instrument when behavior already answers the question: if you want to know whether a feature is used, your product analytics know, and they are more honest than people who over-report the things they think they should be doing. Interview to explain what the data made confusing, not to re-derive it.
The question nobody asks: what happens to the eleven transcripts?
Here is the part that determines whether the number ever mattered. A team runs eleven interviews, reaches saturation, writes a summary deck, and ships. Two quarters later a new PM asks whether anyone has talked to customers about onboarding. Nobody can find the round. The transcripts are in a drive folder, the themes are in a deck, the customers they came from are in the CRM, and none of the three know about each other. So the team books five interviews and rediscovers theme two.
That is not a discipline failure, it is a plumbing failure, and it is expensive. Context-switching — hunting one insight across a research doc, a feedback inbox, and an analytics dashboard — costs an estimated $450 billion a year, with the average employee losing 40% of productive time to it (Gallup). A PM who has to hand-stitch an interview quote to an account and a revenue figure generally doesn’t, and the round quietly expires.
The saturation tally only pays off if the themes outlive the round. That means each theme lands on the customer record it came from and the roadmap item it should change. In AIOProductOS, Insights is one feedback feed across reviews, requests, surveys, designs, and support, with every item linked to the feature it informs and the account it came from — so an interview theme sits beside that customer’s plan and revenue, and features rank by request count and revenue at stake rather than by whoever argued hardest. Next quarter, “we already know this, here are the six interviews” is a view, not an archaeology project. The path from raw signal to a shipped change is in turning customer feedback into product changes.
Stop asking how many interviews are enough. Run the tally, let it tell you, and make sure the themes are still findable the next time someone asks the same question. If your research keeps going cold between rounds, start with our guide to the best feedback tools.