How many users should I interview?

Most technical founders ask the sample-size question because they want permission to start.

Is five users enough? Do you need ten? Should you talk to twenty before you trust the pattern? You have a product with fifty to a thousand users, a few worrying signals in the data, and no researcher on the team. You want to learn what is going on without turning a simple question into a month-long research project.

The honest answer is: there is no magic number. But there is a useful range.

For one focused question in one fairly coherent segment, start with five to seven interviews. Expect nine to twelve to show you the main themes. Use sixteen to twenty-four only when you need a richer understanding of the details. Add a few more interviews when your users split into genuinely different segments.

Then stop thinking in batches and build the habit that matters more: one conversation every week.

The better question

“How many users should I interview?” sounds precise, but it hides the real decision.

You are not trying to estimate a population percentage. You are not trying to prove that 37% of users feel something. You are trying to learn enough to make a product decision: why new accounts do not activate, why power users stay, why a segment churns, why a workflow keeps ending in a spreadsheet.

That means the better question is:

How many users do I need to talk to before I stop being surprised by the answer?

Nielsen Norman Group’s guide to UX interview sample size frames this through saturation: the point where new interviews stop changing the themes. The exact number depends on the breadth of your question, how varied your users are, how skilled the interviewer is, and how carefully you analyse what you hear.

That is good news for a founder. You do not need the perfect study. You need a small, well-scoped batch, followed by enough discipline to keep listening.

The five-user rule is not an interview rule

The most common mistake is importing the famous five-user rule from usability testing.

Jakob Nielsen’s article on testing with five users is about watching people use an interface. If five people try to complete the same task and three of them cannot find the button, you probably have a real usability problem. Interface issues repeat quickly.

Exploratory interviews are different.

In an interview, you are not watching someone fail at one task. You are asking them to describe a working life, a buying decision, a workaround, a cancellation, or a recent moment of frustration. Those stories vary more than click paths. One user’s story may reveal procurement. Another may reveal onboarding. A third may reveal that the feature you care about is irrelevant because the workflow moved somewhere else.

NN/g says this directly: for many exploratory interview studies, five participants are too few. Five can be a good first cut. It is not a universal stopping point.

Use five users when you are testing whether people can complete a task in the product. Use more when you are trying to understand why the task matters, what came before it, and what the user does when your product is not involved.

What saturation research says

The useful academic work gives founders a better set of numbers than “five”.

In the classic 2006 Field Methods paper, How Many Interviews Are Enough?, Greg Guest, Arwen Bunce, and Laura Johnson analysed sixty in-depth interviews and tracked when new themes stopped appearing. Their finding is the line everyone cites: saturation occurred within the first twelve interviews, while the basic elements of larger themes were present as early as six.

That is the first practical range:

• Six interviews can reveal the obvious patterns.
• Twelve interviews can be enough to stabilise themes in a focused, relatively coherent group.

But there is a second distinction that matters for product work. In Code Saturation Versus Meaning Saturation, Monique Hennink, Bonnie Kaiser, and Vincent Marconi separate two jobs. Code saturation means you have heard the range of issues. Meaning saturation means you understand those issues with enough texture to explain them well.

Their study found code saturation at nine interviews, but meaning saturation took sixteen to twenty-four. In plain founder language:

• Nine interviews may tell you what the problems are.
• Sixteen to twenty-four may tell you why those problems behave the way they do.

This is the difference between “users find onboarding confusing” and “new admins fail because they do not know which data source is the system of record, so they postpone setup until the champion is available, and then the trial goes cold.”

You can ship a useful fix from the first insight. You can build a better product from the second.

Segments change the count

The numbers above assume one focused question and one user group. Most B2B SaaS products are messier than that.

If your product has buyers, admins, and daily users, do not average them into one sample. If agencies and in-house teams use the same feature for different jobs, do not pretend they are one audience. If churn looks different for new customers and long-term customers, split the study.

First Round Review’s UX research crash course for founders makes the practical version clear: narrow the audience by common behaviour, not just demographics. Talk to people who share the context you are trying to understand.

You usually do not need twelve interviews for every segment. Start with five to seven in the segment that matters most. If a second segment clearly behaves differently, add three to five more from that group and compare the stories. If the second group keeps surprising you, keep going.

The goal is not statistical representativeness. The goal is coverage of the real variation that can change your decision.

The founder version

