SaaS Customer Discovery Interview Script (Steve Blank Lens)

Most SaaS founders pitch too early. The customer discovery interview — when done correctly — is the antidote: a structured conversation designed to surface problems, not validate assumptions. This guide provides a complete, annotated interview script grounded in Steve Blank's Customer Development methodology, with analysis frameworks to turn raw transcripts into product decisions.

Customer discovery is not market research. It is not a focus group. And it is decidedly not a sales call wearing a trench coat. It is a structured ethnographic conversation with the goal of understanding whether a specific problem exists, how acutely it is felt, and what people currently do about it.

Steve Blank's foundational work — documented in The Four Steps to the Epiphany — establishes customer discovery as the first and most critical stage of the Customer Development model. The core insight: startups do not fail because they cannot build product. They fail because they build product nobody needs. Discovery interviews are the error-correction mechanism that prevents this failure mode before it becomes expensive.

The script below is built for founder-led discovery in B2B SaaS, adapted from Blank's original framework with structural additions from Jobs-to-be-Done theory. It is annotated throughout so you understand not just what to ask but why each question exists and what answers you are listening for.

The Pre-Interview Setup

Before the first question, three things must be true.

The interviewee is the right person. In B2B SaaS, this typically means someone who experiences the problem directly, not someone who manages a team that experiences it. If you are building a tool for revenue operations analysts, interview the analyst — not the VP of RevOps who approves the budget. Budget holders come later, during validation, when business model questions become relevant.

You have done zero pitching to get here. The invite should be framed as "I'm doing research on how [target role] handles [problem domain] and would love 45 minutes of your time." No product mention. No solution pitch. This is not dishonest — it is accurate. You are doing research.

You have a recording setup and a note-taker lined up. You cannot conduct a great interview and take great notes simultaneously. Use a second person, or record with the interviewee's explicit permission. The transcript is the artifact that matters — your in-meeting impressions are unreliable.

Interview Length and Timing

Allocate 45–60 minutes. The first 10 minutes are warm-up and context. The middle 30 minutes are the core problem exploration. The final 10–15 minutes are synthesis and wrap-up. Do not let the conversation run over — it signals disrespect for the interviewee's time and reduces the likelihood they will refer others to you.

Phase 1: Context and Background (10 Minutes)

The purpose of the opening phase is to establish rapport and gather the contextual data that will make sense of everything that follows. You need to understand the interviewee's role, their company, and their day before you can interpret their problems.

Opening script:

"Thanks so much for making time. As I mentioned, I'm in the early stages of researching how [target role] manages [broad problem domain], and I want to learn from your experience specifically. There are no right or wrong answers — I'm genuinely trying to understand how things work in practice, not pitch anything. Mind if I record so I can focus on listening rather than note-taking?"

Context questions:

1. "Walk me through your role — what are you responsible for day to day?"
2. "How long have you been in this role? How large is your team?"
3. "How does [problem domain] factor into your work on a typical week?"
4. "Who else in your organization is involved in decisions related to [problem domain]?"

What you are listening for: The interviewee's vocabulary for the problem domain. The stakeholders involved. The frequency and visibility of the problem. Pay attention to how they frame their responsibilities — it tells you which problems feel like their job to solve vs. someone else's problem.

Annotation: Do not correct their terminology or introduce your own. If they call the thing you call "pipeline velocity" something different, adopt their language for the rest of the interview. Your goal is to understand their world, not to educate them about yours.

Phase 2: Problem Exploration (20 Minutes)

This is the heart of the interview. The goal is to understand the problem landscape — what problems exist, which ones feel urgent, and what emotional weight they carry.

Transition:

"I'd like to dig into some of the specific challenges you face around [problem domain]. Tell me about the last time [problem trigger event] happened for you."

Note: The "last time" framing is deliberate. It anchors the conversation in a specific, real episode rather than a generalized abstraction. Specific episodes produce specific, useful data. Abstract discussions produce "it depends" and "sometimes we..." — which are not actionable.

Problem exploration questions:

1. "Walk me through what happened from the beginning. What triggered it?"
2. "What did you do first? What did you try?"
3. "Where did you get stuck?"
4. "What does this cost you — in time, in money, in stress?"
5. "How often does this happen?"
6. "What happens if you don't solve it?"
7. "Who else is affected when this happens?"

The single most diagnostic question:

