What Should a Customer-Discovery Interview Test Before You Build the Product?

A pre-build customer interview should test your assumptions about the customer's real situation before it tests enthusiasm for your idea.

The useful questions are about the job the person is trying to accomplish, the event that creates the need, what they do today, what frustrates them about that approach, how often the problem appears, what makes it urgent, who else affects the decision, and what they have already spent, changed, tolerated, or tried because the problem matters.

That evidence is more useful than asking, "Would you use this?" A person can like an idea in conversation and still have no reason to change behavior when the product exists.

Customer discovery is therefore a way to reduce uncertainty before you commit more time and money. It is not a substitute for later evidence from prototypes, real use, payment, retention, or other market behavior.

Start by writing down what you currently believe

An interview becomes sharper when the team knows which assumptions it is trying to challenge.

Before the conversation, write down the beliefs the product depends on. For example:

• a specific person experiences a specific problem;
• the problem appears in a recognizable situation;
• the person cares enough to seek a solution;
• the current workaround has meaningful costs or limitations;
• the buyer can influence or make the decision;
• the problem is important enough to compete with other priorities;
• a new approach could fit the person's constraints.

These are not conclusions. They are claims waiting for evidence.

David Fradin's Genius Talk product-strategy work begins with the job the customer is trying to accomplish. That starting point is useful because it keeps discovery anchored in the customer's situation rather than the team's feature list.

A team that begins with, "We are building an AI planning assistant," is already discussing a solution.

A stronger discovery statement is, "We believe small agency owners struggle to turn scattered project information into a reliable view of next week's workload."

Now the interview has something concrete to investigate.

Test the job before the product

The first question is whether the customer is actually trying to accomplish the job you think matters.

Ask for recent examples rather than general opinions.

Useful prompts include:

• Tell me about the last time this happened.
• What were you trying to get done?
• What triggered the situation?
• What happened next?
• What made it difficult?
• What would a good outcome have looked like?
• Who else was involved?

The value of a recent story is that it gives the researcher a sequence to examine. General statements such as "I hate admin" can mean many things. A specific account of preparing payroll on Friday afternoon can reveal the tools, dependencies, delays, workarounds, people, and consequences involved.

Fradin also emphasizes looking at how customers actually use products and solve problems, not only what they say they want. In the Genius Talk material, he describes discovering uses that differed from the company's assumptions and reconsidering positioning around proven behavior.

For pre-build discovery, the principle is simple: treat behavior as evidence that can confirm or challenge the story in your head.

Study the current workaround

If the problem matters, the customer is often doing something about it already.

The workaround may be awkward. It may involve a spreadsheet, an assistant, a chain of messages, an existing product, manual checking, a service provider, or simply tolerating the problem.

Ask:

• What do you do now?
• How did you choose that approach?
• What works well enough about it?
• What breaks?
• What have you already tried?
• Why did you stop using an alternative?
• What would make switching inconvenient?

This part of the interview prevents a common mistake: comparing the proposed product with an imaginary world in which the customer has no alternative.

The real competitor may be a product. It may also be an established habit that feels cheaper, safer, or familiar.

Understanding the workaround helps the team see what a new product would have to displace.

Test the trigger and urgency

A real problem can still be too infrequent or too low-priority to support the product you want to build.

Ask what causes the customer to act.

Does the issue become urgent at month-end? During a hiring push? After a customer complaint? When a project crosses a certain size? When a deadline is missed? When a manager asks for a report?

Then ask what happens if the customer does nothing.

The purpose is to understand priority without manufacturing pain.

A problem that annoys someone every six months may need a different product, price, or acquisition model from a problem that interrupts work every day. A task that looks important to the product team may sit far below other demands in the customer's actual week.

David M. Kaplan's contribution to the Genius Talk product synthesis broadens this question. Product appeal is only one part of viability. Distribution, margins, and the wider business model matter too. A customer interview cannot settle those economics, but it can reveal decision conditions that later analysis must respect.

For example, the user may care deeply about a problem but lack purchasing authority. The buyer may care about a different outcome. Adoption may require data access, integration, approval, training, or a workflow change that the team has not considered.

Those constraints belong in discovery because they shape what a realistic product decision looks like.

Ask about decisions, not compliments

Solution-focused questions are tempting because they produce clear-sounding answers.

Would you pay for this? Do you like this feature? Would this save you time? Would you switch from your current tool?

The problem is that the person is being asked to predict behavior in a hypothetical situation while also trying to be helpful.

A stronger interview looks backward before it looks forward.

Ask what the person has already purchased, tried, delayed, escalated, improvised, requested, or abandoned. Ask how similar decisions were made. Ask what evidence they needed, who had to agree, what budget or constraint mattered, and what made the issue important enough to act on.

Past behavior does not guarantee future demand. It gives the team more grounded evidence than politeness toward an idea.

This is also where discovery should be able to surprise you.

Danny Nathan describes a reported product project in the rodeo industry where the team initially expected separate applications for fans and athletes. Discovery exposed enough overlap that the planned product structure changed.

The important part of that example is not the industry. The research was allowed to alter the architecture.

If every interview ends by confirming the original concept, ask whether the questions are capable of producing an inconvenient answer.

Separate problem evidence from solution evidence

A strong customer-discovery interview can tell you that:

• the situation exists;
• the customer recognizes it;
• the current workaround has limitations;
• the issue has a trigger and consequence;
• the customer has already taken action;
• decision constraints are visible;
• some assumptions are wrong.

It still cannot prove that your proposed product will be adopted.

That distinction matters because teams can leave a set of enthusiastic interviews feeling as though the market has already voted.

It has not.

The customer-led product synthesis built from the Genius Talk interviews describes an evidence ladder. Early hypotheses and customer language sit below stronger forms of evidence such as interacting with a concept or prototype, using a real product, repeating the use, paying, or expanding.

Pre-build interviews belong near the beginning of that ladder.

Their job is to improve the quality of the next bet.

Patrick Boylan's MuseFlow discussion shows why later product evidence matters. His work pays close attention to how learners experience challenge, progression, and practice in the product itself. Those are questions that conversation alone cannot fully answer. At some point, the user has to encounter the experience.

The interview should help you decide what deserves that next test.

Decide what deserves a prototype

After several interviews, organize the evidence by assumption.

For each important belief, mark it as:

Supported so far. Multiple relevant customers describe a similar situation or behavior.

Contradicted. The interviews show the assumption does not match how customers currently work or decide.

Unclear. The evidence is mixed, too thin, or based mainly on opinions rather than examples.

Then ask which remaining unknown is both important and testable with a small prototype or market experiment.

The next step might be a clickable concept, a manual service version, a landing page, a workflow simulation, a limited pilot, or another low-cost test appropriate to the product. The interview itself does not tell you which method is universally best.

The principle is to spend the next unit of effort on the riskiest assumption that customer conversation cannot resolve.

A pre-build interview checklist

Before leaving discovery, you should be able to answer:

1. Who experiences the problem?
2. What job are they trying to complete?
3. What event triggers the need?
4. What do they do today?
5. What is unsatisfactory about the current approach?
6. How often does the situation occur?
7. What makes it important enough to act on?
8. Who influences the decision?
9. What constraints could block adoption?
10. What past behavior shows the problem matters?
11. Which assumption did the interviews weaken?
12. What remains uncertain enough to require a prototype or real-world test?

If the team can only answer what customers said they liked about the proposed idea, discovery has stayed too close to the pitch.

A useful interview leaves the team with a clearer picture of the customer's world and a more precise list of what still needs proof.