Your first customer discovery call is the start of the front-end journey as a founder and then a salesperson. It is a filtering exercise, where you throw out the nine ideas that only feel promising so the tenth one can get built with actual confidence.

That sounds routine, but it changes almost every decision that comes after it. What counts as useful evidence, which questions are worth asking and when to stop talking to people and start building.

The hardest part of customer discovery is knowing what to do with what you hear. One person says they need a feature, another says they would pay for it and suddenly the roadmap starts filling up. Good discovery means being able to step back and ask whether you are hearing a real problem or just a collection of opinions.

What Does a Typical Failed Discovery Call Look Like?

In essence, it looks like a quiet failure.

Twelve calls get booked. Nine actually happen. In eight of those nine, the founder explains the product within the first three minutes, then asks some version of “Would you use something like this?” Seven people say yes, or something close enough to yes that it gets counted as one.

The roadmap gets built around the feature that came up most in those eight calls. Three months later it ships. And nobody who said yes on the call ever opens it.

This happens when a discovery call asks “Does this sound good?” instead of “What have you actually done to solve this problem?” People will usually be polite when you describe a product to them and ask if they would use it. That can make almost any idea look like it has demand.

Two other symptoms show up in almost every failed batch of calls across every industry or product category.

The interviewer talks more than the interviewee

Take a failed call and look at the transcript. Count how many words each person spoke. The founder is usually explaining, giving context or defending the idea for most of the call. If the founder talks less than the person being interviewed, that is already a good sign that the conversation gave you something useful.

Every note reads like a feature request

The notes say, “They want a dashboard.” “They asked for Slack integration.” Nothing about when the problem last came up, how they deal with it today or what happens when they leave it unsolved. Feature requests are easy for customers to give you but hold very less value at that stage for you. They are someone’s idea for a solution, not proof that you have found the real problem.

If your recent calls look like this, don’t take it as a reason to give up on discovery. It usually means you are asking the wrong questions or talking to the wrong people. The calls happened, but they didn’t give you anything that could actually change what you build.

How Do You Get People to Agree to a Discovery Call

Recruiting people for customer discovery is different from finding your first ten real users, but people often treat them as the same thing. A user is someone who might try your product. An interviewee is someone willing to spend fifteen minutes talking honestly about a problem. That means the ask needs to be smaller and the way you approach them needs to be different.

The biggest reason people ignore discovery messages is that they sound like a pitch. “We are building X, would love to show you” asks a stranger to judge your product when they have no reason to care about it yet. People are more likely to reply when you ask for their experience instead. You’re trying to understand a problem, so talk to someone who has actually dealt with it. That small change can affect both who replies and how openly they talk.

Where to actually find these people:

• Existing customers or free users: They already know you, so you can skip the pitch and ask how they currently deal with a problem.

• Communities where the problem gets discussed regularly: A subreddit, a niche Discord or a LinkedIn comment where someone has already complained about the exact problem you are planning to solve. If someone has talked about the problem publicly, they are usually much easier to interview and more likely to give you an honest answer.

• Warm introductions through your network: Asking someone “Do you know anyone who deals with X?” can get you a stranger who has no reason to be polite or tell you what you want to hear.

Whichever channel you use, the messages that get replies are short, clear and honest about what you are asking for. Nothing to buy and nothing to sign up for. Send that to the right ten people and you will get more useful conversations than sending cold DMs to 100 prospects.

What Should You Actually Ask in a Customer Discovery Interview

There is no mention of your product anywhere, just pure pain discussion. The interview should work even if your product doesn’t exist yet. You are not testing your solution. You are trying to find out if the problem is real, recent and costly enough that someone has already tried to solve it. That’s also why SaaS business ideas that have actual scope in 2026 often start with problems people are already spending money to solve, rather than problems a founder simply thinks might exist. Paying customers have already tested the problem for you.

The DISCOVER Framework

Real interviews often do not follow a script for thirty minutes. Having questions grouped by what you want to learn from each one makes it easier to bring the conversation back to useful evidence when it starts drifting into opinions. Eight categories, spelling DISCOVER, cover the main areas a discovery interview needs to explore.

Detail (D) Keeps the conversation focused on one specific event that actually happened, rather than a general impression.

• "Walk me through the last time this actually happened, start to finish."

• "When exactly was that? Last week, last month?"

• "What were you doing right before you ran into this?"

Impact (I) Shows what the problem is costing them, so you have a clear number to judge how urgent it really is.

• "How much time would you say that took?"

• "Did it cost you anything directly, a client, a deadline, a sale?"

• "If you added it up over a month, what would that look like?"

Substitute (S) Shows what they are using right now, which is your real competition

• "What are you doing about this today, without any new tool?"

• "Is that a proper tool, a spreadsheet or just tolerating it?"

• "What don't you like about the way you are solving it now?"

Commitment (C) Check whether they have already spent money or put real effort into solving the problem, which tells you more than what they say they might do later.

• "Have you paid for anything to try to solve this?"

• "How much are you willing to spend for a tool that fixes this?"

• "Has anyone on your team spent real time trying to patch this?"

Occurrence (O) Find out how often the problem actually happens, based on what they remember rather than a rough guess.

• "How often does this come up, roughly?"

• "Is this a daily thing, weekly or occasional?"

• "Was last time typical, or worse than usual?"

Vision (V) Find out what a real solution would look like to them, based on their definition rather than the founder’s.

• "If this just went away tomorrow, what would change for you?"

• "What would 'handled' actually look like, day to day?"