"What do you do today when this problem occurs?"

This question is the most important one in the script. The answer tells you three things simultaneously: (1) whether the problem is real enough that people have developed workarounds, (2) what the "current solution" competitive set actually is, and (3) how much friction the incumbent solution creates. A problem with no current solution is either very new or not painful enough to act on. A problem with an expensive, clunky workaround is a funded pain point with a clear competitive gap.

Probing for depth:

When an interviewee describes a pain, use these probes to go deeper:

• "Tell me more about that."
• "What made that particularly frustrating?"
• "How did that make you feel?"
• "What did you do next?"
• "Was this a one-time thing or does it happen regularly?"

Resist the urge to problem-solve. When an interviewee describes a pain, your brain will immediately pattern-match to your solution. Do not let this show. Do not say "oh interesting, we've been thinking about a tool that..." Do not nod in a way that validates your hypothesis. Listen neutrally and ask the next probe.

Annotation: First Round Review has documented that the most common failure mode in founder-led discovery is "premature convergence" — founders hear the first few interviews confirm their hypothesis and stop listening openly. The solution is structure: commit to the full script in every interview, regardless of what you hear in the first five sessions.

Phase 3: Current Solutions and Alternatives (10 Minutes)

Before closing the problem exploration, you need a complete picture of what the interviewee is currently doing to manage the problem. This is your competitive intelligence and your pricing anchor in a single block of questions.

Current solution questions:

1. "What tools, processes, or people do you currently use to handle this?"
2. "How long have you been using that approach?"
3. "What works well about it? What doesn't?"
4. "Have you tried other approaches in the past? Why did you switch — or not switch?"
5. "If you could wave a magic wand and change one thing about how you currently handle this, what would it be?"

Annotation on the magic wand question: This is a classic Jobs-to-be-Done probe. The constraints people describe in response reveal the real friction — often something entirely different from the surface-level problem they described earlier. Pay close attention to answers that reference time ("I wish it didn't take so long"), people ("I wish I didn't have to involve [other team] every time"), or confidence ("I wish I could trust that the output was accurate").

What you are listening for: The depth of dissatisfaction with the current solution. Whether they have actively searched for alternatives. Whether the problem is in their active budget — have they spent money on it, or is it something they simply tolerate?

According to OpenView Partners' research on product-led and sales-led growth, buyers who have already tried and abandoned a category solution are significantly higher-intent than buyers who have never engaged with the category. Your discovery interviews should surface which camp your targets are in.

The patterns you surface here will recur directly in win-loss analysis — where the same "current solution" dimension determines why deals close or fall apart. The better your discovery data, the sharper your win-loss taxonomy will be.

Phase 4: Ideal Outcome and Wrap-Up (10 Minutes)

The final phase shifts from problem to aspiration. You are not asking what your product should do — you are asking what success looks like in the interviewee's own terms.

Outcome questions:

1. "If this problem were completely solved, what would change for you? For your team?"
2. "How would you measure whether the solution was working?"
3. "What would you need to see before you'd be confident enough to change how you currently do this?"
4. "Who in your organization would need to be involved in a decision to change your current approach?"

Annotation on the final question: This question does two things. First, it maps the buying committee — essential for B2B SaaS where average deal cycles involve multiple stakeholders across functions. Second, it tells you whether the interviewee is a champion who can drive internal change, or an end user with no purchasing authority. Both are valuable; they just need to be engaged differently in subsequent conversations.

Wrap-up:

"This has been really helpful. Last question: is there anyone else you'd recommend I talk to — either inside or outside your organization — who deals with these issues?"

This referral ask is not optional. Your best interviews come from referrals from people you have already interviewed. They pre-qualify the interviewee, establish trust via the referral, and accelerate your research timeline significantly. Always ask.

Close:

"I really appreciate you taking the time. Once I'm further along in this research, I'd love to share back what I'm learning if that's useful to you."

This close sets up a legitimate reason to follow up and keeps the relationship warm for your first customer conversations once you have reached the validation stage. The founders who convert discovery contacts into early customers almost always do so through this kind of sustained, low-pressure relationship — not through a sudden cold pitch months later.

The Analysis Framework: From Transcripts to Insights

Running 20 discovery interviews and filing away the transcripts is a waste. The analysis is where the value is extracted.

Step 1: Transcribe and Tag

