Before You Build, Price, or Launch, Ask for Decision Evidence
The meeting sounds evidence-rich.
The product lead quotes a customer. Sales quotes three prospects. Customer success quotes a renewal risk. Marketing quotes a campaign result. The founder quotes a conversation from last week.
Everyone has signal.
Nobody has enough evidence.
This is how teams make large decisions from scattered fragments. Not because they are careless. Because the fragments feel real. They came from customers, prospects, metrics, tickets, recordings, notes, reviews, and calls.
But the material arrived in the wrong shape for the decision.
It is too shallow, too scattered, too biased toward the loudest account, or too detached from the moment the customer actually made a choice.
Before you build, price, launch, reposition, or prioritize, ask a harder question:
What evidence would make this decision responsible?
Start with the decision
The weak first question is:
What feedback should we collect?
The better first question is:
What decision are we trying to make?
That shift changes everything.
If the decision is pricing, you need evidence about perceived value, alternatives, budget ownership, internal justification, package fit, proof gaps, and urgency.
If the decision is roadmap priority, you need evidence about frequency, severity, workaround cost, affected roles, existing alternatives, and the moment the problem becomes urgent.
If the decision is positioning, you need evidence about customer language, buying triggers, objections, comparisons, credibility, and what almost stopped the buyer.
If the decision is onboarding, you need evidence about the first confusing moment, expected value, handoffs, ownership, setup burden, and time to first proof.
Same customer base. Different decision. Different interview.
Generic feedback cannot carry all of that.
Name the current belief
Every important decision already has a belief hiding inside it.
Write it down before you interview anyone.
We believe customers churn because they do not reach value in the first 14 days.
We believe buyers hesitate because the category is unclear.
We believe this feature request is a symptom of a broader workflow problem.
We believe price is not the real objection. The real objection is weak proof.
We believe the homepage is using our language, not the buyer's language.
Now the research has a job.
It is not there to collect more comments. It is there to test the belief.
That matters because teams are very good at using customer anecdotes to protect the decision they already wanted to make.
Decision evidence should make the team less comfortable with weak certainty.
Interview the missing audience
Most teams over-sample whoever is easiest to reach.
Happy customers. Loud customers. Friendly buyers. Recent users. The account that already knows the founder. The person who gave the strongest quote.
Those people matter, but the missing audience often holds the decision evidence.
Ask whose voice is absent:
customers who stayed but never expanded
users who activated and then went quiet
prospects who chose another option
buyers who hesitated and then purchased
customers who gave a low score but no explanation
new customers who just finished onboarding
support-heavy customers who still renewed
If you only interview people who confirm the team's preferred story, the research will look clean and stay weak.
Set an evidence threshold
Before the interviews, decide what would be enough to change the decision.
You do not need false precision. You need a standard.
Examples:
If eight out of twelve churned customers describe the same onboarding failure, we will prioritize that fix.
If buyers repeatedly compare us to a cheaper adjacent tool, we will rewrite the value story before changing price.
If customers who love the product still cannot explain the value internally, we will create better proof before the next launch.
If the feature request is really a workflow problem, we will design for the workflow before committing roadmap capacity.
Without an evidence threshold, the team can explain away anything uncomfortable.
The point of research is not to remove judgment. It is to make judgment harder to fake.
Turn the decision into a voice interview
Once the decision is clear, the interview can be focused.
Open with context:
We are trying to understand what happened around this decision so we can decide what to build, fix, price, or explain next.
Then ask for the real situation:
What were you trying to accomplish?
What did you expect would happen?
What actually happened?
Can you give a specific example?
How often did that happen?
Who else was affected?
What did you compare us against?
What almost stopped you?
What would have changed your decision?
If we fixed one thing first, what should it be?
The goal is not a longer interview. The goal is to avoid stopping at the first answer.
People will say more in three minutes of voice than they will type into a form. The useful part is what the follow-up does with the moment where the meaning appears.
What the report should answer
A good report should make the next meeting shorter.
It should answer:
What decision were we trying to support?
What did the team believe before the interviews?
Which assumptions held up?
Which assumptions weakened?
Which themes appeared across conversations?
Which quotes explain those themes in the customer's own words?
Which audience segments differed?
What should we do next?
What is still unknown?
Without transcripts and quotes, the report becomes another opinion with cleaner formatting.
The team needs the pattern and the source.
The point
Do not ask customers for feedback because feedback sounds virtuous.
Ask the people your business depends on for evidence because a decision is waiting.
Lemma helps teams send one voice interview link, ask adaptive follow-ups, and turn the answers into transcript-grounded themes, quotes, reports, and next actions.
Start from the Customer Discovery Interview template before the next product, pricing, launch, or positioning decision becomes another debate from fragments.