• "Is there a version of this that's already good enough, or does it need to be perfect?"

Extent (E) Check whether other people face the same problem, without turning the conversation into a request for referrals.

• "Do other people on your team deal with this too?"

• "Is this specific to how you work, or pretty common in your role?"

• "Have you heard other people complain about the same thing?"

Reaction (R) Capture the exact words they use, because the way they describe the problem can tell you how strongly they feel about it.

• "How would you describe it when it happens, in your own words?"

• "Is that a mild annoyance or something that genuinely frustrates you?"

• "What's the first thing you think when it happens again?"

Not every call needs all eight questions in order. Most conversations naturally cover Detail and Substitute early, then move toward Impact and Commitment once the person is more comfortable. The categories are there to guide the conversation, so if a call is running long but still feels thin, you can quickly see what information is missing.

How Do You Run the Call So People Actually Open Up?

Getting the questions right solves maybe half the problem. The other half is about how the fifteen minutes actually unfold.

Let the silence sit: After you ask a question, it’s tempting to fill the silence with another question or explain what you meant. Don’t. Wait a full five seconds. Some of the most useful answers come after that pause, when the person has a moment to think of the detail they almost forgot to mention.

Don't defend the idea: If someone points out a problem with an assumption behind your product, it’s an instinct to explain why they are wrong or how a future version will fix it. Once people see that criticism gets argued with, they will stop sharing it for the rest of the conversation.

Take notes by hand or in a way that doesn't look like transcription: Typing nonstop changes how people talk. It can make the conversation feel more like an interview than a normal chat, so people give shorter, safer answers. If they are okay with it, record the call and keep your live notes light.

End with one open door: “Is there anything you expected me to ask that I didn’t?” This question often brings out information you would have missed otherwise. It gives the other person a chance to talk about what they think matters, instead of keeping them inside your list of questions.

What's the Formula for Scoring a Discovery Finding?

“A lot of people mentioned it” does not tell you what to build first. Two problems can come up often and still need very different places on the roadmap. How often people mention a problem does not tell you how badly they need it solved. A real priority needs numbers.

Score each interview where a given problem came up, using four signals:

Named workaround exists: 0 points if none, 1 point if they described a specific current fix.

Quantified cost stated: 0 points if vague ("annoying"), 2 points if a number was given (hours, dollars, a lost deal).

Money or effort already spent chasing a fix: 0 points if none, 2 points if they've paid for something or actively searched.

Urgency language: 0 points for "sometimes" or "occasionally," 1 point for "every time" or "constantly."

That gives each interview a score from 0 to 6 for that problem. Average the score across every interview where the problem came up, then multiply by how many people raised it independently.

Problem Score = (number of people) × (average per-interview score).

The multiplication matters because neither number tells you enough on its own. A problem mentioned by seven people with an average score of 4 gets 28. A problem mentioned by only three people with a score of 6 gets 18. The first one ranks higher because more people have the problem and it has a real cost. Without this formula, a few detailed conversations can easily seem more important just because they were easier to remember.

This also helps with a common problem in synthesis meetings. Two people remember the same calls differently and disagree about what mattered most. Having a number gives everyone something concrete to work with instead of arguing. Good discovery gives you evidence about what matters to users. From there, you need a clear way to measure what happens next. Choosing the right startup analytics framework can help you track the signals that actually matter instead of collecting numbers for the sake of it.

The Real Point of the Discovery Call

This is bigger than interviews. A roadmap is a series of decisions and each one depends on the evidence behind it. A founder who runs ten focused discovery calls and properly reviews them may do less work than someone who runs thirty vague calls and never reviews what they heard. The difference is that the first founder can point to the exact conversation and score behind the next thing they decide to build.

That’s the kind of customer discovery worth making time for when a founder already has a full calendar. It’s not research just for the sake of research. It’s a short, focused process that turns fifteen minute conversations into decisions you can still explain and defend six months later.

At ByteHint, this is where every engagement starts. We look at the evidence behind the product before we start talking about features. We review the founder’s discovery notes, or help them run the interviews if that work hasn’t happened yet. Then build the roadmap around what the scores show instead of whichever idea sounds best in the room. If you have already run the calls and have a pile of notes but no clear next step, that’s where we pick up.

FAQs

1. How many customer discovery interviews should a first-time founder run before building anything?

Ten to twelve with a genuinely similar group is usually enough to know whether a pattern is real, based on saturation research from qualitative interviewing. Fewer than that, and a single vocal person can look like a trend.

2. Should customer discovery interviews happen before or after building an MVP?

Before, whenever possible. The entire value of discovery is that it's dramatically cheaper than a build. Interviews that happen after launch still matter, but by then you're validating with sunk cost already spent rather than avoiding it.

3. What's the difference between a customer discovery interview and a sales call?

A sales call is trying to move someone toward a decision about your product. A discovery interview is trying to understand a problem that would exist whether or not your product ever gets built. Mixing the two, even slightly, contaminates the data, because the person can feel when they're being sold to and starts answering more politely.

4. Is it okay to interview friends or existing contacts for customer discovery?

Only for practice, not for real signals. Someone who has a personal relationship with you has an incentive to be encouraging that a stranger doesn't share, and that incentive quietly distorts everything they tell you, usually without either of you noticing it happening.

5. What if nobody mentions the problem I expected to hear about?

That's a finding, not a failed interview round. It usually means the problem is less urgent than assumed, or it's real but attached to a different group of people than the ones being interviewed. Either way, it's cheaper to learn that from ten conversations than from three months of engineering time.