Customer Discovery Interview Questions That Get Receipts

A good customer discovery interview should change a decision. You might narrow who you’re building for, investigate a problem you hadn’t understood, or stop treating a polite “yes” as a reason to build.

The useful question afterward is: what do we know now, and what are we still assuming?

Asking about a specific event helps. So does keeping your interpretation separate from what the person actually told you. Neither turns one conversation into proof that you have a business.

Decide what you need to learn

Before the call, write down the uncertainty you’re trying to resolve. “Do customer-success managers lose track of the handoff after a contract is signed?” gives you something to investigate. “Will people love our platform?” invites a pitch.

You can do this before building, while testing a prototype, or after customers start using the product. The question changes with the decision in front of you.

In her YC talk on building products and talking to users, Adora Cheung recommends continuing conversations with users after launch. She also warns against building every requested feature without understanding the problem behind it.

Choose people who have relevant experience. A friend who does the job may teach you something; a stranger who doesn’t do it may not. Include people outside your immediate circle so your sample doesn’t depend on who wants to encourage you. The customer-discovery sourcing guide covers finding and screening interviewees.

Four customer discovery questions to start with

Use these as openings. Follow an answer worth understanding instead of rushing to finish the list.

1. “Tell me about the last time this happened.”

Start with a situation they recognize. If you’re investigating customer handoffs, ask about their last customer launch rather than assuming handoffs are broken.

What started the work? Who took part? Where did it go smoothly? Where did it get difficult?

Don’t require the event to have happened last week. An annual budget process and a daily support queue run on different clocks. Ask when it happened and how often it occurs.

2. “Walk me through how you handled it.”

Find out what they actually did, including tools, messages, manual steps and help from colleagues. Ask what worked before concentrating on what failed.

If they’re comfortable showing a blank template or walking through a nonconfidential example, that can clarify the account. Respect a refusal; you don’t need their customer data.

A spreadsheet isn’t automatically a product opportunity. It may be a perfectly adequate solution. Ask what makes it adequate or inadequate for this person.

3. “What happened as a result?”

Explore the consequences in their words. Did someone repeat work? Did a customer wait? Did anything important change?

If they give a time or money estimate, ask how they arrived at it. Distinguish a rough estimate from a number they track. “It feels like hours” and a record of time spent deserve different treatment in your notes.

Existing spending is useful context. Its absence leaves questions about priority, available alternatives and willingness to change. It doesn’t settle those questions for you.

4. “What have you tried to change, if anything?”

Ask what prompted the attempt, who was involved and what happened. If they haven’t tried anything, explore why without arguing that they should have.

The problem might be tolerable. They might lack authority. Another priority might keep winning. Those explanations suggest different next conversations.

For a B2B purchase, ask how a similar change was approved previously. The person doing the work may not own the budget. Learn about the actual process before asking them to predict whether somebody else will pay.

Keep the interview from becoming a sales pitch

Explain honestly why you’re talking to them, then give them room to describe their experience. Avoid questions that contain the answer you want: “How frustrating is your current system?” already assumes frustration.

You don’t need to make someone defend the problem by challenging them to prove it exists. Ask what happened and let the answer stand, including when it weakens your idea.

Jakob Nielsen’s discussion of user interviews recommends exploring specific incidents, warns that memory can be unreliable, and explains how leading questions can produce misleading answers. He also distinguishes interviews from watching people use a design. A detailed account is still an account; testing a prototype answers a different question.

If a product discussion would be useful, make the transition explicit. Ask whether they’d like to see what you’re working on. Record their experience of the problem separately from their reaction to your solution.

A hypothetical example: what did the interview prove?

Suppose you’re considering a tool for customer-success teams. A manager describes a recent launch:

“The signed contract stayed in sales. We started implementation without the integration requirements and had to book another call.”

They say they spent about two hours sorting it out. They use a spreadsheet for launches, but it doesn’t include the requirements from sales. They haven’t bought another tool.

There are several possible explanations. The team may need software. It may need an agreed handoff. Or this could be an unusual mistake in an otherwise workable process.

Write three short notes:

Reported event: On this launch, implementation began without the requirements. The manager estimates two hours of extra work. The account came from the interview; you haven’t checked a record.

Interpretation: Missing information at the sales handoff may cause avoidable rework. That’s your working explanation, not something the interview has established across the market.

Next test: Ask other people responsible for similar launches about their most recent handoffs. Find out whether missing information recurs, how they handle it and whether anyone owns fixing it.

If that pattern holds, you could test an agreed handoff checklist with a willing team before writing software. Decide what you’d watch: whether the required information arrives before implementation, for example. A cleaner handoff would support that intervention. It wouldn’t, by itself, establish demand for a paid product.

That’s my recommendation for using the notes: choose a test that addresses the uncertainty you actually have.

Compare interviews without flattening the differences

Keep each person’s role, context and recent example attached to the notes. Five similar complaints can hide five different buying situations.

Look for recurring consequences and attempts to solve them. Also keep the cases where the process works well. Those may show you who doesn’t need your product, or what an adequate alternative already looks like.

A referral, an offer to try something and a payment tell you different things. None deserves the same meaning in every situation. A paid pilot can reveal willingness to try a limited offer; it doesn’t establish renewal or long-term value.

Use what you’ve learned to revise the buyer and problem hypothesis. The startup validation framework can help you plan what to test next.

What to do after your next interview

Before opening your product backlog, write the reported event, your interpretation and the next test. Mark what you don’t know. Then ask whether the test could change your mind, or whether you’ve designed another way to hear yes.

You don’t need to finish every interview ready to build. You need to understand which decision the evidence supports.

For more guidance, the free five-day Validation Blueprint email course is available through the signup form on this page.