Here is the practical answer for a tiny B2B SaaS team.

If this is your first round of interviews, book five to seven conversations around one specific question.

Do not recruit “users” in general. Recruit the users whose recent behaviour answers the question.

• If you want to understand activation, talk to people who signed up and did not reach the first useful outcome.
• If you want to understand retention, talk to power users who keep coming back.
• If you want to understand churn, talk to customers who cancelled in the last two to four weeks.
• If you want to understand pricing, talk to prospects who seriously evaluated you and did not buy.

After those first conversations, write down the themes. If the same story appears twice, treat it as interesting. If it appears three times, treat it as a candidate pattern. If the fifth, sixth, and seventh interviews are still adding new causes rather than repeating the existing ones, your question or segment is broader than you thought. Narrow it or keep going.

Then run the next batch. By the time you reach nine to twelve interviews in one coherent segment, you should know the main themes. If you still do not, the problem is probably not the count. It is the recruiting, the question, or the interview quality.

Quality beats volume

Bad interviews do not become reliable because you ran more of them.

Rob Fitzpatrick’s The Mom Test is still the cleanest founder-facing rulebook here: talk about the user’s life, ask about specifics in the past, and talk less than they do. Y Combinator’s Eric Migicovsky gives similar advice in How to Talk to Users: do not pitch, do not ask hypotheticals, and ask for specific moments from the user’s life.

That changes sample size in practice. Five interviews grounded in recent behaviour will teach you more than twenty calls full of “would you use this?” and “what do you think of our roadmap?”

Use questions like:

• “Can you walk me through the last time that happened?”
• “What were you trying to get done?”
• “What did you do instead?”
• “Who else was involved?”
• “What made this worth solving now?”

Teresa Torres’ story-based interview guidance points in the same direction. Stories contain context. Abstract answers contain the participant’s theory of themselves. You want the story.

Stop counting interviews and start counting weeks

The batch answer is useful, but it is not the whole answer.

Teresa Torres’ continuous discovery framing shifts the unit from “interviews per study” to “customer touchpoints per week”. In a User Interviews conversation about continuous interviewing, she recommends a customer interview at least once a week and argues that frequency matters more than the total number in a single batch.

That is the habit most founders need.

A founder who talks to one user a week for a year will have fifty conversations. More importantly, those conversations will be distributed across launches, bugs, pricing changes, cancellations, onboarding problems, and new segments. You will not just learn more. You will learn closer to the moment when the decision is still alive.

This is where Maren fits naturally. The hard part for a founder is not believing that user conversations matter. It is maintaining cadence when everything else is on fire. Maren can run structured conversations continuously, ask users to walk through recent experiences, probe vague answers, and bring back themes while the team keeps building. The founder still has to make the judgement call. Maren makes it much harder to go six weeks without hearing from the people using the product.

A simple decision table

Use this as the working version.

The product-market fit row is not an interview sample-size rule. It is a reminder from B2B founder research, including Lenny Rachitsky’s guide to finding product-market fit in B2B, that early fit is often visible in a small number of companies that love, pay for, and keep using the product. That signal is behavioural. Interviews help you understand it, but they do not replace it.

When to stop

Stop a batch when the next conversation is unlikely to change the decision.

That does not mean every user says the same thing. It means you can explain the pattern, the exceptions, and the next step. You know which issue is common, which issue is rare but serious, and which issue belongs to a different segment.

Keep going when the answer is still changing shape.

If interview nine introduces a new workflow that explains four confusing support tickets, do not stop because a table said twelve. If interview six sounds exactly like interviews three, four, and five, you can probably make the next product decision before finishing a perfect academic sample.

Numbers are guardrails. Surprise is the signal.

The short answer

For one focused question in one segment, interview five to seven users to get started. Expect nine to twelve to reveal the main themes. Use sixteen to twenty-four when the decision is important enough that you need depth, nuance, and confidence. Add three to five interviews for a genuinely different segment.

Then put one user conversation on the calendar every week.

The founder who talks to seven users once may make one better decision. The founder who keeps talking to users every week builds a better company memory. You stop guessing what users meant. You start recognising the story when it comes back in a new form.

If you are asking how many users to interview, the practical answer is simple: pick one decision, recruit five people whose recent behaviour can teach you about it, and book the first conversation. The rest of the number will reveal itself when the stories stop surprising you.