Discovery vs validation interviews: which one do you need?

It is Tuesday evening. You have sketched the Slack integration three customers asked for, booked five calls for the week, and told yourself you are finally doing customer research.

Then the first call starts, and the first question quietly decides what kind of evidence you will get.

“What happened the last time reporting slowed your team down?” is a discovery interview question. “We are thinking of building a Slack integration. Would that be useful?” is a validation interview question, and not a very good one.

Both conversations look similar from the outside: same calendar invite, same 30 minutes, same polite customer. But discovery interviews and validation interviews answer different questions, create different evidence, and fail in different ways. When founders blur them together, they come away with notes that feel like learning but cannot support a product decision.

The cost is real. CB Insights’ March 2026 analysis of startup failure patterns looked at public post-mortems, founder interviews, and shutdown announcements from 431 VC-backed companies that shut down since 2023. “Ran out of capital” appeared most often, at 70%, but CB Insights frames that as the ending, not the root cause. Poor product-market fit appeared in 43% of identifiable failure reasons.

Most of those teams had talked to customers. The problem is that a conversation can record courtesy, not evidence, if you do not know which job the interview is supposed to do.

Discovery finds the problem. Validation tests a specific answer.

Use this distinction:

A discovery interview asks: What is actually happening for this person, and which problems are worth solving?

A validation interview asks: Does this specific thing we made, or plan to make, hold up against reality?

In discovery, you do not yet know what the product should do. You are trying to understand the problem space, the current workaround, the stakes, the language customers use, and the reason the old way is no longer good enough.

In validation, you have a candidate answer: a prototype, a landing page, a pricing package, a written concept, a workflow, a sales offer. You are trying to learn whether that answer survives contact with real behaviour.

A technical analogy helps. Discovery is profiling the system to find the real bottleneck. Validation is benchmarking the fix. If you profile after committing to the fix, you will mostly find evidence for the thing you already wanted to build. Customer conversations work the same way.

What a discovery interview is for

Nielsen Norman Group defines discovery as a preliminary UX phase for researching the problem space, framing the problems to solve, and gathering enough evidence for an initial direction. The most important sentence for founders is the caveat: discovery does not typically involve testing a hypothesis or evaluating a potential solution.

That means your idea stays out of the conversation.

A discovery interview is useful when you cannot yet describe the problem in the customer’s own words, or when you suspect your understanding is too thin. The goal is not to ask people what they want. The goal is to collect specific stories about what already happened.

Teresa Torres makes a practical distinction that improves interviews immediately: your research questions are not your interview questions. Your research question might be “why do trials stall in week two?” But asking that directly produces summaries, guesses, and rationalisations. The interview question is something like:

• “Walk me through the week you signed up.”
• “What were you trying to get done before you tried us?”
• “What happened the last time the old way broke down?”
• “Who else got involved?”
• “What did you do after you closed the tab?”

The answer to your research question lives inside the story.

Say you run a B2B reporting tool and trials keep going quiet after signup. A discovery interview with a stalled trial user does not open with your onboarding flow. It opens with the week they signed up. You might learn that the signer was evaluating on behalf of a colleague, the colleague was on holiday, and by the time she returned the trial had expired and nobody remembered the password. That is not a feature request. It is a story about buying, handoff, timing, and ownership. It changes what you would even consider fixing.

You know discovery is working when you can state the problem like this:

Three of eight admins rebuilt the same Monday export in a spreadsheet because they did not trust the dashboard totals.

That is stronger than:

Users find reporting frustrating.

One is a pattern with people, actions, timing, and consequence. The other is a mood.

What a validation interview is for

Validation starts after you have something concrete enough to test.

That thing can be rough. Nielsen Norman Group describes concept testing as showing an approximation of a product or service that captures its core value, not the full experience, so you can learn whether it fits the target audience’s needs. You do not need production software. You need enough specificity that the customer reacts to the actual idea instead of inventing their own version.

Marty Cagan’s four risks are useful here:

• Value: will customers buy it or users choose to use it?
• Usability: can users figure it out?
• Feasibility: can you build it with the time, skills, and technology you have?
• Business viability: does it work for the company?

For a technical founder, feasibility is often the comfortable risk. Value is usually the dangerous one. Validation interviews exist to face value risk before engineering momentum makes the idea feel inevitable.

The natural validation question is also the weakest one:

Would you use this?

Jakob Nielsen’s first rule of usability is to watch what people do, not trust what they say they do, and especially not trust what they predict they might do in the future. In Nielsen and Levy’s analysis of 113 interface comparisons, the correlation between measured performance and stated preference was 0.44. Preference is not useless, but it is a weak proxy for behaviour.

So validation needs harder evidence than liking.

For usability risk, give people a task and watch what happens. For this kind of evaluative usability testing, Nielsen’s five-user guidance is properly scoped: small rounds can reveal many problems when you fix and test again, rather than spending the whole budget on one large batch.

For value risk, look for behaviour and commitment. A useful validation interview ends with a next step that costs something appropriate to the stage: time with another stakeholder, access to real data, an introduction to the buyer, a pilot conversation, a signed agreement, or money. Generic praise is not validation. “Sounds useful, keep me posted” is not validation. It is politeness.

Rob Fitzpatrick’s The Mom Test is useful precisely because it treats customer conversations as a place where polite feedback can mislead you. The practical standard is simple: count what people have done, what they are doing now, and what they are willing to do next.

