Interviews vs surveys in customer research: are you asking why, or how many?

Interviews tell you why, and surveys tell you how many. That is the short answer to interviews vs surveys in customer research: interview to understand an experience in detail and follow up on what you don't yet understand, and survey when your questions are clearly defined and your sample suits the estimates you want.

Neither proves demand on its own. Interview accounts don't establish how common something is, and a big pile of survey responses doesn't become representative just because it is big. Start with the sentence you want the research to support; its wording usually tells you whether you need an interview, a survey, direct observation, existing records or a mix.

Write the claim before you pick the tool

A survey asking "Was onboarding easy?" can't stand in for watching where someone gets stuck. An interview explaining one failure can't tell you how often that failure happens across the user base.

NN/g separates research methods partly by whether they reveal reported attitudes or observed behavior (research-methods overview). An answer someone gave you is not an action you watched.

Interviews find the shape of the problem

An interview turns up vocabulary, decision steps, constraints and alternatives you didn't anticipate, because you can ask what a term means and follow an unexpected branch.

Say a participant abandoned setup because they lacked "approval." That could mean manager permission, access to company data, a purchasing decision or a technical authorization. Those are different problems, and a conversation is how you find out which one you have.

Anchor each account in a recent event, label estimates and secondhand information, and ask about times the process worked as well as times it failed.

Interviews aren't automatically unbiased or deep. Leading questions, poorly matched participants and selective interpretation can produce a convincing story the evidence doesn't support.

Surveys count what you can already define

Before building the form, define the population, eligibility, measure and period. "New users" might mean people who created an account in a particular month, people who attempted setup or people who completed it. Each choice changes the denominator.

AAPOR's best practices stress specific objectives, sampling, question design and transparent methods, and ask whether a survey is the right method at all (AAPOR's survey guidance).

If "approval" is still ambiguous to respondents, your count will lump several different experiences together. Interviews or a questionnaire pretest catch that before the survey goes out.

Surveys can include open-ended questions, but someone has to interpret and code every answer. A long form full of open questions is not automatically a faster substitute for a conversation.

Let each method answer its own question

Here is a made-up example: a team investigating why people abandon setup.

1. It checks whether the product records the relevant setup steps reliably.
2. It interviews people who recently attempted setup, to learn what the events don't explain.
3. The conversations turn up several meanings of "waiting for approval." The team defines those categories, tests whether respondents read the wording as intended, and decides whether a survey would answer a remaining frequency question that matters.
4. A later task-based session checks whether a proposed change helps people complete setup.

This is one order, not a required one. Existing evidence may already answer part of the question.

A bigger sample from the wrong place is still the wrong sample

A survey sent through a founder's social network shows what those respondents think, not what every potential customer thinks (your former coworkers are lovely, but they are not the market). Report how people were recruited and which population the results can reasonably describe.

Interviews have the same trap: picking participants because they are easy to reach can leave out an important role, and adding more from the same source leaves the same gap.

Don't attach a standard margin of sampling error to a sample that doesn't justify it. If the decision needs defensible population estimates, get survey design and analysis expertise instead of borrowing a generic sample-size calculator. For exploratory work, report the accounts and their context, and don't dress them up as statistical validation.

Count the effort across the whole study

Interviews need recruiting, scheduling, preparation, moderation, records and analysis. Surveys need question design, testing, sampling, monitoring, cleaning and interpretation. The minutes a participant spends are only one part of the work.

A short survey with a poor measure can leave you more uncertain than before. Choose the smallest study that can responsibly inform the decision, and say what it won't answer.

Write a method statement before you launch

"We need to decide [action]. The uncertain claim is [claim]. We will collect [evidence] from [defined people or records] using [method]. This can establish [scope], but it cannot establish [limit]. We will use [additional method or next step] if [specific gap] remains."

That statement makes it harder to pick a method only because the team already pays for the software. It also gives the final report a boundary: the conclusion should fit the evidence the study was built to collect.