How many customer discovery interviews should a founder do?

Many founders aim for around 15 to 20 conversations with one clearly defined customer type, then look for repeated patterns. Stop when new interviews no longer teach you anything surprising, not when you hit a fixed number.

Should I pitch my idea during the interview?

Not at the start. Spend most of the conversation learning about their current behaviour and problems. Show or describe a solution only at the end, and treat reactions cautiously since people are polite.

Who should I interview first?

People who currently have the problem and are already trying to solve it, even with spreadsheets or workarounds. Avoid friends and family unless they genuinely match your target customer.

What is the Mom Test?

It is a well-known idea from Rob Fitzpatrick's book of the same name: ask about people's real past behaviour and specifics, not hypothetical opinions, so that even your mother could not lie to you about your idea.

How do I know if the demand is real?

Look for commitment, not compliments. Real signals include time, money, introductions and access to data. Examples are agreeing to a pilot, paying a deposit, introducing a colleague or sharing their current process.

Customer Discovery Interviews: Questions That Reveal Real Demand

Most failed products were not badly built. They were built for a problem that was not painful enough, or not shared by enough people willing to pay. Founders often discover this after months of development, when the launch is quiet and the early feedback is a polite "looks nice". The cheapest way to avoid that outcome is to talk to real people before you write code. Done well, customer discovery interviews reveal whether a problem is real, who has it, how they solve it today and what they would pay to fix it.

Done badly, they produce false confidence. This guide explains how to run interviews that surface truth, with example questions, a step by step process and the traps that catch first-time founders.

What customer discovery is, and what it is not

Discovery is a research activity. Your goal is to learn about the customer's world, not to convince them of your idea. It is different from a sales call, a survey and a usability test:

Not a sales call: you are not asking for a purchase decision yet.
Not a survey: surveys are good for measuring something you already understand, but weak for discovering things you do not know to ask about.
Not a usability test: you are exploring the problem, not evaluating a screen design.

It is also a good first step before a product discovery sprint, which takes what you learn in interviews and turns it into a tested concept and a focused scope.

Why people give you misleading answers

Humans are kind. If you describe your idea and ask "Would you use this?", most people say yes. It costs them nothing, and they do not want to hurt your feelings. They are also bad at predicting their own future behaviour. "I would definitely pay for that" often means "that sounds interesting".

The solution is to stop asking for opinions about the future and start asking about the past. What did they do the last time this problem occurred? What did it cost them? What did they try? Facts about past behaviour are far harder to fake than predictions.

A real-world style example

Suppose a founder wants to build an app for small clinics to reduce missed appointments. The first idea is a reminder tool. In early interviews with clinic owners, the founder asks, "Would you pay for automatic reminders?" and hears plenty of enthusiasm. Later, using a better approach, the founder asks, "Tell me about the last time a patient did not show up. What happened next?"

The answers change the picture. Several owners already send WhatsApp messages by hand. The real pain is not sending reminders but refilling the empty slot at short notice, and keeping the front desk from being buried in rescheduling calls. The founder shifts focus from reminders to waitlist filling and easy rescheduling. This is an illustrative scenario, but it shows how good questions can redirect a product before a line of code is written. If you are exploring this space, our guide to what small clinics really need from management software provides context on typical workflows.

Step by step: plan and run the interviews

Write down your riskiest assumptions. For example: the problem happens often, current solutions are inadequate, the buyer has budget, and the user will change habits. Rank them by how badly your idea fails if they are wrong.
Define a narrow customer segment. "Small businesses" is too vague. "Owner-run dental clinics in Tier 2 Indian cities with two to five staff" is something you can find and learn from.
Find people who match. Use LinkedIn searches, local business groups, industry events, your network's introductions and communities where your segment gathers. Be direct: "I am researching how clinics handle missed appointments. Could I ask you a few questions for 20 minutes? I am not selling anything."
Prepare a short guide, not a script. Choose five to eight open questions focused on the past and the present. Leave room to follow interesting threads.
Run the conversation. Start with their role and context, move to recent specific events, explore current solutions and costs, and close with a few questions about next steps.
Take notes or record with permission. Capture exact phrases. Their words become your future landing page copy and sales messaging.
Debrief within a day. Write what surprised you, what you heard repeated and what you would change in the next interview.
Synthesise after each batch of five. Group notes into themes, count how many people mention each problem, and update your assumptions list. Adjust your segment or questions as needed.

Questions that work

Understand their context

"Walk me through how you handle [task] today, step by step."
"Who else is involved in that process?"

Explore a specific past event

"Tell me about the last time [problem] happened. What led up to it?"
"What did you do next? How long did it take?"
"What was the most frustrating part?"