Transcribe every interview verbatim. Then read through each transcript and tag every meaningful unit of data with one of the following labels:

• Problem: A pain or frustration the interviewee described
• Context: The situation in which the problem occurs
• Current solution: What they do today to manage it
• Language: The exact words they use to describe the problem
• Emotion: The affect attached to the problem (frustration, resignation, embarrassment)
• Stakeholder: Other people mentioned in relation to the problem
• Quote: A verbatim statement that captures something essential

Step 2: Affinity Mapping

Extract all tags into a shared space — a physical whiteboard, Miro, or FigJam works well. Group tags into clusters by theme. Do this without imposing hierarchy first: just group similar tags together. Once all tags are placed, name each cluster with a brief descriptive phrase.

The clusters that contain the most tags across the most interviews are your strongest signals. The clusters that carry the most intense emotional language are your highest-urgency problems — even if they appear less frequently in raw count.

Step 3: Frequency x Intensity Matrix

For each problem cluster, score it on two dimensions:

• Frequency: How many interviewees mentioned it? (mapped to your total interview count)
• Intensity: How urgently did they describe it? (1 = mild inconvenience, 5 = acute pain affecting business outcomes)

Plot each cluster on a 2x2. Problems in the high-frequency, high-intensity quadrant are your primary targets. Problems in the high-intensity, low-frequency quadrant are potential niche opportunities or early adopter segments — worth noting but not building for yet.

Step 4: Connect to Downstream Research

Discovery interviews are the top of a research funnel, not a standalone exercise. The problems you surface here should be validated quantitatively through willingness-to-pay survey design — where you translate qualitative problem prioritization into actual price sensitivity data.

The "current solution" data from discovery interviews also becomes foundational input for understanding your churn root causes. Customers who chose you over an incumbent will eventually tell you whether you genuinely replaced the old solution or just added complexity — and the discovery interview corpus gives you the baseline to interpret those later signals correctly.

SaaS Capital's annual research on net revenue retention has consistently found that products perceived as replacing a prior solution retain at significantly higher rates than products perceived as adding to an existing stack. Discovery interviews are where you determine which camp your product is being placed in — before it becomes a retention problem.

Common Failure Modes and How to Avoid Them

The Pitch Creep Problem

The most corrosive failure mode: the founder starts presenting their solution midway through the interview, ostensibly "to get feedback." Once you pitch, the interview converts from discovery to validation — and you have compromised the quality of any remaining problem data, because the interviewee is now reacting to your framing rather than reporting their own experience.

Fix: Keep your product, mockups, and solution language completely out of discovery interviews. If an interviewee asks "so what are you building?", answer honestly but briefly ("I'm exploring this space and not ready to share specifics yet — I'm more interested in learning from you right now") and pivot immediately back to their experience.

The Confirmation Bias Loop

Founders running their own discovery are statistically likely to overweight confirming evidence and underweight disconfirming evidence. This is not malice — it is human cognition operating exactly as designed.

Fix: Before each interview, write down the specific hypothesis you expect this conversation to challenge. After the interview, spend 5 minutes specifically looking for evidence that your hypothesis is wrong. Force the disconfirmation exercise.

The Sample Bias Problem

Interviewing only your existing network produces a convenience sample, not a representative one. Your network skews toward people who share your professional context, vocabulary, and mental models — making it harder to surface problems you have not already imagined.

Fix: Actively recruit outside your network using community channels, cold outreach, and paid recruitment panels for at least 40% of your interview sample. The conversations that feel most foreign and uncomfortable are usually the most informative.

Asking About Future Behavior

"Would you pay for this?" "Would you use a tool that does X?" These questions feel useful but are scientifically unreliable. Behavioral economics research consistently shows that stated preference diverges significantly from revealed preference. People predict their own future behavior poorly — they are excellent at describing what they actually do today.

Fix: Keep all questions anchored in past or present behavior. "What did you do last time this happened?" not "What would you do if...?" "What are you currently spending on this problem?" not "What would you be willing to spend?"

Activation Rate as a Discovery Signal

One underutilized output of customer discovery interviews is early signal on activation rate — the percentage of new users who reach your product's core value moment. During discovery, you can surface the conditions that make activation likely or unlikely before you have built anything.

Ask: "If you signed up for a tool designed to solve this problem, what would you need to see in the first week to feel confident it was working?"

