How to Run Customer Discovery Interviews: A 10-Question Signal Script (2026)

Most discovery interviews just collect flattery. Here's a 10-question script built to surface revealed behavior instead, plus how to recruit, read, and act on the signal.

October 10, 2026 · Requestproduct Team

Most founders don't run bad discovery interviews because they ask bad questions. They run bad interviews because they're hoping for a yes, and people are remarkably good at sensing that and giving it to them.

Why Most Discovery Interviews Lie to You

The flattery trap: why people tell you what you want to hear

When you sit across from someone, describe your idea, and ask "would this be useful to you," you've already told them what answer makes the conversation pleasant. Most people are conflict-avoidant in a 30-minute call with a stranger who clearly cares about the outcome. They'll nod, say "yeah, that's cool," maybe add "I'd definitely try that," and mean almost none of it in a way that predicts future behavior.

This isn't malice. It's social friction-avoidance. The fix isn't finding more polite people to be less polite with, it's changing what you ask so politeness has nothing to grab onto.

Stated preference vs. revealed behavior

Stated preference is what someone says they'd do. Revealed behavior is what they've actually done: money spent, hours burned on a workaround, tools downloaded and then abandoned, Slack messages sent at 11pm complaining about a broken process. Stated preference is cheap to produce and costs the interviewee nothing. Revealed behavior has a receipt.

A discovery interview is only useful to the extent it drags revealed behavior out of someone's memory. Every question in this script is designed to do that, not to collect opinions about a hypothetical future.

Interviews are a signal, not a verdict

One interview, however compelling, is one data point. Treat it as a single input into a larger demand-first stack, not a referendum on your idea. That's the whole premise behind the 7-step demand-first playbook: interviews come after you've already seen some demand signal (search volume, community complaints, a waitlist, a spreadsheet someone built to cope), not instead of it. An interview that confirms a signal you've already observed is worth far more than an interview that's the only evidence you have.

Before You Interview: Find the Right People to Talk To

Who counts as a real prospect (not friends and family)

A real prospect has the problem today, in their actual job or life, with their own money or time on the line. Friends, family, and "a guy I know who's kind of in that space" are not real prospects, no matter how encouraging they are. They're invested in you, not in the problem, and that distorts everything they tell you.

Screen for three things before you book the call: they currently experience the problem (not "might someday"), they currently do something about it (even a bad workaround counts), and they have some authority over spending or process in that area.

Recruiting from communities where your buyers already complain

The best interviewees are people you catch mid-complaint, not people you cold-recruit from a spreadsheet. Look at the same places people openly vent about the problem you're exploring. Our guide on where to ask for software recommendations online maps the subreddits, niche Slack and Discord communities, and Q&A forums where your target buyers already ask peers for help, which is exactly where you'll find people primed to talk honestly, because they're already venting to strangers.

If you're earlier than that and don't have a defined audience yet, the tactics in how to find early adopters for your startup cover how to identify and approach people who are likely to feel the pain hardest and first.

How many interviews are enough

There's no magic number, but a useful rule of thumb: keep interviewing within a single segment until you stop hearing anything new. In practice, that's often somewhere between 8 and 15 conversations for a narrow segment. If you're still getting surprised after 15, your segment is probably too broad, not too small a sample.

The Golden Rule: Ask About the Past, Not the Future

Why "Would you use this?" is worthless

"Would you use this?" asks someone to simulate a future decision they've never had to make, under conditions that don't exist yet (no price, no onboarding friction, no competing priorities that week). People answer this question optimistically because it's free to say yes and mildly awkward to say no to someone's face.

Anchoring questions to the last time they hit the problem

Replace every future-tense question with a past-tense one. "Would you use a tool for X" becomes "tell me about the last time X happened to you." This forces a specific memory instead of a hypothetical, and specific memories come with detail you can't fake: what they were doing, who else was involved, what it cost them, what they did next. This is the same behavior-over-intent logic behind the 7-signal framework: spending and action beat stated intent every time, so your questions need to dig for what people actually did, not what they'd theoretically do.

Spotting the difference between a problem and a mild annoyance

A real problem has a cost attached that the person can name without prompting: lost deals, wasted hours, a spreadsheet they built themselves out of frustration, money they already spend on a half-working fix. A mild annoyance gets described in vague terms ("it's a bit of a pain") with no specific incident attached. If someone can't recall a recent, concrete instance of the problem, you're likely looking at a mild annoyance, not a problem worth building for.

The 10-Question Discovery Interview Script

Use this as a starting skeleton, not a script to read verbatim. The goal of every question is the same: drag a specific memory, a specific cost, or a specific past action out of the person in front of you.

Opening: context and last-time-it-happened

Walk me through the last time you ran into [the problem]. What were you doing right before it happened?
What was going through your mind in that moment, frustration, resignation, something else?

Middle: current workarounds and what they cost

What do you currently do to deal with this, step by step?
How much time does that take you in a typical week or month?
What does that actually cost you, in dollars, hours, or things you don't get to do instead?

Probing: what they've already tried and paid for

What have you already tried to fix this, tools, hacks, spreadsheets, hires?
Have you ever paid for something to solve this, even partially? What was it, and why did you stop using it, if you did?
On a scale from "mild annoyance" to "I'd drop what I'm doing to fix this right now," where does this sit, and when's the last time it hit that upper end?

Closing: who else has this problem

Who else on your team, or in your network, deals with this same thing?
If you wanted to bring in a new tool for this today, who would need to sign off, and what does that process usually look like?

That last question matters more than it looks. It doesn't ask "would you buy this," it asks about a real procurement behavior they've lived through before, which tells you far more about actual buying friction than any hypothetical yes.

