Discovery Interview Script Template

The fastest way to waste a discovery interview is asking someone whether they would use something that does not exist yet. People are generous with hypothetical enthusiasm and unreliable predictors of their own future behavior. The script below is built around what someone has actually done, not what they imagine they might do.

What does a working discovery interview script look like?

Start with the hypothesis, before writing a single interview question.

Hypothesis format: who does what, because why, and what evidence would change your mind. Example: "Small business owners abandon our onboarding flow because it asks for payment details before they have seen any real value, and evidence that would change this: if users who skip payment setup convert at a similar rate once they hit a paywall later, the payment-details step is not actually the blocker."

Six-question interview guide, built to test that hypothesis from different angles:

1. "Tell me about the last time you signed up for a new tool like this one. Walk me through what happened, step by step."
2. "What made you stop, if you did stop, at any point during that signup?"
3. "Tell me about a time you decided not to finish signing up for something. What tipped you toward walking away?"
4. "How do you currently handle [the problem this product addresses] without this tool?"
5. "Tell me about the last time that current approach failed you or cost you time."
6. "If you were explaining to a colleague why you did or didn't finish signing up for something like this, what would you say?"

Each question asks about a specific past event, not a general opinion or a future hypothetical. That is deliberate: a memory of something that actually happened is far more reliable evidence than a prediction about something that has not.

How do you turn AI-generated questions into a usable script?

Prompting an AI to draft an interview guide against your hypothesis is a legitimate way to get a fast first draft, and it is genuinely faster than starting from a blank page. The discipline is in what happens after the draft appears: read every question and cut anything that leads the witness ("don't you wish onboarding was faster?"), replace vague prompts ("what do you think about our signup flow?") with behavioral ones ("tell me about the last time you used our signup flow"), and check that each surviving question actually targets the hypothesis rather than sounding plausible in isolation.

A script an AI produced and a human then edited hard reads differently from one nobody reviewed: fewer leading questions, more specific probes, and a tighter connection to the actual thing you are trying to learn.

How do you synthesize what you hear into something actionable?

After each interview, resist the pull to summarize immediately into a tidy takeaway. Cluster raw notes or a transcript into two or three themes, and attach a direct quote or specific observation to each one.

Theme	Supporting quote or observation	Confidence
Payment friction is not the real blocker	"I actually didn't mind entering my card, I just didn't understand what I'd get after"	Medium
Unclear value before commitment	"I couldn't tell what the tool actually did until after I'd already signed up"	High
Time pressure during signup	"I was doing this on my phone in a meeting, honestly I just gave up"	Low

End with a stated decision: based on these themes, does the evidence support, weaken, or kill the original hypothesis, and what is the next concrete action. Skipping this last step is the most common way good interviews produce no actual change.

What mistakes turn an interview into a pitch?

The most damaging mistake is describing the product or feature before the participant has described their own experience, which anchors their answers to your framing instead of theirs. Once you have said "we're building a tool that does X," every answer that follows is at least partly a reaction to X, not an independent account of the participant's own problem.

A second common mistake is treating a friendly, agreeable participant as validation. Someone being polite in an interview is not the same as someone who has actually experienced the problem you are testing for; a behavioral question about a specific past event filters for the second kind of answer far better than a general question about interest does.

Who this is for, and who it is not for

This script fits a product manager, researcher, or founder running discovery before committing engineering time to a direction, especially the workflow taught in Builders Camp's AI Prompting for Customer Discovery bootcamp: turning assumptions into testable hypotheses, generating and editing interview guides, and synthesizing evidence into decisions, using AI to speed up the thinking without replacing the actual conversation. It is not a usability test script, which observes someone using an existing product rather than probing a problem that may not have a solution yet; those need a different structure entirely, closer to the broader interviewing practice covered in how to run customer interviews.

If the discovery evidence points toward a specific feature worth building, the next step is scoping it in a PRD, and if that feature eventually needs to be broken into buildable pieces, see how to write a good user story.

What to do with this script right now

Write your hypothesis first, in the who/what/why/evidence format above, before drafting a single question. Every question that follows should trace back to that hypothesis, and every answer you get should be judged against whether it supports, weakens, or kills it, not against whether it felt like a good conversation.

Builders Camp's AI Prompting for Customer Discovery bootcamp runs 1 week across 2 live sessions, taught by Andre Albuquerque, and walks through this exact loop, hypothesis, interview guide, synthesis, decision, as a repeatable weekly workflow rather than a one-time exercise.