Learn about current solutions and cost

"What have you tried to fix this? What happened?"
"Do you currently pay for any tool or service for this? How much?"
"What does it cost you in time or lost revenue when this goes wrong?"

Test priority and commitment

"Where does this problem rank among your top three challenges right now?"
"If I built something that solved this, what would you need to see before you tried it?"
"Who else should I speak with?" (an introduction is a meaningful signal)

Questions to avoid

"Do you think this is a good idea?" People will say yes.
"Would you pay for this?" Hypothetical answers are unreliable.
"Do you want feature X?" You will collect a wish list, not priorities.

How to read the signals

Not all positive responses are equal. Rank what you hear by the commitment behind it:

Weak signal: compliments, "sounds interesting", "let me know when it is ready".
Medium signal: detailed stories of the problem, sharing the spreadsheet or tool they use, spending time with you.
Strong signal: introductions to colleagues, access to data, a signed pilot letter, a deposit or a pre-order.

A founder who collects several strong signals from one segment has a far better foundation than one who has twenty compliments. Test demand cheaply as a next step. A simple waitlist landing page can show whether strangers outside your network take action.

Turning interviews into decisions

After around ten to fifteen conversations, patterns appear. Write a one page summary that answers:

Who exactly has the problem, and how often does it occur?
What do they do today, and what does it cost?
What triggers them to look for a better option?
Who decides, who uses and who pays?
What would a minimal first version need to do to earn a trial?

Use this summary to scope a lean first release. Founders who skip this step tend to over-build. Pairing discovery with realistic planning also helps avoid delays, as discussed in our article on why software timelines slip and how to scope an MVP.

It also helps to decide in advance what would make you stop or change direction. For example, if fewer than a handful of interviewees describe the problem as urgent, you might narrow the segment or explore a different problem. Writing the rule beforehand protects you from rationalising weak evidence later.

Practical tips for the conversation itself

Keep interviews to around twenty or thirty minutes, and tell the person at the start that you are here to learn, not to sell. Silence is useful: after someone answers, wait a few seconds, because they often add the most honest detail when nobody interrupts. Ask "why" gently and follow it with "can you give me an example?" to move from opinions to stories. If the conversation is remote, record with permission and review the transcript later. Thank everyone afterwards and send a short note describing what you learned. People remember being heard, and many will help again when you have something to test.

Key benefits of disciplined discovery

Lower risk: you test the idea before investing in development.
Sharper positioning: you learn the words customers use for their pain.
Better scope: you identify the smallest feature set that matters.
Early sales leads: interviewees who care often become pilot users.
Stronger fundraising stories: investors respond to evidence from real customer conversations.

Common mistakes founders make

Interviewing the wrong people. Friends and colleagues are not your market unless they truly fit.
Pitching too early. Once you pitch, people respond to the pitch, not to their own reality.
Talking more than listening. Aim for you speaking a small share of the time.
Leading questions. "Don't you find it annoying when...?" plants the answer you want.
Only seeking confirmation. Look actively for evidence that you are wrong. That evidence is the most valuable thing you can gather.
Never writing anything down. Memory favours what you hoped to hear.
Treating interviews as one-off. Keep talking to customers after launch. Discovery is a habit, not a phase.

Conclusion

Customer discovery is inexpensive, uncomfortable and extremely effective. A few weeks of honest conversations can save months of building the wrong thing. Focus on past behaviour, listen for commitment rather than compliments, and let the evidence shape your scope.

When you are ready to turn validated insights into a real product, our team can help you plan and build it. Visit our page on SaaS development services to see how we take startups from validated idea to a launched product.

Frequently Asked Questions

How many customer discovery interviews should a founder do?: Many founders aim for around 15 to 20 conversations with one clearly defined customer type, then look for repeated patterns. Stop when new interviews no longer teach you anything surprising, not when you hit a fixed number.
Should I pitch my idea during the interview?: Not at the start. Spend most of the conversation learning about their current behaviour and problems. Show or describe a solution only at the end, and treat reactions cautiously since people are polite.
Who should I interview first?: People who currently have the problem and are already trying to solve it, even with spreadsheets or workarounds. Avoid friends and family unless they genuinely match your target customer.
What is the Mom Test?: It is a well-known idea from Rob Fitzpatrick's book of the same name: ask about people's real past behaviour and specifics, not hypothetical opinions, so that even your mother could not lie to you about your idea.
How do I know if the demand is real?: Look for commitment, not compliments. Real signals include time, money, introductions and access to data. Examples are agreeing to a pilot, paying a deposit, introducing a colleague or sharing their current process.