The answers to this question are your activation milestone candidates — the exact behaviors that correlate with a customer experiencing genuine value. Founders who run rigorous discovery before building frequently find that their initial activation hypothesis (usually "user completes setup") is wrong, and the real activation signal is something more specific and harder to reach.

This is valuable to know before you have instrumented your product around the wrong milestone. OpenView Partners' product benchmarking data shows that B2B SaaS products with clearly defined, research-validated activation milestones outperform products where activation was defined by engineering convenience rather than customer behavior research.

Frequently Asked Questions

How many customer discovery interviews do you need before drawing conclusions?

Steve Blank's original guidance is a minimum of 10–15 interviews per customer segment before forming hypotheses. First Round Review has documented that most founders under-index here — they stop after 3–5 interviews and mistake early signal for validated insight. For a B2B SaaS product with 2–3 target segments, plan for 30–45 total interviews in the initial discovery phase.

What is the difference between customer discovery and customer validation?

Customer discovery (the first stage in Blank's Customer Development model) is about understanding whether a problem exists and how painful it is. Customer validation is the subsequent stage — testing whether your specific solution and business model actually resolve that problem for paying customers. Most early-stage founders conflate the two and present their solution too early in the discovery phase, which biases the data.

Should you show your product during a customer discovery interview?

No — not during early-stage discovery. Showing the product primes the interviewee to evaluate features rather than articulate problems. The exception is customer validation interviews, where you deliberately present a prototype or demo and observe reaction. In discovery, the goal is to understand the problem space, not to pitch a solution.

How do you recruit participants for customer discovery interviews?

The most effective channels for B2B SaaS are: (1) your personal LinkedIn network filtered by target role and company size, (2) mutual connections via warm intro, (3) communities and Slack groups where your ICP is active, and (4) direct cold outreach with a clear value exchange. Offer a 45-minute conversation, not a "user interview" — the framing matters for response rates.

What questions should you avoid in a customer discovery interview?

Avoid any question that can be answered with "yes" or "no," any question that contains your solution hypothesis ("Would you use a tool that does X?"), and any question that asks people to predict future behavior ("Would you pay for this?"). People are notoriously poor at predicting what they will do — they are excellent at describing what they actually do today.

How do you analyze customer discovery interviews at scale?

The most reliable method is affinity mapping: transcribe each interview, pull out verbatim quotes, and cluster quotes by theme on a shared board. Themes that appear across 5 or more interviews with emotional language attached to them are your strongest signals. Count frequency and intensity separately — a problem mentioned casually by 12 people may matter less than a problem that causes visible frustration in 6.

What is the Jobs-to-be-Done (JTBD) connection to customer discovery?

Jobs-to-be-Done (developed by Clayton Christensen and popularized in SaaS by Bob Moesta) reframes the discovery question from "what features do customers want?" to "what progress are customers trying to make in their lives or work?" It pairs naturally with Blank's problem-first methodology. A JTBD-informed discovery script probes for the job, the constraints preventing progress, and the social and emotional dimensions — not just the functional task.

How does customer discovery connect to pricing strategy?

Discovery interviews surface the jobs customers are hiring your product to do and the alternatives they're currently using. Both directly inform pricing. If a customer is currently spending $2,000/month on an agency to do manually what your tool automates, your pricing ceiling is set by that alternative. Coupling discovery with a willingness-to-pay survey design gives you both qualitative context and quantitative range.

Conclusion

Customer discovery interviews are not a box to check before you start building. Done with discipline — using a structured script, neutral listening, and rigorous analysis — they are the single highest-return research investment a founder can make before writing the first line of production code.

The Steve Blank framework is simple in structure but demanding in execution. The temptation to pitch is constant. The temptation to stop at 5 interviews is real. The temptation to interpret confirming evidence generously and disconfirming evidence critically is human. The four-phase script above is designed to constrain these failure modes through structure.

Run 15 interviews with this script. Transcribe them. Map the clusters. Score the frequency and intensity. The result will not be certainty — discovery never produces certainty. But it will be a dramatically better-informed starting point than the alternative: building for months and discovering the problem landscape only when churn patterns tell you something went wrong.

The founders who skip discovery do not save time. They spend it later, running win-loss analysis on deals they should have never pursued, or retrofitting activation improvements onto a product built for a problem that turned out to be less acute than assumed. Discovery is not upstream of strategy — it is strategy. And the script above is where it begins.