Learning Resources · Methods Library · Need-Focused Interviewing
Discovery

Need-Focused Interviewing

Used in: A1.2 Step 2.1 (Need discovery) A1.3 Step 2 (Root cause exploration) A1.4 Step 3 (Multi-dimensional understanding) A6 Step 3 (Concept validation) Core Method: Qualitative inquiry across discovery and validation stages

QR code linking to this method page Scan to open

Purpose

Conduct structured conversational inquiry to deeply understand user experiences, needs, motivations, obstacles, and reactions through one-on-one dialogue. Interviewing is the most versatile qualitative research method, adaptable across all innovation lifecycle stages from need discovery (A1.2) through concept validation (A6).

Interviews excel at exploring:

  • Jobs and goals: What users are trying to accomplish (Jobs-to-be-Done framing)
  • Conscious frustrations and obstacles: Barriers users can articulate
  • Emotional impacts: How needs affect users psychologically (anxiety, confidence, burden)
  • Decision-making and priorities: What matters most to users, how they make choices
  • Frequency and patterns: How often needs manifest, temporal patterns
  • Workaround strategies: Coping mechanisms users consciously employ
  • Reactions and comprehension: User responses to concepts, prototypes, or ideas (validation stages)

Interviews cannot reliably surface:

  • Latent needs users have normalized (“that's just how it is”)—requires observation ()
  • Tacit workarounds that have become automatic—requires ethnographic methods
  • Behavioral patterns users don't consciously recognize—requires direct observation
  • Discrepancies between reported and actual behavior—triangulation with observation needed

When to Use

Interviewing is appropriate when:

  • Users can consciously articulate experiences (vs. latent/tacit needs requiring observation)
  • Need deep exploration of motivations, emotions, decision-making, impacts beyond what observation reveals
  • Want to understand “why” behind behaviors (complement to observation's “what”)
  • Distributed user base makes observation impractical (remote interviews feasible)
  • Need to explore hypothetical scenarios or future intentions (within limits)
  • Validating concepts, prototypes, or ideas requiring user reactions

Interviewing is NOT sufficient when:

  • Need is primarily behavioral/tacit—users “can't say but can show” → Use observation ()
  • Suspected gap between self-report and behavior—triangulate with observation
  • Need manifestation highly context-dependent—supplement interviews with contextual inquiry
  • Frequency/temporal patterns uncertain—add diary studies ()

Best practice: Combine interviewing with at least one observational method for robust validation.

Prerequisites

Before conducting interviews:

  • Clear investigation focus: Need hypothesis (A1.2), validated need (A1.3), concept to validate (A6)
  • Target user types identified: Who to interview based on Step 1 planning
  • Recruitment complete or in progress: Participants scheduled with confirmed availability
  • Interview guide prepared: Tailored question list aligned with investigation purpose (templates below)
  • Recording tools ready: Audio/video recording equipment tested, consent forms prepared
  • Interviewer capability: Team member(s) trained in interview techniques, comfortable with conversational inquiry
  • Ethical approval: IRB approval if required, informed consent process established

Quality Criteria

Good interview indicators

An effective need discovery interview exhibits:

  • 70/30 talk ratio: User talks 70% of time, interviewer 30%—indicates proper listening balance
  • Multiple specific stories captured: At least 3-5 concrete examples from user's experience (not generic responses)
  • Emotional responses noted: Interviewer documented frustration, anxiety, relief, enthusiasm—signals need intensity
  • Reached underlying needs: Moved beyond surface solution requests to fundamental needs through probing
  • User comfortable and honest: Rapport established, user sharing openly including negative experiences
  • Concrete details about workarounds: User described specific coping strategies with time/effort data
  • Breakdown moments explored: At least one story of process failure with consequences
  • Context variation revealed: Identified when need is worse/better based on situational factors

Poor interview indicators

Warning signs of inadequate interview:

  • Interviewer dominated conversation: Talking more than user, explaining instead of listening
  • Generic responses without examples: User says “it's generally frustrating” but can't provide specific instance
  • User defensive or giving "right answers": Feels judged, trying to look competent rather than sharing honestly
  • Stuck discussing features/solutions: Interview became feature request session rather than need exploration
  • Rushed through sections: Skipped core Need/Obstacle Exploration to “get through guide”—sacrificed depth
  • Technical problems disrupted flow: Recording failures, connectivity issues broke rapport
  • No emotional dimension captured: Purely functional discussion, missed affective needs
  • Interviewer bias evident: Leading questions, confirming hypotheses rather than exploring openly

Self-assessment after interview

Interviewers should evaluate each interview:

  • Did I learn something unexpected? (If everything confirmed hypotheses, possible confirmation bias)
  • Did user share at least 3 specific stories? (Concrete vs. abstract)
  • Did I understand why user has workarounds? (Not just what they are)
  • Could I describe user's emotional experience? (Beyond functional obstacles)
  • Did I resist suggesting solutions? (Solution-free discipline maintained)
  • Would this interview data enable synthesis? (Rich enough for pattern identification)

Complete Interview Protocol for A1.2 Need Discovery

This protocol is specifically for A1.2 need discovery interviews. For adaptations to other activities (A1.3 root cause exploration, A6 concept validation), see “Adaptations by Activity” section at end of this method.

Core principle: Questions explore what users are trying to accomplish (jobs/goals), what prevents them (obstacles/needs), how they currently cope (workarounds revealing need significance), and how this affects them (emotional and functional impact)—all without discussing solutions, features, or competitive products.

Interview Structure and Question Flow

A well-structured 60-75 minute need-focused interview follows this progression:

| SectionDurationPurpose
Opening5 minBuild rapport, establish context, secure consent
Context Setting10 minUnderstand user's role, workflows, environment
Job/Goal Exploration15 minWhat user is trying to accomplish (JTBD framing)
Need/Obstacle Exploration20-25 minWhat gets in user's way (CORE SECTION)
Impact Assessment10 minHow obstacles affect user (intensity, frequency)
Closing5 minAdditional topics, referrals, thanks
Need-Focused Interview Structure

Opening Section (5 minutes)

Purpose: Establish comfortable environment, explain research purpose, secure informed consent, begin building trust.

Sample opening script:

quote “Thank you for taking time to speak with me today. I'm [name] from [organization], and I'm conducting research to understand the challenges people face when [relevant domain]. This isn't a sales call—we're not trying to sell you anything. We're in early exploration, trying to learn from people like you who have direct experience with [domain].

I'd like to record our conversation so I can focus on listening rather than taking notes, and so I can review what you share later. The recording is just for our research team—we won't share it publicly or use your name without permission. Is that okay with you?

Everything you share will be confidential. In any reports or presentations, we'll anonymize quotes and won't identify you or your company unless you explicitly give us permission.

This should take about 60 minutes. I'll ask questions about your experiences, and please feel free to share honestly—there are no wrong answers. Does this all sound okay? Any questions before we start?” quote

Key elements:

  • Explicitly state “not selling”—reduces user defensiveness
  • Explain recording purpose and confidentiality—builds trust
  • Set time expectation—respects user's schedule
  • Invite questions—establishes collaborative tone

Rapport building - Light opener question (choose one based on context):

  • “Before we dive in, tell me a bit about yourself—how did you end up in [role/domain]?”
  • “What's your background? How long have you been doing [relevant work]?”
  • “I'd love to hear your journey—what led you to [current position/situation]?”

Purpose: Easy question gets user talking, establishes conversational tone rather than interrogation feel. Listen for:

  • How long in role (experience level affects need perception)
  • Career path (reveals priorities, values)
  • Passion or frustration in tone (signals areas to explore)

Context Setting Section (10 minutes)

Purpose: Understand user's role, responsibilities, typical workflows, and environment—context needed to interpret need discussions.

Role and responsibilities - Opening question:

  • “Tell me about your current role. What are you responsible for day-to-day?”
  • “Walk me through a typical [day/week] for you. What fills your time?”
  • “What does your job entail? What are the main things you're accountable for?”

Follow-up probes:

  • “What does success look like in your role? How is your performance measured?”
  • “What takes up most of your time? What gets the most attention?”
  • “What parts of your role are most important vs. less critical?”

Why this matters: Understanding role scope and priorities helps contextualize needs—a minor frustration in low-priority task is less significant than obstacle in core responsibility.

Workflow and environment exploration:

  • “Walk me through how [relevant process] typically works for you.”
  • “Describe your workflow for [activity related to need hypothesis]. What are the steps?”
  • “When you need to [relevant task], what do you do? Start to finish.”

Environment and tools:

  • “What tools or systems do you use for [relevant activity]?”
  • “Who do you typically interact with or depend on for [relevant work]?”
  • “What's your work environment like? (Office, remote, hybrid? Solo or team-based?)”

Why this matters: Workflow details reveal where breakdowns occur (need manifestation points); tools/systems show current coping strategies; environment factors affect need experience.

Success criteria and priorities:

  • “When you think about [relevant domain], what does 'done well' look like?”
  • “What are your top priorities in [relevant area]? What matters most?”
  • “If you could wave a magic wand and change one thing about [relevant work], what would it be and why?”

Why this matters: Success criteria become “gains” in empathy maps; priorities indicate which needs are most significant; magic wand question often surfaces highest-intensity need without directly asking.

Job/Goal Exploration Section (15 minutes)

Purpose: Understand what user is trying to accomplish—their jobs-to-be-done, goals, desired outcomes. This is JTBD framing for understanding the job, NOT competitive hiring analysis.

Functional jobs (what user is trying to accomplish) - Primary job identification:

  • “When you [relevant activity], what are you ultimately trying to achieve?”
  • “What's the goal when you do [task]? What would successful completion look like?”
  • “Why does [task] matter? What's the bigger purpose it serves?”

Job decomposition:

  • “Let's break that down—what are the sub-goals or steps involved in [primary goal]?”
  • “To accomplish [goal], what needs to happen first? Then what?”
  • “Are there different types of [job] you do? How do they differ?”

Example (sales forecasting context):

quote Interviewer: “When you create your quarterly forecast, what are you ultimately trying to achieve?”

User: “I need to give my VP an accurate pipeline prediction.”

Interviewer: “Why does that matter? What happens with an accurate prediction?” (Probing for underlying goal)

User: “VP uses it for resource planning—hiring, territory assignments. If I'm way off, we're either under-resourced or over-committed.”

Interviewer: “So the job is providing reliable input for organizational planning, not just submitting numbers?”

User: “Exactly. And personally, being accurate builds my credibility.” quote

Notice: Questions explore the job/goal itself, not which products user might “hire” to do job (that's competitive analysis, out of A1.2 scope).

Emotional and social jobs:

Christensen's JTBD framework recognizes jobs have functional, emotional, and social dimensions. A1.2 explores all three.

Emotional job questions:

  • “How do you feel when [task] goes well? What about when it doesn't?”
  • “What emotions come up around [activity]? (Stress, confidence, anxiety, satisfaction?)”
  • “Is there a personal dimension to [task] beyond just getting it done?”

Social job questions:

  • “How does [task outcome] affect your relationships with [colleagues/manager/customers]?”
  • “What do others expect from you regarding [activity]? How does that pressure feel?”
  • “Is there a reputation or credibility aspect to [task]?”

Example:

quote “You mentioned forecast accuracy builds credibility. Tell me more about that social dynamic.”

“When I nail the forecast, my VP trusts my judgment on other stuff. When I miss, I feel like I'm back to proving myself. There's definitely a 'am I competent?' undercurrent.” quote

This reveals emotional job (building confidence/reducing anxiety) and social job (establishing credibility) beyond functional job (providing numbers).

Success criteria and desired outcomes:

  • “What would 'perfect' look like for [job/goal]? If everything worked ideally?”
  • “How do you know when you've done [task] successfully?”
  • “What outcomes are you optimizing for? Speed, accuracy, thoroughness, something else?”

Why this matters: Success criteria define “gains” (desired outcomes when need is satisfied). Later, A2-A7 solutions must deliver these outcomes or they won't satisfy need.

Need/Obstacle Exploration Section (20-25 minutes) — CORE

Purpose: Identify what prevents users from accomplishing their jobs/goals—this is where needs are directly revealed. This is the heart of A1.2 interviewing.

General obstacle identification - Opening need exploration:

  • “What gets in your way when trying to [accomplish goal]?”
  • “What's hard or frustrating about [task/process]?”
  • “When [activity] doesn't go smoothly, what typically goes wrong?”
  • “What slows you down or creates friction in [workflow]?”

Probing for specificity:

  • “Can you give me a specific example of when [obstacle] happened?”
  • “Tell me about the last time you experienced [challenge]. Walk me through it.”
  • “What makes [obstacle] particularly difficult? What aspect is most frustrating?”

Critical technique: Request STORIES, not generalities

❌ “Do you ever have trouble with [task]?” (Yes/no, shallow)

✅ “Tell me about the last time [task] was difficult. What happened?” (Concrete story, rich detail)

Five Whys technique (reaching underlying needs):

When user describes surface obstacle, probe deeper with “why” questions to reach underlying need:

Example progression:

quote User: “I need better reports from the CRM.”

Interviewer: “What's not working with current reports?” (Why #1)

User: “They don't show the data I need for forecasts.”

Interviewer: “What data is missing that you need?” (Why #2)

User: “Deal health signals—executive engagement, legal status, budget approval.”

Interviewer: “Why are those signals important for your forecast?” (Why #3)

User: “Without them, I'm guessing if deals will close. Can't tell what's real vs. stalled.”

Interviewer: “What happens when you can't tell?” (Why #4)

User: “I either over-commit (if I'm optimistic) or sandbag (if conservative). Both look bad.”

Interviewer: “How does looking bad affect you?” (Why #5)

User: “Undermines my credibility with leadership. Creates stress every forecast cycle.” quote

Underlying need revealed: Confidence and credibility in forecasting (not “better reports”—that's a solution request).

How many “whys”: Not rigidly five—stop when you reach emotional or fundamental need. Sometimes 3 whys suffice; sometimes need 6-7.

Breakdown and failure exploration:

Needs manifest most clearly when things break down or fail. Explore these moments intensively.

Questions:

  • “Tell me about a time when [process] completely broke down. What happened?”
  • “When [task] goes wrong, what are the warning signs? How do you know it's going off track?”
  • “What's the worst-case scenario with [activity]? Have you experienced that?”
  • “Describe a situation where you couldn't accomplish [goal]. What prevented you?”

Follow-up probes for breakdown stories:

  • “What triggered the breakdown? What was the first sign of trouble?”
  • “How did you realize something was wrong?”
  • “What did you do when it broke down? How did you respond?”
  • “What was the consequence? How did this affect you/your team/your goals?”
  • “How long did it take to recover? What did recovery require?”

Why breakdowns matter: They reveal need intensity (bigger consequences = higher intensity) and need boundaries (when things work OK vs. when they fail).

Workaround and coping strategy exploration:

How users currently handle needs reveals need significance—elaborate workarounds indicate high need intensity.

Questions:

  • “How do you currently handle [challenge/obstacle]?”
  • “What tricks or shortcuts have you developed for [task]?”
  • “Walk me through your actual process—not the official process, but how you really do it.”
  • “Do you do anything 'off the books' to make [task] work?”

Probing workaround details:

  • “How much time does [workaround] take? How often do you do it?”
  • “Is that approach reliable, or does it sometimes fail?”
  • “Have you tried other approaches? What didn't work?”
  • “If you couldn't use [workaround], what would happen?”

Example:

quote “You mentioned keeping a spreadsheet outside the CRM. Tell me about that—what's in it?”

“15 columns tracking deal health indicators our CRM doesn't capture. Color-coded by confidence level. Takes me 45 minutes to update every Monday.”

“How critical is that spreadsheet? What if you lost it?”

“I'd be forecasting blind. That spreadsheet IS my forecast confidence.” quote

This reveals workaround burden (45 min/week, manual maintenance) and dependency (critical to job performance)—strong need intensity indicators.

Constraint and limitation exploration:

  • “What limits or constrains you in [task/domain]? What boundaries do you operate within?”
  • “Are there things you wish you could do but can't? What prevents you?”
  • “What resources do you lack that would help with [challenge]? (Time, information, tools, authority, expertise)”
  • “If you had complete freedom, how would you approach [task] differently?”

Why constraints matter: They reveal contextual factors shaping need experience and may point to enabling needs (prerequisites that must be satisfied before focal need can be addressed).

Comparison and contrast (without competitive products):

Explore variation in need experience across different contexts—reveals when need is most/least acute.

Questions:

  • “Does [challenge] vary depending on [context factor]? When is it worse/better?”
  • “Are there situations where [task] is easy vs. difficult? What makes the difference?”
  • “Compare your experience with [scenario A] vs. [scenario B]. How do they differ?”
  • “When you first started [role/task], how was it different? Has [challenge] changed over time?”

Example:

quote “Is forecasting equally difficult year-round, or are there periods when it's harder?”

“End of quarter is hell. Mid-quarter is manageable—smaller deals, less pressure. Q4 is worst because annual targets are on the line.” quote

This reveals temporal context affecting need intensity (quarterly cycles, annual pressure).

NOTE: These are context comparisons, NOT competitive product comparisons. We're exploring when/where need arises, not “Product A vs. Product B.”

Impact Assessment Section (10 minutes)

Purpose: Understand how obstacles affect user—functional impact, emotional impact, frequency, consequences. This establishes need intensity and pervasiveness.

Frequency assessment:

  • “How often does [obstacle/challenge] come up? Daily, weekly, monthly?”
  • “Is this a constant issue or sporadic?”
  • “When you think about last [week/month], how many times did you encounter [challenge]?”

Why frequency matters: High-frequency needs (daily, weekly) are more significant than rare needs (annually), all else equal.

Functional impact assessment:

  • “When [obstacle] happens, what's the practical consequence? What can't you do?”
  • “How does [challenge] affect your ability to [accomplish goal]?”
  • “What's the cost of [obstacle]—in time, money, errors, missed opportunities?”
  • “If [challenge] went away completely, what would be different in your work?”

Quantification when possible:

  • “How much time does [workaround/obstacle] consume? Per day/week/month?”
  • “How much does [failure scenario] cost when it happens?”
  • “What's your error rate or failure rate with [task]?”

Example:

quote “You mentioned forecast inaccuracy creates problems. What's the typical magnitude—are you off by 5%, 20%, more?”

“I try to stay within 10% variance, but bad quarters I've been off 25%. That's 'explain yourself to leadership' territory.” quote

Quantified impact strengthens need documentation.

Emotional impact assessment:

  • “How does [challenge] make you feel? (Stressed, anxious, frustrated, overwhelmed?)”
  • “What goes through your mind when dealing with [obstacle]?”
  • “Is there an emotional toll to [challenge]? What is it?”
  • “On a scale of minor annoyance to major stressor, where does [challenge] fall for you?”

Probing emotional intensity:

  • “You said [emotion word]—tell me more about that. How intense is that feeling?”
  • “Does [challenge] keep you up at night? Cause Sunday evening dread?”
  • “How do you cope with the stress/frustration of [obstacle]?”

Why emotional impact matters: Strong emotional responses (anxiety, dread, relief when resolved) signal high-intensity needs worth addressing.

Consequence exploration (what's at stake):

  • “What's at stake if you don't handle [challenge] well? What's the downside?”
  • “Has [failure scenario] ever had serious consequences for you? What happened?”
  • “In the worst case, what could go wrong if [obstacle] isn't managed?”
  • “What would happen if you just... didn't do [task] at all? (Even if that's not realistic)”

Example:

quote “What's at stake with forecast accuracy? Beyond looking bad?”

“Directly affects my comp—bonus is tied to forecast accuracy. And if I'm consistently off, I worry about my job security. My VP fired someone last year partly for unreliable forecasts.” quote

High-stakes consequences (compensation, job security) indicate high need intensity.

Satisfaction and dissatisfaction:

  • “On a scale of 1-10, how satisfied are you with how [task/process] currently works? Why that rating?”
  • “What would it take to move from [current rating] to [higher rating]?”
  • “When you think about [domain], what leaves you most dissatisfied or frustrated?”
  • “Conversely, what's working well? What are you satisfied with?”

Why ask about satisfaction: Helps distinguish true needs (deep dissatisfaction, low ratings) from minor irritations (moderate satisfaction, 6-7 ratings).

Closing Section (5 minutes)

Purpose: Capture anything missed, obtain referrals, express gratitude, maintain positive relationship.

Open-ended closing questions:

  • “What haven't I asked about that's important for understanding [domain]?”
  • “If you were doing this research, what else would you want to know?”
  • “Is there anything about [topic] we haven't covered that you think I should understand?”
  • “Any final thoughts or stories you'd like to share about [domain]?”

Why this matters: Users often save most important insights for end, or realize during interview what you really need to know. Open-ended closing captures this.

Referral requests:

  • “Do you know others who might have similar experiences or perspectives I should talk to?”
  • “Who else should I speak with to get a fuller picture of [domain]?”
  • “Would you be comfortable introducing me to [specific person/role type]?”

Follow-up permission:

  • “Would it be okay if I followed up with you if I have clarifying questions after reviewing our conversation?”
  • “As our research progresses, would you be interested in hearing what we learn?”

Closing script:

quote “This has been incredibly helpful—thank you for being so generous with your time and insights. What you've shared will really help us understand [domain] better.

As a reminder, everything you shared is confidential. We'll use your insights in our research, but won't identify you or your company without permission.

[If applicable:] We'll send you a small thank-you gift card as appreciation for your time—should arrive via email within a few days.

Thanks again, and please don't hesitate to reach out if you think of anything else you'd like to add!” quote

Interview Techniques and Question Types

Beyond specific questions, effective A1.2 interviewing employs various question types and probing techniques:

Open vs. closed questions

Open questions (preferred for exploration):

  • “Tell me about...” / “Describe...” / “Walk me through...”
  • “How do you...” / “What do you...” / “Why does...”
  • Elicit narrative, detail, user's own language

Closed questions (use sparingly, for confirmation):

  • “Do you...?” / “Is it...?” / “Have you...?”
  • Yield yes/no or short answers
  • Useful for confirming understanding: “So you're saying [paraphrase]—is that right?”

Ratio: 80% open questions, 20% closed questions for confirmation.

Probing techniques

Silence probe:

  • After user answers, pause 2-3 seconds before responding
  • Users often elaborate to fill silence, adding richer detail

Echo probe:

  • Repeat last few words user said as question: User: “It's frustrating.” → Interviewer: “Frustrating?”
  • Prompts user to elaborate without directing content

Clarification probe:

  • “Can you say more about that?”
  • “Help me understand what you mean by [term user used].”
  • “When you say [quote], what specifically do you mean?”

Example probe:

  • “Can you give me a specific example of when that happened?”
  • “Tell me about the last time you experienced that.”
  • Grounds abstract statements in concrete experiences

Contrast probe:

  • “How is that different from [alternative]?”
  • “Compare [situation A] to [situation B]—how do they differ?”
  • Reveals nuances and boundaries

Feeling probe:

  • “How did that make you feel?”
  • “What was going through your mind at that moment?”
  • Surfaces emotional dimension of needs

What NOT to Ask (Critical Boundaries)

A1.2 interviews must avoid questions that introduce solution thinking or competitive framing. These contaminate need discovery with bias.

NO Solution-Focused Questions

❌ Don't ask:

  • “What features would you want in a solution?”
  • “If we built a tool for [task], what should it do?”
  • “How would you design the perfect [product] for this?”
  • “What would make [our product/service] better?”
  • “Which capabilities are most important in a [solution category]?”

Why not: These anchor user on solutions (features, capabilities) rather than needs. Users think about what they can imagine building, not underlying needs.

✅ Instead ask:

  • “What are you trying to accomplish that you can't today?”
  • “What would be different if [obstacle] went away?”
  • “What does success look like for [goal]?”

Focus on outcomes and needs; solutions come later in A2 Ideation.

NO Competitive Product Questions

❌ Don't ask:

  • “Which products do you currently use for [task]?”
  • “How does Product A compare to Product B?”
  • “Why did you choose [Product X] over alternatives?”
  • “What do you like/dislike about [Competitor Y]?”
  • “If you could switch from [current solution] to something else, what would it be?”

Why not: These are competitive analysis questions requiring solution comparison—belongs after A2 Ideation when you have solution concepts to position.

✅ Instead ask:

  • “How do you currently handle [task]?” (May reveal tools used, but focus is on approach not product evaluation)
  • “What works well about your current approach? What doesn't?”
  • “When your current approach fails, what happens?”

Focus on understanding current state and gaps (needs), not evaluating competitive products.

NO Leading Questions

❌ Don't ask:

  • “Don't you think [task] is frustrating?” (Suggests expected answer)
  • “Most people struggle with [X]—do you?” (Implies user should agree)
  • “Isn't it true that [assumption]?” (Leading toward confirmation)

✅ Instead ask:

  • “How do you feel about [task]?” (Open, neutral)
  • “What's your experience with [X]?” (No suggested response)
  • “Tell me about [topic].” (Pure exploration)

NO Hypothetical Questions (generally)

❌ Avoid:

  • “What would you do if [hypothetical scenario]?”
  • “Imagine [hypothetical situation]—how would you handle it?”

Why: Hypothetical responses are unreliable—what people say they'd do differs from actual behavior.

✅ Instead ask:

  • “Tell me about the last time [scenario] happened. What did you actually do?”

Focus on real past experiences, not hypothetical futures.

Exception: “Magic wand” questions acceptable for revealing aspirations:

  • “If you could wave a magic wand and change one thing about [domain], what would it be?”

This surfaces priorities without asking for solution specifications.

Adapting Questions by Context

Interview questions should adapt to user type, domain, and investigation focus:

B2B vs. Consumer contexts

B2B additional topics:

  • Organizational dynamics: “How does your [process] fit into broader organizational workflows?”
  • Stakeholder complexity: “Who else is involved in [task]? How do their needs interact with yours?”
  • Decision-making: “How are decisions about [domain] made in your organization?”
  • Constraints: “What organizational policies or constraints affect how you approach [task]?”

Consumer additional topics:

  • Life context: “How does [task] fit into your daily/weekly routine?”
  • Personal values: “What matters most to you when it comes to [domain]?”
  • Social dynamics: “Do you discuss [topic] with friends/family? What do they say?”
  • Trigger events: “What prompted you to start [behavior/task]?”

Expert vs. Novice users

For experts (adjust language and depth):

  • Use domain terminology (they're comfortable with jargon)
  • Probe for nuanced distinctions: “How does [scenario A] differ from [scenario B] in your expert view?”
  • Ask about edge cases and complex situations
  • Explore evolution: “How has your approach changed as you've gained experience?”

For novices (simplify, provide more context):

  • Avoid or explain jargon
  • Focus on basics and common scenarios
  • Probe confusion and learning challenges: “What was hardest to understand when you started?”
  • Validate uncertainties: “It's okay if you're not sure—I'm interested in your honest experience.”

Interview Guide Template

Practical template for A1.2 interview preparation:

mdframed[linecolor=alphacolor, linewidth=2pt, roundcorner=5pt, backgroundcolor=alphacolor!5] A1.2 Need-Focused Interview Guide Template

Investigation: [Need hypothesis]

Interview Date: [Date] | Interviewer: [Name] | Participant: [ID/pseudonym]

0.3cm

OPENING (5 min)

  • Intro, consent, recording permission
  • Rapport: “Tell me about your background—how did you get into [role]?”

CONTEXT SETTING (10 min)

  • “Describe your role and main responsibilities.”
  • “Walk me through a typical [day/week/workflow].”
  • “What does success look like in your work?”

JOB/GOAL EXPLORATION (15 min)

  • “When you [relevant activity], what are you trying to accomplish?”
  • “Why does [goal] matter? What's the bigger purpose?”
  • “How do you know when you've done [task] successfully?”
  • “Beyond functional goals, is there an emotional or social dimension?”

NEED/OBSTACLE EXPLORATION (20-25 min) — CORE

  • “What gets in your way when trying to [accomplish goal]?”
  • “Tell me about the last time [task] was difficult. What happened?” [Get story]
  • “What's most frustrating about [process]?”
  • Five Whys: Keep probing “why” to reach underlying need
  • “How do you currently handle [challenge]?” [Workarounds]
  • “Tell me about a time when [process] completely broke down.” [Breakdown story]
  • “Does [challenge] vary by context? When is it worse/better?”

IMPACT ASSESSMENT (10 min)

  • “How often does [obstacle] come up?”
  • “What's the practical consequence when [obstacle] happens?”
  • “How does [challenge] make you feel emotionally?”
  • “What's at stake if [challenge] isn't handled well?”
  • “On 1-10 scale, how satisfied are you with [process] currently?”

CLOSING (5 min)

  • “What haven't I asked that's important?”
  • “Do you know others I should speak with?”
  • “Can I follow up if I have clarifying questions?”
  • Thank participant, confirm confidentiality, explain next steps

0.3cm

Notes for interviewer:

  • Listen 70%, talk 30%
  • Probe for specific stories, not generalities
  • When user requests features/solutions, ask “Why do you want that? What would it enable?”
  • Note emotional responses (frustration, anxiety, relief)—signal need intensity
  • Let silences breathe—users often elaborate after pauses

mdframed

Adaptations by Activity

While the core interview protocol above is for A1.2 need discovery, interviewing adapts across innovation lifecycle activities:

A1.2 Need Discovery Interviews

Core inquiry focus: Jobs/goals, obstacles, need manifestation, current workarounds

Key principles:

  • NO solution discussion—focus exclusively on needs
  • Request specific stories, not generalities
  • Use Five Whys to reach underlying needs
  • Distinguish needs from solution requests
  • Explore emotional and social dimensions

Sample size: 12-20 interviews spanning identified user types, continuing until patterns stabilize (saturation)

A1.3 Root Cause Exploration Interviews

Core inquiry focus: Why validated need exists, underlying causes, causal chains

Key questions:

  • “Why does [validated need] occur?”
  • “What would have to change for this need to no longer exist?”
  • “When does this need NOT occur? What's different in those situations?”
  • Five Whys progression targeting causation
  • “What systemic factors create [need]?”

Input required: A1.2 validated need statement—root cause interviews build on established need understanding

Interview adjustments:

  • Start with validated need (not discovering need from scratch)
  • Focus on causal factors, not need manifestation
  • Explore systemic causes, not just symptoms
  • Probe what would eliminate need entirely
  • May interview different stakeholders (causes may span user types)

Sample size: 8-12 interviews focused on specific causal hypotheses

A1.4 Need Exploration Interviews (Multi-dimensional Understanding)

Core inquiry focus: Technical feasibility, user context nuances, business implications, ecosystem dependencies

Key questions:

  • Technical dimension: “What technical constraints affect [need]?” “What infrastructure exists/is missing?”
  • User dimension: “How does [need] vary across different user groups?” “What user capabilities affect this?”
  • Business dimension: “What business factors influence [need]?” “How does organizational structure affect this?”
  • Ecosystem dimension: “What external dependencies exist?” “How do regulatory/market factors affect [need]?”

Input required: A1.2 validated need + A1.3 root cause analysis

Interview adjustments:

  • May interview domain experts, not just end users
  • Focus on specific dimensions (technical, business, ecosystem)
  • Explore feasibility boundaries and constraints
  • Can be shorter, more focused interviews (30-45 min)

Sample size: 6-10 interviews per dimension explored

A6 Concept Validation Interviews

Core inquiry focus: Concept comprehension, need-solution fit, usage likelihood, adoption barriers

Key questions:

  • “What is this concept trying to do?” (comprehension check)
  • “How well would this address [your need]?”
  • “What works well about this concept? What's missing or concerning?”
  • “How would you use this? Walk me through a scenario.”
  • “How does this compare to what you do today?”
  • “What would make you adopt/not adopt this?”

Input required: A3 concept description/prototype—validation interviews require artifact to react to

Interview adjustments:

  • Present concept/prototype upfront (first 5-10 min)
  • Focus on reactions and comprehension, not need discovery (needs already validated)
  • Probe fit with previously validated need
  • Explore usage scenarios and adoption likelihood
  • Can identify concept gaps or misalignments with need

Sample size: 10-15 interviews spanning user types from A1.2 segmentation

Tools and Resources

Recording and transcription

Recording equipment/software:

  • Video conferencing: Zoom, Microsoft Teams, Google Meet (built-in recording)
  • Audio recorders: Smartphone voice recorder apps, dedicated recorders (Sony, Olympus)
  • Backup recording: Always have backup—second device recording simultaneously

Transcription services:

  • Rev.com: Human transcription, $1.50/min, 99%+ accuracy, 12-24 hour turnaround
  • Otter.ai: AI transcription with human review option, $0.25/min AI-only, real-time transcription
  • Descript: AI transcription + editing, $12/month for 10 hours, integrated video editing
  • Trint: AI transcription, $48/month for 7 hours, supports 30+ languages

Cost estimate: 15 × 60-minute interviews = $1,350-2,700 for complete professional transcription

Interview guides and templates

Standard materials:

  • Interview guide template (provided above)—customize per investigation
  • Informed consent form (obtain legal/ethics review)
  • Participant information sheet explaining research purpose, confidentiality
  • Incentive tracking spreadsheet (who received what compensation)

Note-taking and documentation

During interview:

  • Minimal notes—maintain eye contact and active listening
  • Note key quotes, emotional moments, time stamps for important segments
  • Observation/emotion logging: track when user shows frustration, excitement, confusion

Post-interview:

  • Debrief notes immediately after interview (while memory fresh)
  • Note non-verbal cues, tone, energy that recordings don't capture
  • Document initial impressions and emerging themes

Tools:

  • Digital notebooks: Notion, Evernote, OneNote for organizing interview notes
  • Qualitative analysis software: NVivo, Dedoose, Atlas.ti for coding transcripts
  • Simple alternative: Spreadsheet with columns: Participant, Quote/Insight, Codes, Notes

Recruitment and scheduling

Scheduling tools:

  • Calendly, Doodle for easy participant scheduling
  • Buffer time between interviews (15-30 min) for debrief and preparation

Incentive management:

  • Amazon gift cards, Visa prepaid cards for consumer participants
  • Charitable donations as alternative incentive
  • Track in spreadsheet: Participant ID, incentive amount, delivery date, confirmation

Participant tracking:

  • CRM or spreadsheet tracking: Name, role, contact, user type, interview date, status, notes
  • Tag with user type from segmentation for ensuring coverage

Common Challenges and Solutions

Challenge 1: User jumps to solution requests

Scenario: User says “I need a feature that does X” or “You should build Y.”

Why this happens: Users think in solutions because that's how products are marketed; easier to describe solution than articulate underlying need.

Solution - Redirect to underlying need:

  • “That's interesting—what would that enable you to do that you can't today?”
  • “Help me understand the situation where you'd use that. What's the problem you're solving?”
  • “Tell me about the need beneath that solution idea.”
  • “Before we talk solutions, help me understand what you're trying to accomplish.”

Example exchange:

quote User: “I need a dashboard showing all my deals.”

Interviewer: “What would seeing all your deals enable you to do?”

User: “I'd know which ones need attention.”

Interviewer: “Tell me about a time you didn't know which deals needed attention. What happened?”

User: “Last quarter, a big deal stalled and I didn't realize until too late...” quote

Now exploring the underlying need (knowing deal status) through concrete story.

Challenge 2: User gives generic responses

Scenario: User says “It's fine, mostly works okay” or “It's sometimes frustrating.”

Why this happens: User being polite, hasn't reflected deeply, or question too abstract.

Solution - Request specific stories:

  • “Can you tell me about the last time you did [task]? Walk me through it step-by-step.”
  • “You said 'sometimes frustrating'—tell me about a specific time when it was frustrating. What happened?”
  • “When it doesn't work okay, what happens? Give me a concrete example.”
  • Use silence—pause 3-4 seconds after generic response. User often elaborates to fill silence.

Challenge 3: User is defensive about current approach

Scenario: User feels criticized about workarounds, mistakes, or inefficiencies. Becomes guarded.

Why this happens: User interprets questions as judgment (“why are you doing it wrong?”).

Solution - Reframe as learning, not evaluation:

  • “I'm not evaluating you or your approach—I'm trying to understand the challenges anyone in your position would face.”
  • “You've clearly developed smart workarounds. I want to understand what drove those creative solutions.”
  • “There are no wrong answers. Your honest experience is exactly what I need to learn from.”
  • “I'm learning from your expertise about what makes [task] challenging.”

Tone matters: Use curious, respectful tone. Avoid “why do you...?” (can sound accusatory); use “help me understand...” (collaborative).

Challenge 4: Interview goes off-topic

Scenario: User shares interesting but tangential stories (war stories, company politics, unrelated complaints).

Why this happens: User enjoying conversation, thinks tangent is relevant, or avoiding harder questions.

Solution - Graceful redirection:

  • “That's fascinating. Let me make sure I understand [tangent point], then I'd like to return to [core topic].”
  • “I want to respect your time—let me steer us back to [focus area].”
  • “That's really interesting. Can we bookmark that and come back if we have time? Right now I want to make sure we cover [core topic].”

Judgment call: Allow some tangents (may reveal unexpected insights) but redirect after 2-3 minutes. Don't rigidly follow guide—balance structure with exploration.

Challenge 5: Limited time remains, not all questions covered

Scenario: Interview is 45 minutes in, only 15 minutes left, haven't covered all sections.

Why this happens: User verbose, earlier sections took longer than planned, or interview started late.

Solution - Prioritize core sections:

  • MUST COVER: Need/Obstacle Exploration (20-25 min core section)—this is the heart
  • NEXT PRIORITY: Impact Assessment (10 min)—establishes intensity
  • CAN ABBREVIATE: Context Setting (if running short, 5 min sufficient), Job/Goal Exploration (can integrate into Need/Obstacle section)
  • CAN SKIP IF NECESSARY: Some closing questions (but always thank and ask for referrals)

In moment: “I want to make sure we cover [most important topic]. Let me shift our focus there, and if we have time, I'll come back to other questions.”

Challenge 6: User expects product demo or wants to know "what you're building"

Scenario: User asks “So what's your product?” or “When can I see it?”

Why this happens: User curious, wants to understand "what's in it for me," or thinks this is a sales pitch.

Solution - Defer gracefully:

  • “We're in very early exploration—no product yet. That's why your input is so valuable—we're learning what to build.”
  • “Right now we're purely in learning mode. Once we have something to show, I'd love to come back and get your feedback.”
  • “We're deliberately not showing anything yet because we don't want to bias what you share. Your honest experience is what we need.”

If user insists: Briefly describe problem space (not solution), then redirect: “But I'm here to learn from you, not tell you what we're thinking. Let's focus on your experience.”

Challenge 7: Interviewee is very expert/technical, uses jargon

Scenario: User uses domain-specific terms, acronyms, assumes interviewer has deep expertise.

Why this happens: User genuinely expert, excited to discuss with perceived peer.

Solution - Acknowledge expertise, request clarification:

  • “You clearly have deep expertise here. Help me make sure I understand—when you say [term], what does that mean?”
  • “I want to capture this accurately. Can you explain [acronym/concept] for someone less familiar?”
  • “That's a great technical insight. Can you give me an analogy or example to make sure I've got it?”

Benefit: Asking for clarification often reveals important details expert would otherwise skip (assuming everyone knows).

Sample Sizes by Activity

Interview sample sizes vary by investigation purpose and complexity:

| ActivitySample SizeRationale
A1.2 Need Discovery12-20Saturation across user types; continue until 3-4 consecutive interviews reveal no new need dimensions
A1.3 Root Cause8-12Focused causal hypotheses; fewer needed when exploring specific causes vs. broad discovery
A1.4 Need Exploration6-10 per dimensionDimension-specific (technical, business, etc.); shorter, focused interviews
A6 Concept Validation10-15Spanning user types from A1.2; validate concept-need fit and identify gaps
Interview Sample Sizes by Activity

Saturation principle: Continue interviewing until patterns stabilize—when 3-4 consecutive interviews produce no new insights, likely reached saturation. However, ensure saturation within each user type, not just overall.

Budget vs. rigor trade-off: Minimum 10-12 interviews for any investigation; more is better for confidence but diminishing returns after 20 for most contexts.

Interview Adaptations by Activity

A1.2 Need Discovery Interviews:

Core inquiry focus: Jobs/goals, obstacles, need manifestation, current workarounds

Key questions:

  • “What are you trying to accomplish in [domain]?”
  • “What gets in your way?”
  • “Walk me through last time you experienced [hypothesized need]”
  • “How do you currently handle this?”
  • “What would be different if this obstacle didn't exist?”

Critical principle: NO solution discussion. If user requests features, probe: “What would that enable you to do that you can't today?”

A1.3 Root Cause Exploration Interviews:

Core inquiry focus: Why need exists, underlying causes, causal chains

Key questions:

  • “Why does [validated need] occur?”
  • “What would have to change for this need to no longer exist?”
  • “When does this need NOT occur? What's different in those situations?”
  • Five Whys progression: repeatedly asking “why” to reach root causes

Input required: A1.2 validated need statement—root cause interviews build on established need understanding

A6 Concept Validation Interviews:

Core inquiry focus: Concept comprehension, need-solution fit, usage likelihood

Key questions:

  • “What is this concept trying to do?” (comprehension check)
  • “How well would this address [your need]?”
  • “What works well? What's missing or concerning?”
  • “How would you use this? Walk me through a scenario”
  • “How does this compare to what you do today?”

Input required: A3 concept description/prototype—validation interviews require artifact to react to

Sample Sizes by Activity:

  • A1.2 Need Discovery: 12-20 interviews (saturation across user types)
  • A1.3 Root Cause: 8-12 interviews (focused on specific causal hypotheses)
  • A6 Concept Validation: 10-15 interviews (spanning user types from A1.2)

[Continue with full detailed protocol, examples for each adaptation, common challenges specific to each application...]

Coming soon

Share how you use Need-Focused Interviewing

This is where practitioners will be able to share field notes, variations, and additional templates for this method — what worked, what to watch for, and adaptations for different contexts.

Until the community space opens, we welcome contributions by email and will fold the best into the method page.