No time to read?
Key takeaways
- A customer interview validates a problem, it does not get people to like your idea: you talk about their past, never about your solution.
- Compliments ("great idea, I'd use it") are poison: they push you to build a product nobody will buy.
- A dozen well-run interviews are enough to see whether the problem is real, and save you months of coding in the void.
You have a SaaS idea and the urge to open your editor right now. When you know how to build, the reflex is to code first and "see if it sticks" later. But the market punishes that impatience with depressing consistency: the number one reason startups fail is neither the tech nor the cash, it is building something nobody wants.
The customer interview is the cheapest antidote there is. Twenty minutes of conversation with the right person teaches you more than a month of development. You just have to ask the right questions, because a badly run interview lies to you as smoothly as your own enthusiasm does.
Why customer interviews change everything before you code
The trap when you can build a product is solving a problem you invented. You see the architecture, the screens, you feel it would be useful. But "it would be useful" is not "people would pay me for it." Between the two lies a gap, and the customer interview is the only bridge that crosses it without ruining you.
42%
fail from no market need
12
interviews to saturate the themes
80%
of the signals in the first 6
In its analysis of startup post-mortems, CB Insights ranks "no market need" as the top cause of failure, at 42%, ahead of running out of cash and the team. The good news is that this risk can be tested by hand, fast. The landmark study by Guest, Bunce and Johnson (2006) shows that in qualitative research, thematic saturation is reached within about a dozen interviews, and 80% of the recurring ideas surface in the first six. Translation for you: you do not need a hundred conversations to decide, you need a dozen good ones.
Twenty minutes of listening beat a month of coding. The keyboard can wait until the problem is proven.
Discovery interview or usability test: do not confuse them
Many people mix up two things that have nothing to do with each other, and reassure themselves with the wrong one. The discovery interview validates the need, before you build. The usability test validates the use, once there is something to show. Doing one while thinking you are doing the other is the surest way to validate a mockup for a problem that does not exist.
| Criterion | Discovery interview | Usability test |
|---|---|---|
| When | Before coding, on the idea | On a prototype or an MVP |
| Question | Does the problem really exist? | Can people use the product? |
| Focus | The person's past and daily life | The screens, the flow, the buttons |
| Fatal mistake | Talking about your solution | Guiding the person during the test |
Remember the line: until you have proof of the problem through the discovery interview, testing an interface proves nothing. We cover this in detail in the SaaS usability testing guide, which takes over once the need is validated.
The questions that kill your customer interview
The real danger in an interview is not missing a piece of information, it is collecting a false positive. Your interviewee wants to be nice, so they compliment you, and you leave convinced you are right. That is the whole point of Rob Fitzpatrick's Mom Test: ask questions such that even your mom could not lie to you to make you feel good.
The three poisons of an interview
Compliments ("I love it, that's clever"), hypotheticals ("would you use a tool that...") and promises ("absolutely, I'd pay for that") are three forms of polite lie. None of them commits the person, none of them describes a fact. A future intention is worth nothing: only the past is data.
The switch is simple: stop talking about your idea, get the person talking about their life. Instead of "would you use an app to handle this?", ask "tell me about the last time this problem blocked you." Instead of "how much would it cost, in your opinion?", ask "what do you use today, and what does it cost you?". You are looking for dated facts, real workarounds, money already spent. That is the signal of a genuine problem.
Running a customer interview in five steps
A good interview lasts twenty minutes and never sounds like a recited questionnaire. It is a guided conversation where you talk little and dig a lot. Here is the frame you can reuse every time.
Set the scene without pitching
Anchor in the past
Dig into the pain
Look for money and time already spent
End with a door, not a sale
Write everything down word for word, especially the expressions used. The phrases your prospects repeat ("I waste so much time on...") are the gold of your future sales pitch and your value proposition. You do not invent the words that sell, you harvest them in interviews.
How many interviews, and how to read the signals
You do not need a polling institute. Aim for a dozen interviews with people who truly look like your future customer, not your friends or your entrepreneur community. If you hear the same pains, the same workarounds, the same words come back, you are onto a solid pattern. If every person describes a different problem, your idea is not framed tightly enough yet.
At the end, you should be able to tick the boxes honestly. Not "sort of", not "it depends". A soft box is a signal, not a detail to ignore.
My customer interview holds up
0 / 5A no-go is a win
If the interviews do not confirm the problem, you just saved months. You did not fail, you avoided building in the void. Reframe the problem, change target or angle, and go listen again. A pivot at the idea stage costs a week; at the finished-product stage, it costs everything.
From listening to your first product
The customer interview is not a box to tick, it is the foundation of everything that follows. Validated problems become your MVP, harvested words become your pitch, and the people you interviewed become your first users. To go further, combine this listening with a SaaS market research that triangulates demand, structure what you learn through the lens of jobs to be done, and keep the end goal in mind: reaching product market fit by iterating with real people. Validation and distribution do not wait for the code to be finished: they move alongside it.
The founder who wins is not the one who codes fastest. It is the one who took the time to listen before building, and who already knows who to talk to the day the product is ready.
Your problem is validated, now what?
Answer two questions and get an acquisition diagnostic tailored to your stage.