Customer Discovery Should Explain Why People Buy, Not Just What They Want
Customer discovery is not supposed to produce a feature list.
It is supposed to explain a buying decision.
That distinction gets lost quickly.
A customer asks for a dashboard. Another asks for an integration. Someone wants lower pricing, faster setup, better reporting, cleaner permissions, or a simpler workflow. The team clusters the requests, counts the mentions, and calls it evidence.
Feature requests are clues. They are not strategy.
A customer might ask for a dashboard because they need internal proof. They might ask for an integration because adoption is blocked by another team. They might ask for a lower price because they do not understand the value. They might ask for simpler setup because they are not the buyer. They are the person who has to live with implementation.
Discovery is useful when it reveals why someone buys, hesitates, switches, stays, or leaves.
It is weak when it only records what people say they want.
Stop asking customers to design the product
The weak discovery question is:
What would you want this product to do?
It sounds customer-centric. It is often a way to outsource product judgment to people who do not have the full context.
Customers can be generous with ideas they would never pay for, never implement, and never defend internally.
Better discovery starts from behavior:
What are you trying to accomplish now?
How do you handle it today?
What breaks or slows down?
What happens when the problem is not solved?
Who notices?
What have you tried already?
What made you look for something else?
What would make you switch?
The goal is not to collect wishes.
The goal is to reconstruct current reality.
Find the current alternative
Every customer has an alternative.
Even if they say they do not.
The alternative might be a competitor. It might be a spreadsheet. It might be a consultant. It might be a manual process. It might be doing nothing. It might be one senior person who knows how to handle the messy cases.
If you do not understand the current alternative, you do not understand the buying decision.
Ask:
What do you use today?
What works well enough that you tolerate it?
What is painful but not painful enough to change yet?
What would be hard to replace?
Who would resist a new option?
What would need to be clearly better before you changed?
This is where real competition appears.
The competitor is not always the company in your category. Sometimes the competitor is inertia with a spreadsheet and a senior employee holding the process together.
Find the switch moment
People rarely wake up ready to buy.
Something happens first.
A launch misses expectations. A support backlog grows. A buyer cannot explain the value internally. A manual workaround breaks. A competitor wins a deal. A founder gets tired of guessing. A customer complains loudly enough that the team has to pay attention.
The switch moment is when the pain becomes active.
Ask:
When did this become worth solving?
What happened right before you started looking?
Why did the old way stop being acceptable?
Who pushed for a change?
What would happen if you waited another quarter?
What made this urgent now?
Interest is cheap. Urgency is the beginning of demand.
If the customer cannot describe the switch moment, the problem may be real, but the market motion may still be weak.
Find the objection before the feature request
A feature request often hides an objection.
"Can it export reports?" might mean, "I need to defend this decision to leadership."
"Does it integrate with our tools?" might mean, "I am afraid adoption will fail."
"Can we start smaller?" might mean, "I believe the value, but not enough to commit."
"Can we customize it?" might mean, "Our workflow is messier than your positioning admits."
Ask:
What would almost stop you from using this?
What would make this feel risky?
Who would need to be convinced?
What proof would they ask for?
What would make this feel like too much work?
Which part of the current approach would you be nervous to replace?
The objection is not a nuisance. It is often the clearest map of what the product, offer, proof, or message needs to solve.
Test the team's assumptions
Before interviewing customers, write down what the team believes.
We believe buyers want richer customer feedback before roadmap decisions.
We believe churn is caused by slow time to value.
We believe pricing hesitation is really weak proof.
We believe prospects compare us to manual interviews more than static forms.
We believe the homepage is using language buyers would not use themselves.
Then use the interviews to put pressure on those beliefs.
Ask questions that could prove the story wrong:
What did you compare us against?
What did you expect this would replace?
What almost stopped you from buying?
What would have made this feel unnecessary?
What did you need to believe before you could say yes?
The best discovery does not confirm the team's story.
It improves it.
What the discovery report should answer
A customer discovery report should not be a transcript dump or a feature-request list.
It should answer:
Which problem appears repeatedly?
Which buyer trigger makes it urgent?
Which current alternatives are customers using?
What language do customers use before they know your category?
What objections appear before purchase?
Which feature requests are symptoms of a deeper job?
Which quotes should product, marketing, sales, and leadership hear?
What should the team build, position, package, price, or test next?
Every theme should be grounded in quotes and transcripts.
Without the source, a report is just a polished opinion.
A customer discovery interview guide
Use this when you are validating a product, offer, feature, service, or positioning direction.
What are you trying to accomplish in this area right now?
How do you handle it today?
What works about the current approach?
What is frustrating, slow, expensive, risky, or unclear?
Can you walk through the last time this problem showed up?
Who else was involved?
What did it cost you in time, money, trust, or momentum?
What have you tried already?
What would make you look for something new?
What would make you trust a new option?
What would almost stop you from switching?
If this worked well, what decision would it help you make?
Notice what is missing from the first pass:
"What features do you want?"
Ask that later. First, understand the decision.
The point
Customer discovery should not end with a wish list.
It should produce evidence about the buying decision: the current alternative, the switch moment, the objection, the language, and the change a customer is willing to make.
Lemma turns that discovery into adaptive voice interviews and transcript-grounded reports, so the team can decide what to build, say, package, price, or test next.
Start with the Customer Discovery Interview template before the next feature request gets promoted into strategy.