The expensive middle: failing at both

Most bad founder interviews are not purely discovery or purely validation. They are a muddled middle.

The first failure mode is the pitch disguised as discovery. You book a “learning call”, ask one broad question, then mention your idea by minute four because you are excited, uncomfortable, or trying to be helpful. From that point on, the conversation is contaminated. The customer is no longer describing their world. They are responding to yours.

You will collect compliments, feature ideas, and soft encouragement. Those feel good in the notes. They are not discovery evidence.

The second failure mode is validation with no chance of rejection. You show a prototype, ask “thoughts?”, collect adjectives, and call the concept validated. No task. No comparison with the current workaround. No buyer. No next step. No way to be wrong.

That is the core danger: you designed a conversation you could only win.

Which interview do you need this week?

Use this test before you recruit anyone.

Write one sentence, in a customer’s words, describing the problem you believe you solve. Then check three things:

1. Can you write it without using your product language?
2. Can you name at least three recent incidents where it happened?
3. Can you explain what the customer did instead?

If you fail any of those, run discovery interviews.

You might be right about the opportunity, but you do not have enough evidence yet to validate a solution. You would be benchmarking a fix for a bottleneck you have not profiled.

If you pass all three, ask a second question:

Is there a specific artefact or decision waiting?

If yes, run validation interviews. Show the thing. Set the task. Write down your prediction before the call. Ask for a next step that has a cost.

Here is the quick version:

That last row matters. If you notice yourself hoping the participant likes the idea, you are validating. That is exactly when the interview needs stricter evidence.

How to run a discovery interview

For discovery, use a small set of prompts and follow the story.

• “Walk me through the last time...”
• “What happened before that?”
• “What happened next?”
• “What did you do instead?”
• “Who else was involved?”
• “What made that worth dealing with?”

Stay in the past. Stay out of your product. Do not ask for feature ideas too early. If someone says “we need automation”, ask what happened the last time the manual process broke. “Automation” is the label. The story underneath is the evidence.

Recruit people who recently lived the problem: a trial that stalled last month, a customer who switched from a competitor this quarter, an admin who just set up the workflow, a buyer who said no after a serious evaluation. Recency matters because discovery runs on specific memory. Old stories become tidy summaries.

You have enough for now when the same causal pattern repeats across different people. For a deeper treatment of sample size, see Maren’s guide on how many users you should interview. The short answer is that you are not estimating a population average. You are looking for repeated patterns strong enough to change a product decision.

How to run a validation interview

For validation, prepare the artefact and the evidence standard before the call.

Write down:

• What you believe is true.
• What the participant should be able to do or recognise.
• What behaviour would strengthen the case.
• What behaviour would weaken it.
• What next step would count as commitment.

Then run the interview around the artefact, not around your explanation of it.

If it is a prototype, give a task: “Imagine you need to invite finance and send the first report. Start wherever you would start.” Watch before explaining. If they get stuck, note where and why. Do not rescue the session too early.

If it is a concept, anchor it in a recent event: “Think back to the last time you had to prepare this report. Where would this have fit?” If they cannot connect the concept to a real moment, that is evidence.

If it is pricing, compare against a current budget, current tool, or current pain. “Would you pay €99?” is weak. “What would this replace in your current stack?” and “Who would need to approve it?” are stronger.

End with the right-sized ask:

• “Can we watch you try this with real data next week?”
• “Would you introduce us to the admin who owns this workflow?”
• “Can we set up a pilot with the team that would use it?”
• “Would you put a card on file for the beta?”

The ask does not need to be aggressive. It needs to make the difference between enthusiasm and action visible.

For a full script, use Maren’s concept testing interview guide. For wording traps, use the guide to avoiding leading questions.

The loop, not the phase

Discovery and validation are not stages you graduate from forever.

Healthy teams move between them. A discovery pattern suggests a solution. A validation round exposes a new unknown. That unknown sends you back into discovery with sharper questions.

Product Talk’s continuous discovery advice pushes teams towards regular customer touchpoints for exactly this reason. The cadence matters because customer reality changes faster than your last research project. A segment shifts. A buyer changes. A workaround becomes normal. A validation result that looked clear in March can be stale by June.

For a technical founder, the practical loop is:

1. Discover the problem in real stories.
2. Shape a specific answer.
3. Validate the answer against behaviour.
4. Check the result in product data.
5. Return to discovery when the data disagrees.

The mistake is treating validation as the end of learning. A failed validation interview is often the best discovery prompt you will get.

Where Maren fits

Maren is useful when the hard part is not knowing that you should talk to users, but running enough disciplined conversations to keep the evidence honest.

For discovery, Maren can run structured, asynchronous conversations that keep participants anchored in recent events, ask neutral follow-ups, and return themes with the supporting stories attached. That helps when founder presence would turn the conversation into a pitch or when the people you need to hear from will not book a live call.

For validation, Maren can help test a written concept, onboarding flow, or interview script across a focused segment. You still choose the segment, define the artefact, and decide what evidence is strong enough. Maren does not replace judgement. She reduces the amount of product hope in the room.

The important thing is to choose the mode first.

If you need discovery, do not show the idea. If you need validation, do not accept compliments. Decide before the call: problem or solution, stories or commitments.

That one-line decision is the difference between 30 minutes of politeness and 30 minutes of evidence.