Conducting Customer Discovery Interviews: Questions, Structure, and Techniques
This skill teaches you how to plan, run, and synthesize structured customer discovery interviews that surface genuine pain points, using customer discovery interview questions designed to avoid leading the respondent and to produce evidence you can act on.
Start by writing down your riskiest assumptions about the customer problem. Recruit 5-15 people who match your target segment. Ask open-ended questions about their past behavior, not hypothetical futures. Focus every question on the last time they experienced the problem, what they tried, and what happened. Record the conversation and extract verbatim quotes. Pattern-match across interviews to validate or invalidate your hypotheses.
Outcome: You produce a validated or invalidated set of problem hypotheses backed by verbatim customer evidence, giving you the confidence to commit resources to a solution or pivot your direction entirely.
Prerequisites
- A written problem hypothesis or assumption list (see Formulating Testable Business Hypotheses)
- Access to 5-15 people in your target customer segment
- Basic understanding of the Lean Startup build-measure-learn loop
- A note-taking system (document, spreadsheet, or dedicated tool)
Overview
Customer discovery interviews are the primary evidence-gathering tool in the Lean Startup methodology. Their purpose is deceptively simple: talk to people who might have the problem you think you can solve, and find out whether that problem is real, frequent, and painful enough to warrant a solution. The artifact you produce is not a transcript. It is a synthesis document that maps your original hypotheses to specific, verbatim customer quotes and behavioral evidence, scored by how strongly each hypothesis was supported or contradicted.
The skill sits at the very beginning of the build-measure-learn cycle. Before you design a minimum viable product, before you track innovation accounting metrics, and before you run validated learning experiments, you need to confirm that the problem you plan to solve actually exists in the wild. Customer discovery interviews are how you do that confirmation. They feed directly into hypothesis formulation by providing the raw evidence that either sharpens your assumptions or forces you to rewrite them.
What makes this skill genuinely difficult is not the logistics of scheduling calls. It is the discipline of listening without selling, asking without leading, and accepting evidence that contradicts your vision. Most founders and product managers instinctively pitch during interviews because they are excited about their idea. The interview then becomes a sales call, the respondent nods politely, and the team walks away with false confidence. A well-run customer discovery interview feels almost uncomfortable for the interviewer, because you spend 80% of the time in silence or following up on threads you did not expect. Success looks like finishing a batch of 5-10 interviews with a clear, evidence-backed answer to the question: "Is this problem worth solving for this segment?" That answer might be yes, no, or "yes, but the real problem is something adjacent that I did not anticipate." All three outcomes are valuable.
The concrete deliverable is a hypothesis evidence matrix: a table where each row is one of your original assumptions, each column is an interview, and each cell contains the verbatim quote or behavioral data point that supports or contradicts that assumption. When you can look at that matrix and see a clear pattern across 5 or more interviews, you have the foundation for every decision that follows.
How It Works
Customer discovery interviews work because they exploit a fundamental asymmetry: people are unreliable predictors of their own future behavior, but they are excellent reporters of their own past behavior. When you ask someone "Would you pay $20/month for a tool that does X?" they will almost always say yes to be polite or because they genuinely believe their future self would act differently. When you ask "The last time you had this problem, what did you actually do?" they give you ground truth. The entire structure of customer discovery interview questions is built on this asymmetry.
The technique rests on three principles. First, you never ask about the future. You ask about the past and present. "Tell me about the last time this happened" is the single most important sentence in your toolkit. Second, you never describe your solution until the very end of the interview, if at all. The moment you describe what you are building, the respondent stops telling you about their problem and starts reacting to your solution. Third, you follow emotional energy. When a respondent's voice changes, when they lean forward, when they use strong language ("I hate," "it drives me crazy," "I waste hours on"), that is the signal to probe deeper. Those moments contain the real pain points.
The mental model is essentially forensic journalism applied to product development. You are not conducting a survey. You are reconstructing the scene of a crime, where the "crime" is the problem you believe exists. You want to know: What happened? When did it happen? Who was involved? What did the person try? How much time or money did they spend? What was the outcome? Each answer either corroborates your hypothesis or challenges it.
The reason the Lean Startup framework insists on this step is that building a product without customer evidence is the single largest source of startup waste. Every hour spent in interviews saves dozens of hours of engineering time on features nobody needs. The formula is simple: the cost of one wrong pivot decision is measured in months, while the cost of ten customer interviews is measured in days.
A common misunderstanding is that discovery interviews are qualitative and therefore unscientific. In practice, the rigor comes from three sources: consistent question structure across interviews, verbatim recording so you analyze what was said rather than what you remember, and a predetermined threshold for when you consider a hypothesis validated or invalidated (typically, 4 out of 5 respondents expressing the same unprompted pain point constitutes strong signal). You are not seeking statistical significance. You are seeking pattern convergence across a small, carefully recruited sample.
Step-by-Step
Step 1: Write Down Your Riskiest Assumptions
Before you talk to anyone, open a document and list every assumption your product idea depends on. Focus on problem assumptions, not solution assumptions. For example, "Marketing managers at mid-size SaaS companies spend more than 5 hours per week manually building reports" is a problem assumption. "Marketing managers would prefer a dashboard" is a solution assumption.
You want 3-7 problem assumptions, ranked by risk. Risk here means: if this assumption is wrong, the entire idea falls apart. The output of this step is a numbered list of assumptions you will test in interviews. Each assumption should be specific enough that a single interview response could support or contradict it.
Vague assumptions like "people want better analytics" are untestable because every response could be interpreted as supporting them.
Tip: If you have already completed the sibling skill on formulating testable hypotheses, pull your hypothesis list directly from that artifact. Do not recreate it from scratch. Consistency across the Lean Startup workflow matters more than perfect wording at this stage.
Step 2: Define Your Target Segment and Recruit Respondents
Write a one-sentence description of the exact person you need to interview. Include role, company size, industry, and the specific behavior that qualifies them. " This specificity matters because you need respondents who have actually experienced the problem, not people who might someday experience it. Recruit 5-15 respondents.
Five is the minimum for pattern recognition. Beyond 15, you typically hit diminishing returns for a single segment. Source respondents from LinkedIn outreach, existing customer lists, community forums, or warm introductions. " Offer nothing in return except the value of being heard.
Payment or incentives attract people motivated by the reward rather than the problem.
Tip: Track who you recruit in a simple spreadsheet with columns for name, qualifying criteria, interview date, and status. This prevents you from accidentally skewing your sample toward one subgroup. If all five of your respondents are from the same company size, your pattern is not a market signal, it is a company culture signal.
Step 3: Build Your Customer Discovery Interview Questions Script
Create a semi-structured script with 8-12 open-ended questions organized into three sections: context, problem exploration, and existing behavior. Context questions establish who the person is and what their day looks like ("Walk me through a typical week in your role"). Problem exploration questions probe the specific pain point ("Tell me about the last time you needed to create a report for leadership. ").
Existing behavior questions reveal their current workaround ("What tools or processes do you use today to handle this? "). Write the questions in the order you will ask them, but leave room to deviate. The script is a safety net, not a straitjacket.
Every question should be open-ended, meaning it cannot be answered with yes or no. " The former leads the witness. The latter invites them to tell their story.
Tip: Print or display your assumption list next to your script during the interview. As the respondent talks, you can glance at the assumptions and notice which ones are being addressed. This lets you guide the conversation naturally toward uncovered assumptions without forcing awkward transitions.
Step 4: Set Up Recording and Note-Taking
Before your first interview, decide how you will capture the conversation. The gold standard is audio or video recording (with explicit permission) plus a dedicated note-taker. If you are interviewing solo, record the call and take sparse notes during, then review the recording afterward. Verbatim quotes are the currency of customer discovery.
Your memory of what someone said is unreliable within 24 hours, and your interpretation will unconsciously bend toward confirming your hypothesis. Set up your recording tool and test it before the first interview. Create a note-taking template with sections that mirror your assumption list, so you can drop quotes directly into the relevant assumption bucket during or immediately after the interview. Use the respondent's exact words, not your paraphrase.
Tip: Always ask for recording permission at the start of the call, not in the calendar invite. Saying "I would like to record this so I can focus on listening rather than scribbling notes, is that okay?" gets a yes almost every time because it frames recording as a respect signal, not a surveillance one.
Step 5: Run the Interview
Start with 2-3 minutes of warm-up: thank them for their time, explain you are researching a problem space (not selling anything), and set expectations for the length (20-30 minutes). Then begin with your context questions. The single most important discipline during the interview is to resist the urge to describe your idea. " reply with "I would love to share that at the end.
" When the respondent mentions something that connects to one of your assumptions, probe deeper with follow-up questions. " These follow-ups are where the real insights live. The scripted questions get you into the neighborhood. The follow-ups get you into the house.
Aim for a ratio of 80% respondent talking, 20% you talking. If you are talking more than 20% of the time, you are lecturing, not discovering.
Tip: Silence is your most powerful tool. When a respondent finishes a sentence, wait 3-5 seconds before responding. People fill silence with their real thoughts. The first answer to a question is usually the polished, socially acceptable version. The second answer, prompted by a pause, is often the honest one.
Step 6: Close the Interview and Capture Immediate Impressions
In the last 3-5 minutes, you can optionally share a brief description of what you are exploring and ask for their reaction. Frame it as "Based on what you have told me, we are considering building something that helps with [problem]. " This is not a pitch. It is a gut-check on whether your problem framing resonates.
" The first question surfaces blind spots. The second question snowballs your recruitment pipeline. Within 15 minutes of ending the interview, write down your three strongest impressions: what surprised you, what confirmed an assumption, and what contradicted an assumption. These first impressions fade quickly and are valuable anchors when you synthesize later.
Tip: The referral question at the end is the highest-leverage question in the entire interview. A warm introduction from a respondent converts at 3-5x the rate of cold outreach and tends to produce higher-quality respondents because they self-select for relevance.
Step 7: Extract Verbatim Evidence Into Your Hypothesis Matrix
Within 24 hours of each interview, review your recording or notes and extract verbatim quotes that relate to each assumption on your list. Place each quote into a matrix where rows are assumptions and columns are interviews. Use the respondent's exact words, enclosed in quotation marks, with a brief context note in parentheses. ' If a respondent did not address a particular assumption at all, leave that cell blank.
If they contradicted the assumption, mark the quote with a minus sign or red highlight. Do this extraction for every interview before conducting the next one. Processing each interview before the next one forces you to notice emerging patterns early and adjust your follow-up questions accordingly.
Tip: Keep a separate "surprises" column in your matrix for insights that do not map to any of your original assumptions. These unexpected findings are often more valuable than your planned hypotheses because they represent problems you did not know existed.
Step 8: Synthesize Patterns Across Interviews
After completing 5 or more interviews, review the matrix column by column for each assumption. Count how many respondents supported, contradicted, or did not address each assumption. Apply your validation threshold: if 4 out of 5 respondents independently described the same pain point without prompting, that is strong signal. If only 1 out of 5 mentioned it, the assumption is weak or segment-specific.
Write a one-paragraph synthesis for each assumption that states the verdict (validated, invalidated, or inconclusive), the evidence ratio, and the strongest supporting or contradicting quotes. Look for patterns you did not anticipate: clusters of respondents describing the same adjacent problem, or a segment that experiences the problem very differently from what you expected. The output of this step is a synthesis document that your team can review. It should be clear enough that someone who was not in the interviews can understand the evidence and the conclusion.
Tip: If your results are inconclusive after 5 interviews (a 3-2 split, for example), do not declare the assumption validated or invalidated. Instead, conduct 3-5 more interviews with tighter segment criteria. Inconclusive results usually mean your segment definition is too broad, not that the question is unanswerable.
Step 9: Decide and Communicate Next Steps
Based on your synthesis, make an explicit decision for each assumption: pursue, pivot, or investigate further. A validated problem assumption feeds directly into solution design and MVP planning. An invalidated assumption means you need to reformulate your hypothesis or target a different segment. Write a brief decision memo that connects each assumption to its evidence and the resulting action.
Share this memo with your team, investors, or stakeholders. The decision memo is the bridge between customer discovery and the next step in your Lean Startup cycle, whether that is building an MVP, running an experiment, or pivoting your approach. Without this explicit step, interview insights decay into vague feelings of "I think customers want this" within weeks.
Tip: Present your evidence and decisions in a 15-minute team meeting rather than a long document. Use 2-3 direct customer quotes per assumption. Hearing the customer's voice in their own words is far more persuasive than any amount of summary analysis.
Examples
Example: Early-Stage B2B SaaS Founder Testing a Reporting Tool Idea
A solo founder believes that marketing directors at SaaS companies with 50-200 employees waste hours each week building performance reports manually. She has no product yet and wants to validate whether this pain point is real, frequent, and severe enough to build a business around. She has a small network in the SaaS marketing community and a budget of zero dollars.
She writes three problem assumptions: (1) marketing directors spend 5+ hours per week on manual reporting, (2) the data lives in 4+ disconnected tools, and (3) the reports are primarily for leadership, not for the marketing team itself. " Her script includes questions like "Walk me through the last time you prepared a report for your VP or CEO. " After five interviews, her hypothesis matrix shows that 4 out of 5 respondents confirmed the time waste (ranging from 3 to 8 hours per week), all 5 confirmed pulling from 3+ tools, but only 2 said the reports were primarily for leadership. The others described internal planning use cases.
Her synthesis document validates assumptions 1 and 2, invalidates assumption 3, and surfaces a surprise finding: the biggest emotional frustration was not the time spent, but the anxiety that the numbers might be wrong. This reframes her value proposition from "save time" to "report with confidence," which she carries into her MVP planning.
Example: Product Manager at a Growth-Stage Company Exploring an Adjacent Problem
A PM at a 300-person project management software company is tasked with evaluating whether to build a time-tracking feature. The company already has 15,000 customers, so she has easy access to users, but she needs to avoid biasing respondents who might simply say "yes, more features are better." She has a two-week timeline and a research ops coordinator who can help with scheduling.
She defines her assumptions: (1) teams with 10-50 members actively track time today using a separate tool, (2) the pain is in reconciling time data with project data across two systems, and (3) managers make staffing decisions based on time data at least monthly. She recruits 12 respondents from existing customers, filtering for teams of 10-50 members who have at least one integration with a time-tracking tool (her product analytics team can identify these accounts). Her script carefully avoids mentioning time tracking or any feature concept. Instead, she asks "Tell me about the last time you needed to understand how your team was spending their time across projects.
" After 10 interviews, her matrix shows strong validation for assumption 1 (9 out of 10 use a separate time tool), moderate validation for assumption 2 (6 out of 10 described reconciliation pain), and weak validation for assumption 3 (only 3 out of 10 use time data for staffing decisions, and those three are all in professional services). Her synthesis reveals that the reconciliation pain is real but concentrated in teams that bill clients, not all teams. She recommends scoping the feature for professional services use cases first, which changes the prioritization conversation with her leadership team.
Example: Consumer App Startup Testing a Fitness Problem Hypothesis
A two-person team believes that recreational runners who run 3-5 times per week struggle to follow a structured training plan because existing apps are too complex. They want to validate this before investing their limited savings into development. Their target segment is non-competitive runners aged 25-40 who use a running watch or app.
They write four assumptions: (1) recreational runners attempt to follow a training plan at least once per year, (2) they abandon the plan within 4 weeks, (3) the primary reason for abandonment is complexity or inflexibility, and (4) they would value a simpler alternative over a more feature-rich one. They recruit 8 respondents by posting in two running subreddits and a local running club Facebook group, screening for people who run 3-5 times per week and own a GPS watch. Their script includes "Tell me about the last time you tried to follow a training plan. " After 7 interviews, assumptions 1 and 2 are validated strongly (6 out of 7 tried a plan, 5 of those abandoned within 6 weeks).
However, assumption 3 is contradicted: the primary reason for abandonment is not complexity but life disruption (travel, illness, schedule changes). The plans do not adapt, so runners feel like failures when they miss days and quit entirely. Assumption 4 is inconclusive. The surprise finding is that runners want forgiveness, not simplicity.
They want a plan that recalculates when they miss a run, not a plan with fewer features.
Example: Enterprise Platform Team Validating an Internal Tool Need
A platform engineering team at a 2,000-person company suspects that internal developer teams waste significant time configuring CI/CD pipelines because there is no standardized template. The "customers" here are internal engineering teams. The platform team lead wants evidence before committing a quarter of engineering time to building a self-service pipeline tool.
They define two assumptions: (1) engineering teams spend more than a day setting up CI/CD for new services, and (2) the lack of a template causes inconsistent configurations that lead to production incidents. They recruit 8 tech leads from different product teams, chosen to represent a range of team sizes and technology stacks. Their interview script asks "Walk me through the last time your team set up CI/CD for a new microservice. " and "Tell me about a recent production incident.
" After 8 interviews, assumption 1 is validated (7 out of 8 reported 1-3 days of setup), but assumption 2 is only partially validated (3 out of 8 connected configuration inconsistency to incidents, while the others attributed incidents to code bugs or infrastructure changes). The surprise finding is that the bigger pain is not initial setup but ongoing maintenance: when the CI/CD platform updates, every team has to update their custom configuration independently, creating rolling disruptions. The platform team pivots their proposal from "a template for new setup" to "a managed pipeline abstraction that handles updates centrally," which addresses the higher-frequency pain point and gets immediate executive buy-in.
Best Practices
Never mention your solution until the final minutes of the interview. The moment you describe what you are building, the respondent shifts from reporting their reality to evaluating your idea. This contamination is irreversible within that interview, and the polite positive reactions you receive are not evidence of demand.
Recruit respondents who have the problem today, not people who might have it someday. A common shortcut is to interview friends, colleagues, or people who are easy to access. Unless they match your target segment criteria precisely, their input will steer you toward a problem that does not exist in your actual market. Verify qualifying criteria before scheduling.
Process each interview before conducting the next one. Extracting quotes and updating your hypothesis matrix between interviews takes 30-45 minutes, but it lets you notice emerging patterns early. By your third interview, you should be adjusting your follow-up questions to probe deeper on themes that are surfacing. Batch-processing at the end creates a fog of blended memories.
Ask about behavior, never about intent. "Would you use a tool that does X?" always produces false positives. "What did you actually do the last time this happened?" produces ground truth. Past behavior is the single strongest predictor of future behavior. Build your entire script around past and present tense questions.
Record verbatim quotes, not summaries. Your paraphrase of what a customer said will unconsciously drift toward confirming your hypothesis. The exact words they used carry emotional weight, reveal their mental model, and provide evidence your team can evaluate independently. If you find yourself writing "she said she was frustrated with reporting" instead of her actual words, you have already lost signal.
Interview in pairs when possible. One person asks questions, the other takes notes. The interviewer can maintain eye contact and follow emotional cues without breaking flow to write. The note-taker captures quotes and timestamps. After the call, compare impressions. Two people hearing the same interview will often notice different signals, which improves synthesis quality.
Set a concrete validation threshold before your first interview. Deciding after the interviews what counts as "validated" introduces bias because you will unconsciously set the bar at wherever your data lands. A common threshold is 4 out of 5 respondents expressing the same unprompted pain point. Write this number down before interview one.
End every interview by asking for referrals. "Is there anyone else who deals with this problem that I should talk to?" produces warmer, better-qualified leads than any other recruitment channel. It also tests whether the respondent takes your research seriously enough to put their reputation behind a recommendation.
Common Mistakes
Pitching your solution during the interview instead of listening
Correction
This happens because founders are excited about their idea and interpret every pause as an opportunity to share it. The signal is easy to spot: if you find yourself saying "so what we are building is" or "imagine a tool that," you have switched from discovery to sales. The respondent will nod along politely, and you will walk away with false validation. Redirect by saying "I would love to share more about that after we finish, but first I want to understand your experience." If you catch yourself pitching, flag that interview as potentially contaminated in your synthesis.
Asking leading or hypothetical questions
Correction
Leading questions look like "Don't you think it would be better if..." or "Would you pay for a tool that..." These feel natural in conversation but produce worthless data because the respondent is reacting to your framing, not reporting their reality. The root cause is usually a script that was written to confirm the hypothesis rather than test it. Audit every question in your script by asking: could this be answered with a story about something that already happened? If the answer is no, rewrite it. Replace "Would you use X?" with "How do you currently handle X?"
Interviewing the wrong people because they are easy to access
Correction
This manifests as a batch of interviews where responses are lukewarm or scattered. You ask about a pain point and the respondent shrugs because they do not actually experience it. The cause is usually convenience sampling: interviewing coworkers, friends, or the first five people who responded to your LinkedIn post. Check your respondent list against your target segment definition before starting.
If more than one respondent does not meet every qualifying criterion, pause recruitment and tighten your sourcing. Five interviews with the right people produce clearer signal than fifteen interviews with a mixed audience.
Stopping after 2-3 interviews because the pattern seems obvious
Correction
Two or three confirming interviews create a strong feeling of validation, especially if the respondents are enthusiastic. But small-sample confirmation is statistically meaningless and psychologically dangerous because it locks in premature commitment. The pattern you see at interview three may evaporate at interview six. Commit to your predetermined sample size (minimum five) before drawing conclusions.
If your first three interviews all confirm the same pain point, use interviews four and five to probe harder for contradictions. Actively seek disconfirming evidence.
Treating the interview as a survey by reading questions mechanically
Correction
Some interviewers become so focused on covering every scripted question that they ignore the most interesting thing the respondent just said. The result is a complete checklist of surface-level answers but zero deep insights. The script exists to prevent awkward silences and ensure coverage, but the real value comes from follow-up questions that chase emotional energy. " You can always return to uncovered questions later.
Review your recordings: if more than half of your questions are read verbatim from the script with no follow-ups in between, you are surveying, not interviewing.
Failing to synthesize interviews into a structured artifact
Correction
Many teams conduct interviews, feel informed, and then make decisions based on general impressions rather than documented evidence. Three months later, nobody remembers exactly what customers said, and the team is arguing about whether the problem was validated. The fix is simple but requires discipline: within 24 hours of each interview, populate your hypothesis evidence matrix with verbatim quotes. After your batch is complete, write the synthesis document with explicit verdicts per assumption.
Without this artifact, the entire interview effort provides no lasting value to the organization.
Other Skills in This Method
Tracking Innovation Accounting Metrics
How to define and measure actionable metrics—rather than vanity metrics—to accurately assess startup progress and learning velocity.
Formulating Testable Business Hypotheses
How to translate business assumptions into clearly defined, falsifiable hypotheses with specific success metrics and timeframes.
Selecting the Right MVP Type for Your Idea
How to choose among MVP formats—landing page MVP, concierge MVP, Wizard of Oz MVP, single-feature MVP, and piecemeal MVP—based on your risk profile and resources.
Building a Minimum Viable Product (MVP)
How to design and build the smallest possible version of your product that allows you to test core assumptions with real customers.
Making Pivot-or-Persevere Decisions
How to use experiment data and innovation accounting to decide whether to pivot your strategy or persevere with the current direction.
Designing Validated Learning Experiments
How to structure low-cost experiments—such as landing page tests, concierge MVPs, and Wizard of Oz tests—to generate validated learning about customer behavior.
Running Build-Measure-Learn Cycles
How to execute rapid iterations through the Build-Measure-Learn feedback loop to systematically validate or invalidate product hypotheses.
Frequently Asked Questions
How many customer discovery interviews do I need to conduct before I can draw conclusions?
Five interviews is the minimum for meaningful pattern recognition within a single segment. If your results are split (3 validate, 2 contradict), extend to 8-10 interviews. Beyond 12-15 interviews in one segment, you typically see diminishing returns. The key is not statistical significance but pattern convergence: when new interviews stop producing new information, you have enough. If you are exploring multiple distinct segments, run 5 interviews per segment.
Should I conduct customer discovery interviews before or after formulating my business hypotheses?
Formulate hypotheses first. Customer discovery interviews without a hypothesis list are just conversations. You need specific assumptions to test, or you will not know what to listen for. Use the [formulating testable hypotheses](/skills/formulating-testable-hypotheses) skill to produce your assumption list, then use interviews to validate or invalidate those assumptions. That said, interviews will often surface unexpected hypotheses you had not considered, which you then carry into your next round.
How do I prepare customer discovery interview questions that avoid leading the respondent?
Start every question with "tell me about," "walk me through," "describe," or "how do you." These prompts invite stories, not yes/no reactions. Avoid any question that contains your proposed solution, implies a correct answer, or uses language like "don't you think" or "wouldn't it be better if." A reliable test: read each question aloud and ask yourself whether you could predict a "favorable" answer. If you can, the question is leading. Rewrite it to be genuinely open-ended. For example, replace "Is reporting a pain point for you?" with "How does your team currently handle reporting?"
What do I do if respondents give short, unhelpful answers?
Short answers usually mean your question was too closed or too abstract. " The word "specific" and the anchor to a real event force the respondent out of generalities. If they remain terse, try the echo technique: repeat their last phrase as a question. " and then wait. Silence and repetition are remarkably effective at drawing out detail. If the respondent is simply not engaged, the interview may not be recoverable, and that is fine. Mark it as low-signal and move on.
Can I conduct customer discovery interviews remotely, or do they need to be in person?
Remote interviews (video call or phone) work well for most B2B and many B2C contexts. The key trade-off is that you lose environmental observation: in person, you might see their messy spreadsheet open on their second monitor or notice physical artifacts of the problem. If observation of the user's physical or digital environment is critical to your hypothesis, push for in-person or screen-sharing. For most problem validation, a 25-minute video call produces ample signal. Choose the format that maximizes your recruitment success rate, since a remote interview with the right person beats an in-person interview with a convenient but wrong person.
How long should each customer discovery interview take?
Aim for 20-30 minutes. This is long enough to get past small talk and into real stories, but short enough that busy people will agree to participate. If you consistently run over 30 minutes, your script probably has too many questions or you are not following up deeply enough on the most important threads. If you consistently finish in under 15 minutes, your questions are too surface-level or your respondents are not well-matched to the topic. The interview should feel slightly too short, which means the respondent had more to say. That is better than dragging through forced questions.
Why do my customer discovery interview results keep confirming every hypothesis?
Universal confirmation is a red flag, not a green flag. The most common cause is leading questions that signal the "right" answer. Review your script for any question that contains your solution, implies an expected answer, or uses positive framing. The second most common cause is recruiting respondents who are too friendly (friends, colleagues, warm contacts who want to be supportive). The third cause is confirmation bias in synthesis: you are hearing what you want to hear and filtering out contradictions. Ask a team member who was not in the interviews to independently read the transcripts and categorize the evidence. If their categorization differs from yours, your synthesis is biased.