Reading the Signals: What Answers Actually Mean

Strong signals (they've paid, hacked, or asked for a fix)

Strong signals show up as past action: they paid for a tool (even a bad one), they built a workaround themselves, they asked their boss or a vendor for a fix, or they can describe a specific recent incident with a dollar or time cost attached. Any of these beats a glowing "that sounds amazing" with no history behind it.

Weak signals (interesting, nice-to-have, maybe later)

Weak signals sound enthusiastic but stay abstract: "that would be cool," "I could see using that," "interesting, keep me posted." No specific incident, no cost named, no prior attempt to fix it. Treat these as polite noise until proven otherwise.

Where interview answers map to real feature requests

The pain someone describes in an interview should also show up, unprompted, somewhere else: a forum thread, a product review complaining about a gap, a public feature request. Our breakdown of real feature requests for product ideas covers six sources of this kind of unfiltered demand. If an interviewee's story doesn't echo anywhere in those sources, it may be a real problem for that one person, but it's a weaker bet for a product.

Signal type	What you hear	What it actually means
Strong	"I built a spreadsheet to track this myself"	Proven willingness to invest effort
Strong	"We pay for [competitor/workaround] already"	Proven willingness to pay
Weak	"That would be neat to have"	No cost, no history, no commitment
Weak	"I'd probably use that"	Hypothetical, untestable claim

Turn Discovery Into a Repeatable Feedback System (CTA)

Logging interview signals alongside passive demand data

A brilliant insight buried in a Google Doc from six weeks ago is functionally the same as an insight you never captured. Every interview should feed a running log, tagged by segment, problem, and signal strength, sitting next to the passive demand data you're already collecting (search terms, community threads, support tickets).

Tools that keep interview insights from rotting in a doc

This is exactly the gap that purpose-built feedback systems close. Our ranking of customer feedback tools for startups walks through eight tools ranked by how well they surface real, aggregated demand rather than just storing notes. The common thread across all of them: interview signal is only useful once it's structured and compared against everything else you're hearing, not left to decay in a transcript.

From Interviews to Pre-Launch Validation

Converting interviewees into beta testers

Someone who gave you a detailed, specific answer in an interview has already shown more engagement than a cold lead. Ask directly if they'd want early access once you have something to show. Our guide to find beta testers for a SaaS covers eleven channels for building out that pool further once your initial interviewees are tapped.

Testing willingness-to-pay before you build

An interview can surface pain, but it can't prove someone will pay. The next step is a cheap pre-commitment test: a waitlist with a deposit, a letter of intent, a pre-sale page. If the same people who talked about their pain in the interview won't take a small, low-cost next step, that's a signal worth taking seriously.

Closing the loop with real usage

Eventually, talk has to become behavior: a demo booked, a trial started, a prototype actually opened more than once. Our tactics in how to get product feedback before launch are built around getting a prototype in front of the same people you interviewed, so you're watching what they do instead of relistening to what they said.

Common Discovery Interview Mistakes (and Fixes)

Pitching instead of listening

The moment you describe your idea, you've contaminated the interview. The person is now reacting to your pitch instead of recalling their own history. Fix: describe nothing. Ask about their last experience with the problem and stay quiet.

Leading questions and confirmation bias

"Wouldn't it be great if you could just click a button and have this handled?" is a leading question wearing a question mark. It invites agreement rather than information. Fix: ask open, past-tense questions and let silence do the work.

Talking to the wrong segment

If your interviewees don't actually have budget authority, don't feel the problem daily, or aren't representative of your eventual buyer, their answers won't generalize no matter how sharp your questions are. Fix: screen harder before you book the call, not after you've run twelve of them.

Over-indexing on a single enthusiastic interview

One person with a great story is a story, not a market. Fix: treat every interview as one input into the stack described in the 7-step demand-first playbook, cross-checked against other demand signals before you act on it.

Mistake	What it produces	Fix
Pitching the idea early	Polite agreement, no signal	Describe nothing, ask about their past
Leading questions	Confirmation of your own bias	Open, past-tense, neutral phrasing
Wrong segment	Answers that don't generalize	Screen for budget authority and current pain
One great interview	False confidence	Weigh against other demand signals before acting

Frequently Asked Questions

How many customer discovery interviews should I run before deciding? There's no fixed number, but a common pattern is 8 to 15 interviews within one segment before you stop hearing new information. If you're still surprised past 15, your segment definition is probably too wide.

What questions should I never ask in a discovery interview? Avoid anything future-tense or hypothetical, like "would you use this" or "would you pay for this." Also avoid describing your idea before you've heard their story, since it contaminates every answer that follows.

How do I find people to interview if I don't have customers yet? Look in the communities where your target buyers already discuss the problem, including the forums and groups covered in where to ask for software recommendations online, and use the recruiting tactics in find early adopters for your startup.

Should I record customer discovery interviews? Yes, with permission. You'll catch details on replay that you miss while actively listening and taking notes, and a recording lets you pull exact language for later use in marketing or product copy.

How do I tell a real problem from a nice-to-have in an interview? A real problem comes with a specific, recent incident and a named cost (time, money, or a workaround they built). A nice-to-have stays vague and has no concrete recent example attached to it.

What's the difference between customer discovery and customer validation? Discovery is about understanding whether a problem exists and how people currently deal with it. Validation is about testing whether people will actually commit resources, money, time, or switching effort, to your specific solution.

Conclusion

A discovery interview is only as good as the specific memory it drags out of someone. Ask about the past, listen for cost and prior action, and treat every conversation as one signal to weigh against everything else you already know, not a verdict to act on alone.