Most early stage teams skip research because they picture the expensive version: a recruitment agency, a lab, a moderator, six weeks, a slide deck nobody reads. The version that actually changes products is smaller than that. Five conversations, a few recordings, and a week of attention will reliably beat a quarter of confident guessing.
Five is usually enough
The uncomfortable truth about qualitative research is how fast it saturates. Talk to five people from the same user group about the same task and you will hear the same two or three problems repeatedly. The sixth interview mostly confirms.
That number holds when the group is homogeneous. Two distinct audiences (say, admins and end users) means five each, not five in total. And it only applies to finding problems, not to measuring them; if you need to know what percentage of users hit an issue, that is a survey or an analytics question, not an interview.
So the bar for starting is low: five customers, one week, no budget beyond your own time.
Method one: watch someone use it
The highest value hour in product design is watching a real user attempt a real task while you stay silent.
Give them a goal, not instructions (“set up a campaign that sends on Friday”), then shut up. The discomfort of watching someone struggle without helping is exactly where the insight lives. Take note of every hesitation, every wrong click, every moment they read something twice.
Five sessions of thirty minutes will surface more than any internal debate, and it is the fastest way to find out whether your first ten minutes work or whether people land, stall, and leave.
Method two: ask about the last time, not the general case
Interviews go wrong when they ask people to predict or generalise. “Would you use a feature that does X” reliably produces a polite yes and no useful information.
Ask about behaviour that already happened instead. “Walk me through the last time you needed to do this.” “What did you use? What went wrong? What did you do next?” “What almost stopped you from signing up with us?” Past behaviour is memory; future behaviour is imagination, and imagination is where roadmaps go to die.
The most valuable interviews are with people who nearly bought and did not, and with customers who churned. Both are uncomfortable and both are cheap.
Method three: read the evidence you already own
Before recruiting anyone, mine what exists. Support tickets sorted by frequency are a ranked list of usability failures. Sales call notes contain the objections your homepage should be answering. Search queries inside your product or site show what people expected to find.
Pair that with the quantitative layer: which pages people leave and where flows collapse. Analytics tells you where the problem is; the conversations tell you why. Neither works alone.
Method four: the five second test
Show a page for five seconds, take it away, ask what the company does and what you can do there. Do it with ten people who do not know your business, which takes about twenty minutes to arrange.
Nothing exposes vague positioning faster. If nobody can name your category, the problem is the words rather than the design, and no amount of layout work will fix it.
Method five: a card sort for structure
When the argument is about navigation, stop arguing and run a card sort. Write every page or feature on a card, ask six users to group them and name the groups, and watch your internal vocabulary collide with theirs.
It takes an hour and it settles menu disputes permanently, because the grouping comes from the people who have to use it rather than from the org chart. That is how a site structure should be decided.
Do it in the week you have
A realistic lean cycle: Monday, mine the tickets and analytics and write down three questions worth answering. Tuesday and Wednesday, recruit and run five sessions (offer a small gift card, use whatever video call tool you already have, record everything with permission). Thursday, watch the recordings and pull out every observed problem onto its own line. Friday, group them by frequency and severity, pick the top three, and change something.
The output is not a report. It is a list of decisions and a changed screen. Research that ends in a document nobody acts on is theatre, and startups cannot afford theatre.
Run it before the build, not after, because an MVP built on assumptions is an expensive way to test them. It is also what separates product design that works from product design that looks good, and it feeds directly into the wireframes that come next.
Want a lean research round run alongside your next design sprint? hello@beconfidency.agency.
If you want research, design, and build handled by one accountable team, that is exactly what our product design service is for.