Most first-time founders skip straight to building, then discover after launch that the thing they built solves a problem nobody will pay to fix. User research before your MVP is how you avoid that, and it costs almost nothing. You do not need a panel, a survey tool, or a market report. You need five of the right people, one week, and a set of questions designed to surface the truth rather than flatter your idea. This guide walks through exactly how to run that research, who to talk to, what to ask, and how to turn five conversations into a decision you can actually build on.
Why user research before your MVP beats building on a hunch
Talking to five real customers before you build is the difference between designing for a problem people have and designing for a problem you assume they have. In an hour of honest conversation, a potential user will tell you which parts of your idea matter, which parts they would never use, and what they currently do instead. That single insight, arriving before development starts, routinely saves a founder tens of thousands of pounds in features that would have shipped to silence.
The reason this works is timing. Changing your mind costs nothing on a call and costs a fortune once code is written. When you learn that your target user already solves the problem with a spreadsheet and is perfectly happy, you have just saved the entire build. That is not a failure of the research. That is the research doing its job.
The five-user rule, and why it actually works
You do not need fifty interviews. You need five. The usability research firm Nielsen Norman Group found decades ago that five users uncover roughly 85% of the problems in a design, because the same patterns repeat quickly and each extra participant tells you less than the last. You can read the reasoning in their write-up on why you only need to test with 5 users.
The same logic applies to problem-discovery research before an MVP exists. By the third or fourth conversation you start hearing the same frustrations, the same workarounds, and the same language. When two more people repeat what you have already heard, you have found a pattern worth building on. When the fifth person says something completely new, that is your signal to run another small batch. Five is not a magic number so much as the point where signal starts to outweigh effort.
Who counts as one of your five customers
The five people have to be real potential buyers of the product, not friends being supportive. A good interviewee currently has the problem you want to solve, has tried to solve it in some way already, and would plausibly pay something to solve it better. Your cousin who thinks the idea sounds nice does not count. A stranger who spent money last month trying to fix exactly this problem is worth ten of them.
Finding these people is easier than founders fear. Look in the communities where the problem already gets discussed, whether that is a subreddit, a LinkedIn group, a Slack community, or a WhatsApp group for that trade. Post honestly that you are researching a problem and want twenty minutes, not a sale. Offer a small thank you if the audience expects it. Most people are happy to talk about a frustration that genuinely bothers them, especially when you make clear you are not selling anything yet.
How to run the interviews
Keep each conversation to twenty or thirty minutes, one person at a time, ideally on a call where you can hear tone and follow up. Record it if they agree, so you can listen rather than scribble. Your job is to talk as little as possible. A good discovery interview is roughly eighty percent them and twenty percent you, and the twenty percent is almost all follow-up questions.
Open by asking them to walk you through the last time they hit the problem. Real stories beat opinions every time, because a specific memory is hard to fake and full of detail you would never think to ask about. When they mention a workaround, ask what they tried before that and why it did not stick. When they express a frustration, ask what it cost them in time, money, or stress. You are building a picture of how painful the problem really is, because pain is what predicts whether someone will change their behaviour for your product.
What to ask, and what never to ask
The questions that work are about the past and the present. The questions that mislead you are about the future. Ask “how do you handle this today?” and “what happened the last time this went wrong?” and “what have you paid to fix before?” These pull out behaviour, and behaviour is evidence. Never ask “would you use an app that did this?” because everyone says yes to be kind, and a yes on a hypothetical predicts nothing about a download or a payment.
Avoid pitching your idea in the first half of the call. The moment you describe your solution, the person switches from telling you the truth to reacting to your product, and politeness takes over. Save the reveal for the end, and even then, watch what they do rather than what they say. If they ask when they can use it, or offer to pay now, that is real signal. A warm “sounds great, good luck” is a polite no.
Turning five conversations into a build decision
After five interviews, write down the frustrations you heard more than once, the workarounds people already use, and the exact words they used to describe the problem. Those repeated patterns are your product brief. If three of five people described the same painful workaround, the first version of your product should replace that workaround and nothing else. If nobody could remember the last time the problem actually cost them anything, you have learned that the pain is too mild to build a business on, and that is worth knowing before you spend a penny.
This is also where you set the scope for a lean first build. The research tells you the one job your MVP has to do well, which keeps you from padding version one with features nobody asked for. That discipline is what keeps a first build in a sensible range rather than ballooning, a point we break down in MVP cost in 2026 and challenge further in the myth of the 25k MVP. Research first, then scope, then build, in that order.
Common mistakes that ruin early research
The fastest way to waste your five conversations is to run them like a sales pitch. Founders do this without noticing: they describe the product, watch the person nod, and walk away convinced. Nodding is not buying. If you spend the call talking, you have gathered encouragement, not evidence, and encouragement is the thing that gets founders to build products nobody wants.
The second mistake is talking to the wrong people. Friends, family, and anyone who knows you are the founder will soften every answer to protect your feelings, which makes their input actively misleading. You need people with no stake in your happiness and a real stake in the problem. The third mistake is asking about the future, because “would you use this?” and “would you pay?” measure politeness, not behaviour. Anchor every question in what the person has actually done, and you sidestep all three traps at once.
The last mistake is stopping too early on a single strong reaction. One excited person is a data point, not a pattern, and building on a single glowing conversation is how founders convince themselves a niche of one is a market. Wait for the same thing to repeat across three or four people before you treat it as a signal worth acting on. Repetition is the whole point of doing five.
What to do next
User research before your MVP is not a phase you can buy your way out of later. Five focused conversations, run this week, will tell you whether to build, what to build first, and what to leave out, and they cost you little more than the time to have them. Talk to the past behaviour of five real potential customers, look for the patterns that repeat, and let those patterns write the scope of your first version.
When you have your five conversations and a clear sense of the one job your product must do, the next step is turning that into a buildable plan, which is exactly the work we start with. If you want a hand shaping research findings into a scoped first build, send us a project brief and we will tell you honestly whether the signal is strong enough to build on yet. If you would rather sharpen the plan first, our checklist for scoping an app project picks up right where the research leaves off.
.webp)
.webp)
