Customer Discovery Isn't Asking People If They Like Your Idea

Imagine a founder wants to build an AI-powered scheduling assistant for independent dental clinics.

She's heard the same complaints from dentists: patients cancel at the last minute, others don't show up, and empty appointment slots mean lost revenue.

Her proposed solution would identify likely cancellations, contact patients on waiting lists, and automatically fill empty slots. She believes clinics would pay $199 a month. She has six months of runway and wants an MVP ready in eight weeks. Sounds like a reasonable opportunity. But is it?

Before building anything, I'd want to understand whether clinics have a problem they're willing to spend money solving, or simply one they're tired of dealing with.

That's where customer discovery comes in.

Start With the Customer, Not the Product

Customer discovery is often described as identifying who your customers are. But knowing who might buy your product is only part of it. You need to understand how people behave, what problems they experience, how they're solving them today, and whether those problems are important enough to do something about.

There's also an important distinction between your customer and your user.The customer pays for the product. The user interacts with it. Sometimes they're the same person, but often they're not.

In our dental clinic example, the receptionist might use the software every day, while the clinic owner decides whether it's worth paying for. The receptionist wants fewer phone calls, less manual coordination, and an easy-to-use system. The owner wants fewer empty appointments, better use of resources, and a financial return that justifies the subscription.

A good product needs to address both.

Stop Asking People to Approve Your Idea

One of the most common mistakes during customer discovery is asking leading questions or making assumptions about someone's behaviour. Rather than asking whether they'd use automated scheduling software, I'd ask the receptionist to walk me through the last time a patient cancelled. How much notice did they give? How was the appointment confirmed? What happened after the cancellation? Did someone call patients on the waiting list? How many calls did it take? Was the slot filled?

I'd also want to understand what happens when someone confirms and still doesn't show up. Does the clinic charge cancellation fees? Do patients typically reschedule? How often are appointments permanently lost?

And importantly, who actually feels the impact?

But asking better questions is only part of it. I'd want to understand how often these situations occur, how much time they consume, and what happens when the clinic can't resolve them. A receptionist spending thirty minutes filling an appointment might sound inefficient. But if that happens once a month, it's a very different problem from something happening several times a day. Whenever possible, I'd compare interview responses with actual appointment records rather than relying entirely on estimates.

The goal is to understand what people are already doing, where the process breaks down, and what the consequences are.

Not Every Clinic Is the Right Customer

A clinic experiencing cancellations isn't automatically a potential customer.

Imagine two clinics.

Clinic A loses ten appointments a week but has no waiting list. Most cancelled patients eventually reschedule, and the clinic struggles to find replacements at short notice.

Clinic B loses fewer appointments but has an active waiting list. Its receptionist regularly spends hours contacting patients to fill newly available slots.

Which clinic is more likely to benefit from automated scheduling?

I'd investigate Clinic B first. The opportunity isn't necessarily where complaints are loudest. It's where the problem is frequent, costly, and realistically solvable.

That means looking beyond clinic size.I'd want to understand appointment volumes, waiting lists, cancellation patterns, types of treatment, existing scheduling software, and how much administrative time goes into filling cancelled slots. I'd also want to establish whether recovering an appointment actually creates additional revenue, rather than simply moving a patient's visit from one day to another.

And I'd speak to both the people managing appointments and those approving software purchases. A receptionist struggling with manual calls might love the proposed solution. But if the owner doesn't see a meaningful financial benefit, there's no reason to assume they'll buy it. Understanding both perspectives helps identify which customers are worth pursuing and what the product would actually need to deliver.

Interest Doesn't Establish Willingness to Pay

Suppose several clinic owners say they'd love to see a demo. That's encouraging, but it doesn't establish demand. I'd first want to know what they've already tried.

Have they introduced cancellation fees? Changed their reminder process? Purchased scheduling software? Hired additional administrative staff? Previous attempts to solve a problem can reveal how much priority it has. 

Then comes pricing. Asking, "Would you pay $199 a month?" gives you a hypothetical answer without establishing what the problem is worth. I'd want to understand the economics from the clinic owner's perspective.

For example, suppose the proposed service could recover three otherwise lost appointments a month, each generating $75 in additional revenue after the variable costs of treating the patient. That's $225 in monthly contribution before the $199 subscription, leaving just $26 before accounting for setup, training, or additional administrative effort.

These are hypothetical numbers, but they illustrate an important distinction. A service can solve a genuine problem without creating enough value to justify what it costs. Of course, recovering more appointments or saving substantial staff time could change that calculation. That's what discovery needs to establish. Eventually, I'd want to test actual commitment. Would a clinic agree to a paid pilot? Would the owner allocate a budget? Would the staff commit time to trying a different process? And we wouldn't necessarily need to build an AI product to test the underlying value.

For a small pilot, the founder could work with clinics to manually coordinate openings and waiting lists, using their existing scheduling systems and approved communication processes. That could help establish how many appointments can realistically be recovered, how much administrative work is involved, and whether the owner values the outcome enough to pay for it. It wouldn't prove that an automated AI system could deliver the same results. But it would tell us something important about the opportunity before committing to development.

The point is to find evidence of commitment, not just interest.

Know When to Stop

There's one question I'd establish before discovery begins:

What would we need to learn to decide this isn't worth pursuing?

If most clinics don't have waiting lists, automated scheduling may not fill many empty slots. If patients usually reschedule, the actual revenue loss might be smaller than the complaints suggest. If existing software already handles the process well enough, the benefit of switching could be marginal. And if clinics acknowledge the problem but won't commit time or money to solving it, I'd question whether it deserves another eight weeks of development. That doesn't mean walking away after one disappointing interview. It means establishing what would invalidate the opportunity instead of continually looking for reasons to build.

It's equally important to define what would justify moving forward.

I'd want repeated evidence of costly, recoverable appointment gaps, a customer segment that existing solutions aren't serving well, and clinic owners willing to commit to a credible pilot. I'd also want the economics to make sense. Recovering an occasional appointment isn't enough if the additional value barely covers the cost of the software.

With six months of runway, that's a distinction worth making early.

The Goal Isn't to Validate Your Idea

The founder might be right. Dental clinics may have a meaningful scheduling problem, and software may be a good way to solve it.

But we haven't established that yet.

A receptionist might find the current process frustrating. An owner might agree that cancellations are expensive. Both might like the idea of an AI assistant. None of that necessarily means they'll pay for it.

Before committing eight weeks to an MVP, I'd want evidence that the appointments are recoverable, the economics work, and clinics are willing to change how they operate. That evidence might lead to an MVP, a different customer segment, or a decision not to build at all. All three can be useful outcomes of discovery.

Don't just validate the problem. Validate whether it's worth solving, for whom, and at what cost.

Sometimes the most valuable outcome of customer discovery isn't figuring out what to build.

It's knowing what not to build before you've spent the time and money.