The twelve methods worth knowing, what question each one actually answers, how many people you need, and how to pick the right one instead of defaulting to a survey.
What is customer research?
Customer research is the practice of gathering evidence about what customers need, do, and struggle with, so decisions rest on observation rather than opinion. A customer research method is simply a repeatable way of collecting that evidence — and each method answers a narrow question well and every other question badly.
That last point is where most research goes wrong. Teams pick a method by familiarity — a survey, because everyone knows how to write one — and then ask it a question it structurally cannot answer. A survey can tell you that 38% of customers abandoned onboarding. It cannot tell you why, because you had to guess the answer options before you knew what was happening. Choosing the method is not a formality before the research; it is most of the accuracy of the result.
The reliable pattern is to move from why to how many. Start qualitative to find out what's really going on, then go quantitative to size it. Doing it in the other order produces precise measurements of the wrong thing.
The two axes: qualitative vs quantitative, primary vs secondary
Every method sits somewhere on both axes, and knowing where tells you what you can legitimately claim from the result.
Axis
What it gives you
What it can't
Qualitative
Motive, context, cause, and the language customers use
Size anything, or prove a difference
Quantitative
Frequency, magnitude, and statistically real differences
Explain anything you didn't already think to ask
Primary
Evidence collected for your exact question
Be cheap or fast
Secondary
Fast, cheap context on what's already known
Be current, specific to you, or unbiased
A useful habit: before running anything, write down the sentence you hope to be able to say afterwards. If that sentence contains a number, you need a quantitative method. If it contains the word “because,” you need a qualitative one.
The 12 customer research methods
Each one below leads with the question it answers, because that's how you should be choosing. Sample sizes are working rules of thumb for product teams, not academic thresholds.
Customer interviews
Qualitative
What problem do they have, and how do they deal with it today?
A semi-structured conversation, usually 30–45 minutes, where you ask about real past behavior rather than hypothetical preferences. It's the highest-yield method in the category and the one most teams should run first, because it's the only method that will surprise you — every other method tests something you already thought of.
Sample size:
5–8 per segment to spot themes, 12–15 to trust them
Watch out for:
Leading questions and hypothetical framing. 'Would you use this?' invalidates the answer.
What made them switch — and what nearly stopped them?
A specific interview structure that reconstructs a purchase or churn decision along a timeline: first thought, passive looking, active looking, deciding, first use. Because it anchors on an event that actually happened, it gets at the forces behind the switch — push, pull, habit, and anxiety — rather than a rationalized story.
Sample size:
8–12 recent switchers (or churners)
Watch out for:
Interviewing people who switched too long ago. Under 90 days keeps the memory usable.
Contextual inquiry
Qualitative
What do they actually do, in the place they do it?
Watching someone work through a real task in their real environment, asking questions as they go. It reliably surfaces the workarounds, spreadsheets, and side-channels people never mention in an interview because they've stopped noticing them. Expensive in time, and worth it exactly once per workflow you care about.
Sample size:
4–6 sessions per workflow
Watch out for:
Turning it into an interview. Watch first, ask second, and let silences run.
Diary studies
Qualitative
How does the experience unfold over days or weeks?
Participants log entries — text, photo, or video — as they go about a task over a period of time. It's the only practical way to study things that happen infrequently or across sessions: onboarding over a fortnight, a monthly reporting cycle, a slow-building frustration. The trade-off is elapsed time and a real analysis workload.
Sample size:
8–15 participants over 1–4 weeks
Watch out for:
Participant drop-off. Prompt daily and pay properly, or you'll finish with half the data.
Focus groups
Qualitative
How does a group talk about and react to a topic?
Six to eight people discussing a topic with a moderator. Genuinely useful for language — how customers describe the problem in their own words — and for surfacing disagreement quickly. Poor for anything else: the dominant voice sets the tone within minutes, and individual opinions converge toward it.
Sample size:
2–3 groups of 6–8
Watch out for:
Groupthink. Never use a focus group to decide something one-to-one interviews could decide.
Structured questions sent to many customers at once. Surveys are excellent at sizing something you already understand and terrible at discovering something you don't — every answer option you write is a guess you're asking people to confirm. Run them after interviews have told you which question is worth asking, not before.
Sample size:
100+ responses for a directional read; more for segment cuts
Watch out for:
Non-response bias. The people who answer are systematically different from the ones who don't.
Concept testing
Mixed
Does the idea land before we build it?
Putting a description, mockup, or landing page in front of the target audience and measuring reaction — comprehension, perceived value, and interest. The strongest versions ask for a real commitment (an email, a deposit, a calendar slot) rather than a rating, because stated interest and demonstrated interest diverge sharply.
Sample size:
15–30 for reactions; more if you're measuring conversion
Watch out for:
Politeness. People will not tell you your idea is bad; make them do something instead.
Usability testing
Mixed
Can people actually complete this?
Giving participants a task on a prototype or live product and observing where they fail. Moderated sessions explain why someone got stuck; unmoderated tests produce completion rates and misclick data across more people, faster. It tests execution, never direction — a flawless flow to the wrong feature still tests perfectly.
Sample size:
5 per round catches most issues; iterate in rounds
Watch out for:
Helping. The moment you rescue a stuck participant, you've deleted your own finding.
Splitting live traffic between variants and measuring the difference against a metric. It's the most reliable evidence available for a decision between two options you've already built — and it can only compare things that exist, which makes it a refinement method rather than a discovery one.
Sample size:
Enough traffic for significance — often thousands per variant
Watch out for:
Calling it early. Stopping a test the moment it looks good is how teams ship noise.
Behavioral analytics
Quantitative
Where do people drop off, without being asked?
Funnels, session recordings, and heatmaps showing what people did in the product. Unprompted, unbiased, and available in volume — and completely silent on motive. Its best use in research is targeting: find the step with the drop-off, then go interview the people who dropped.
Sample size:
All of it — this is a population, not a sample
Watch out for:
Inventing the why. Analytics generates hypotheses; it never confirms them.
Feedback mining
Mixed
What are customers already telling us?
Systematically reading support tickets, app reviews, sales-call notes, churn reasons, and community posts, then coding them into themes. It's the cheapest research available because the data already exists, and it's biased toward the loud and the unhappy — which is fine as long as you weight it accordingly instead of treating volume as importance.
Sample size:
A few hundred items gives a readable pattern
Watch out for:
Confusing volume with severity. Ten complaints about one thing can be one angry forum thread.
Industry reports, competitor review sites, public datasets, forums, and prior internal research. Fast, cheap, and the correct first step in almost every study, because it stops you spending expensive interview time re-learning things that are already documented — including by your own team six months ago.
Sample size:
N/A — bounded by time, not participants
Watch out for:
Staleness and vendor spin. Check the date and who paid for the report.
How to choose a customer research method
Start from the question, not the method. Find the row that matches what you actually need to know:
Your question
Method
Then follow with
What problem is worth solving?
Customer interviews
A survey to size the top theme
Why did they buy — or leave?
JTBD switch interviews
Churn-reason analysis at volume
What do they really do all day?
Contextual inquiry
Behavioral analytics to confirm scale
How does this play out over time?
Diary study
Follow-up interviews on the outliers
How do customers describe this?
Focus group or interviews
Copy testing on the language
How many are affected?
Survey or analytics
Interviews with the affected group
Is this idea worth building?
Concept test with a real commitment
Usability testing on the prototype
Can people use what we built?
Usability testing
A/B test once two options exist
Which version wins?
A/B test
Interviews to explain the losing variant
What are they already telling us?
Feedback mining
Interviews on the top theme
Two constraints override the table. If you can't reach the right people, the best method is the one you can actually staff — five interviews with real customers beat a perfectly designed study you never run. And if the decision is reversible and cheap, ship it and measure; research is for decisions that are expensive to undo.
How to run a customer research study
1
Write the decision you're trying to make
Not the topic — the decision. “Whether to rebuild import or invest in templates” is a research brief; “learn about onboarding” is a way to spend three weeks and change nothing. If no decision is waiting on the answer, don't run the study.
2
Do the desk research first
Read the support tickets, the churn reasons, the review sites, and whatever your team already ran. It costs an afternoon and routinely removes a third of the questions you were going to ask people.
3
Pick the method from the question
Use the table above. Write down what you will be able to claim when it's finished, and check the method can actually support that claim.
4
Recruit by behavior, not by title
Screen for what people have done — used the feature in the last month, churned in the last quarter, evaluated and chosen a competitor. Job titles are a weak proxy and produce polite, irrelevant sessions.
5
Ask about the past, never the future
“Tell me about the last time this happened” produces evidence. “Would you use this?” produces encouragement. Follow every generalization with a request for the specific instance behind it. Interview technique tips.
6
Capture the session properly
Record and transcribe rather than typing notes. Notes taken live are already an interpretation, and they quietly delete the quote you'll need three weeks later to convince someone.
7
Synthesize into evidence-linked themes
Break each session into individual observations, group ones that mean the same thing, and keep every theme attached to the quotes underneath it. Then judge themes by breadth, severity, and which segments they hit. How to analyze customer interviews.
8
Decide, and keep the trail
End with a decision and a record of what it rests on. Research that ends in a report gets read once; research that ends in a prioritized change to the plan is the only kind that pays for itself.
Mistakes that invalidate customer research
Asking people to predict themselves
Stated intent and actual behavior diverge, reliably and in the flattering direction. Every “would you” question should become a “when did you last” question.
Using the wrong method for the question
A survey used for discovery only confirms the options you guessed. A usability test used for direction only proves the wrong feature is easy to use. Most bad research is well-executed research pointed at the wrong question.
Talking only to people who like you
Your happiest customers and your own network are the easiest to recruit and the least informative. The people who evaluated you and chose something else know the most about your product's real gaps.
Mixing segments and calling it a sample
Fifteen interviews across four different customer types is four studies of three or four people. Sample size is per segment, and segments that behave differently have to be analyzed separately.
Hearing what you came to hear
Selective recall is the default failure mode of qualitative work. Keeping themes linked to verbatim quotes — and reviewing the sessions that contradict you — is the structural guard. Confirmation bias in product management.
Letting the research end in a document
A finding that never becomes a decision is a cost, not an asset. The step that makes research worth doing is the one after the readout, where the roadmap actually changes. Why customer research gets pushed aside.
Where the method meets the tooling
The methods are only half of it. Synthesis is where research dies.
Most teams don't fail at running interviews — they fail at what comes after. Twenty transcripts sit in a folder, the pattern lives in someone's head, and by the time the roadmap gets written the evidence is a half-remembered anecdote.
Intervool is built for that step: it transcribes your interviews, pulls structured findings from each one, clusters what repeats into evidence-linked themes, and carries them into personas, segments, and a prioritized roadmap — every item one click from the quote behind it.
The twelve that cover almost every real question: customer interviews, jobs-to-be-done switch interviews, contextual inquiry, diary studies, focus groups, surveys, concept testing, usability testing, A/B testing, behavioral analytics, feedback mining from support and reviews, and secondary/desk research. They split into qualitative methods that explain why something happens and quantitative methods that measure how often it happens.
What is the difference between qualitative and quantitative customer research?
Qualitative research — interviews, diary studies, contextual inquiry — works with small numbers of people in depth and explains motivation, context, and cause. Quantitative research — surveys, analytics, A/B tests — works with large numbers and measures frequency, size, and difference. Qualitative tells you what question to ask; quantitative tells you how much the answer matters. Neither substitutes for the other, and running them in that order saves the most wasted effort.
How many customers do I need to interview?
Five to eight per segment will surface most of the major themes, and twelve to fifteen per segment is where teams typically stop learning new things. The signal to stop is saturation — when you can predict what someone will say before they say it. Note that this is per segment: fifteen interviews spread across four very different customer types is really four studies of three or four people each, which is not enough of any of them.
Which customer research method should I use?
Match the method to the question. To learn what problem is worth solving, run interviews. To learn why someone bought or churned, run jobs-to-be-done switch interviews. To learn what people actually do rather than what they report, use contextual inquiry, diary studies, or behavioral analytics. To learn whether a design works, run usability tests. To learn how many people are affected, run a survey or query your analytics.
What is primary vs secondary customer research?
Primary research is evidence you collect yourself — interviews, surveys, tests, observation. Secondary (or desk) research is analysis of what already exists: industry reports, competitor reviews, public data, and your own support tickets and sales calls. Secondary research is cheap and fast and should almost always come first, because it tells you what's already known and stops you spending interview time on questions you could have looked up.
How often should we do customer research?
Continuously, in small amounts, rather than in occasional large projects. The widely cited benchmark from continuous-discovery practice is at least one customer conversation a week per product team. A weekly rhythm keeps evidence current and makes research a habit rather than a project that needs approving each time.
What is the biggest mistake in customer research?
Asking people to predict their own future behavior. 'Would you use this?' and 'how much would you pay?' produce confident answers that don't correlate with what people actually do. Ask about past behavior instead — what they did last time, what they tried, what they paid for — because that's evidence rather than speculation.
How do you analyze customer research?
Break each session into individual observations, group observations that mean the same thing into themes, then judge each theme by how many people it affected, how severe it was, and which segments it hit. The discipline that makes it trustworthy is keeping every theme linked to the verbatim quotes underneath it, so a conclusion can be checked rather than taken on faith.
