Customer Interviews for Product Discovery: From Questions to Decisions

A useful customer interview starts with a Product decision, not a list of questions. The interview is one method for reducing uncertainty by understanding real behavior, context, workarounds, constraints, consequences, and meaning.

Use this workflow:

Learn → Prepare → Run → Synthesize → Decide

For each research round, work in this order:

Decision → Unknown → Method fit → Participant → Evidence needed → Interview → Synthesis → Product decision

The interview itself is only the middle. A strong round can end with a better problem definition, a segment distinction, another evidence source, a concept or usability test, a prioritization decision, or no action. It does not need to justify a feature to be valuable.

If you already know the research decision and need a usable discussion guide, use the User Interview Script Generator. If you need exact question patterns and probes, use Customer Interview Questions That Reveal Real Behavior.

If your interview is next week, jump straight to the runnable aids: copy the phase-organized interview script, keep the facilitation checklist open during the session, capture with the needs-and-frustrations template, and close with the evidence-to-decision log. Each script block states which unknown it resolves, so you can drop any phase that does not serve your blocked decision.

A five-phase workflow

Each phase has an input, a job, an output, a predictable failure mode, and a next decision.

This is iterative, not a ceremony. If synthesis exposes the wrong participant group or a different unknown, return to Prepare. If the remaining uncertainty is better answered another way, switch methods instead of scheduling more conversations.

How to use this page without reading all of it: confirm method fit in §1 Learn, fill the interview plan and the participant check in §2 Prepare, then run the script bank with the facilitation checklist. Capture each session with the needs-and-frustrations template before you synthesize across interviews. The decision log at the end is the definition of done.

1. Learn: are interviews the right method?

Before recruiting anyone, ask:

Can an interview actually answer the uncertainty that blocks this Product decision?

Interviews are especially useful for understanding workflow, context, remembered experience, workarounds, motivations, constraints, switching or buying processes, and the meaning people attach to events. They can materially change confidence about a mechanism or problem framing.

They are weaker as the sole evidence for questions that require population estimates, precise causal effects, exact conversion prediction, or large-scale usability performance.

Interviews are evidence. They are not a magic transformation from “several positive conversations” to statistically validated market demand.

Past or current behavior is often more grounded than unsupported future prediction, but it is not perfect truth either. Interviews still depend on memory, reconstruction, interpretation, and social context. When stakes justify it, compare recall with artifacts, direct observation, usage data, logs, or another source. See Research Triangulation for the specialist workflow.

Plan the interview before writing questions

Complete this before writing interview questions. The goal is to make the research logic clear and easy to challenge.

# Customer Interview Plan

Product decision:
[What choice must this research inform?]

Current evidence:
[What do we already know, and from which source?]

Unknown:
[What specifically remains uncertain and blocks the decision?]

Method fit:
[Why can interviews reduce this uncertainty? What can they NOT establish?]

Participant experience:
[Who has firsthand experience relevant to the unknown?]

Evidence needed:
[What real event, workflow, workaround, consequence, artifact, or decision story would change our understanding?]

Contradicting evidence:
[What observation would make us less confident in the current hypothesis?]

Decision after research:
[What plausible choices could follow: act, reframe, prioritize, test, gather another method, or stop?]

A weak plan says, “We want to learn about collaboration.” A stronger plan exposes the uncertainty: “Teams create a workspace but activation falls before the second collaborator joins; we do not yet know which multi-user setup step creates consequential friction, for whom, or why.”

2. Prepare: define the decision, unknown, participant, and evidence needed

Decision: what choice is currently blocked?

Do not begin with “What do we want to learn?” Begin with:

What Product decision are we unable to make confidently?

Examples:

• Which onboarding problem deserves deeper investigation?
• Is a manual approval workflow consequential enough to address?
• Does one customer segment face a materially different workflow?
• Are we ready to move from problem discovery into solution exploration?

A decision gives the research a stopping point. Without it, the team can collect interesting material indefinitely without knowing what evidence would be enough.

Unknown: write the uncertainty, not the conclusion

Weak:

Users struggle with collaboration.

Stronger:

Activation falls after workspace creation, but we do not yet know which part of multi-user setup creates the most consequential friction, whether that friction differs by administrator context, or what people do when setup stalls.

The second version keeps the unknown visible instead of hiding a hypothesis inside a statement of fact.

Participant: recruit for relevant experience, not a convenient title

The participant should have direct exposure to the situation that can answer the unknown. Relevant criteria may include:

• experience: have they actually encountered the workflow or decision?
• recency: when did it happen, if memory/context matters?
• frequency: how often do they encounter the situation?
• context: company type, workflow maturity, device, constraints, or segment if materially relevant;
• role in the system: user, admin, buyer, approver, manager, champion, procurement, security, or another actor.

Check participant fit

Before scheduling, ask:

1. Has this person actually experienced the situation we need to understand?
2. How recently and in what context?
3. Are they directly involved in the relevant workflow or decision?
4. Are they the user, buyer, administrator, approver, influencer, or economic decision maker?
5. Could that role difference materially change the answer?

In B2B, one person rarely represents the whole buying and usage system. Do not interview only executives to reconstruct daily workflow friction. Do not interview only end users to answer procurement or security constraints.

For deeper reasoning about how many interviews to add, participant heterogeneity, and practical saturation, use How Many Customer Interviews Are Enough?. This page deliberately does not prescribe a universal interview count.

Evidence needed: define what would change understanding

Useful evidence targets include:

• a recent workflow reconstructed step by step;
• an actual workaround and why it exists;
• a switching or purchase event and what triggered it;
• a failed attempt and its consequence;
• an artifact that shows how work is really done;
• an example that contradicts the current hypothesis.

A useful research plan also states what would make the team less confident, not only what would confirm the current view.

Traceability check before you write questions. For each block you plan to ask, write one line: blocked decision → unknown → evidence needed → script block. If a block does not resolve the unknown above, cut it or move it to closing. The script bank below already labels each phase this way, delete any phase that does not serve your unknown rather than asking everything.

Build the discussion guide after the research design

The sequence is:

Decision → Unknown → Participant → Evidence needed → Question / probe

Not:

Find 20 good questions → interview whoever is available → hope a pattern appears.

A customer discovery guide often benefits from:

1. Introduction and context, explain the topic and how the conversation will be used.
2. Recent real experience, reconstruct a specific event.
3. Workflow, steps, triggers, people, tools, dependencies, and constraints.
4. Breakdowns and workarounds, where reality diverged from the intended path.
5. Consequences, what changed because of the problem.
6. Decision behavior, alternatives, approvals, selection, switching, or postponement when relevant.
7. Contradictions / exceptions, situations where the emerging story does not hold.
8. Closing, clarify what was missed and any follow-up.

The guide is scaffolding, not a checklist. The Interview Script Generator creates an editable research instrument once the goal is clear. It does not create evidence or findings.

For pattern-level wording repairs across twelve common failures, use the dedicated Customer Interview Questions guide. The bank below is the runnable minimum for this workflow: each phase states which unknown it resolves, what to ask verbatim, which probes earn their way in, and what to avoid.

Phase-organized interview script bank: copy and run

Default timing is 30 minutes. Read the opening verbatim; treat the rest as conditional branches. If a story already answered a probe, skip it. If you only have 20 minutes, cut Phase 3 first unless your unknown is explicitly about buying or switching.

Phase 0, Opening and permission (3–5 min). Resolves: participant context and consent.

"Thanks for making time. I am researching how [role, e.g. workspace admins] handle [concrete situation, e.g. setting up users and permissions] so we can decide [blocked decision in plain language, e.g. which setup friction to fix first]. This is not a pitch and not a test, I want to understand how the work actually happens. May I record so I can quote you accurately, and are there topics or screens you would rather keep off the record?"

Then establish relevance in one question: "What part did you personally play the last time [situation] happened?" If they observed rather than did it, note the role gap and weight their reconstruction accordingly.

Phase 1, Incident reconstruction (10–12 min). Resolves: trigger → steps → actors → breakdown → workaround → consequence.

Opening:

"Tell me about the last time you [concrete situation]. Start from when you decided to do it."

Use only the probes the story still leaves open:

• When did this last happen, and what triggered it?
• What happened first? What happened next?
• Who else was involved at that point?
• What tool, document, message, or process did you use?
• Where did the workflow change, stall, or break?
• What did you do instead?
• What consequence followed, rework, delay, escalation, cost, or risk?

Transitions that keep the story moving without steering:

• "Say more about that moment."
• "What was happening just before that?"
• "Walk me through what you did when that happened."

Avoid here: "Would you use X?", "Was this frustrating?", "Which feature matters most?", "Would you pay for a fix?" Each smuggles the team's framing into the answer. Stay inside the event first; save evaluation for Phase 4.

Phase 2, Needs-and-frustrations probes (8–10 min). Resolves: unmet need, workaround cost, and severity versus mere annoyance.

Ask only the two or three that fit the reconstructed incident:

• "What part took more effort than it should have?"
• "What did you try when the normal path did not work, and why that workaround?"
• "What did that workaround cost you: time, rework, delay, escalation, money, or risk?"
• "What have you stopped trying to do because of this?"
• "Who else was affected when this happened?"

When they use a pain word ("annoying", "manual", "confusing"), do not record the adjective as the finding. Ask: "What happened, what did you do, and what changed because of it?" The capture template forces this separation.

Phase 3, Decision, alternatives, and constraints (5 min; skip unless buying or switching is the unknown). Resolves: serious alternatives, decision actors, and the constraint that changed the choice.

Opening:

"Tell me about the last time your team evaluated or changed [solution] for this workflow, from when you started considering a change."

Conditional probes only:

• Which alternatives were serious, and when did one rise or fall?
• Who else was involved, and what constraint changed the decision?
• Was there a moment the decision almost went another way?

Boundary: this exposes remembered evaluation mechanics. It does not establish the share of buyers who rank an attribute first, nor prove a shipped integration will lift close rates.

Phase 4, Contradiction and exception (3 min). Resolves: boundary conditions and segment differences.

• "Can you think of a recent case where this worked smoothly or differently?"
• "When does this not happen?"
• "What would make your example atypical for others in your role?"

A contradiction is synthesis material, not noise. Carry it into the capture template and the synthesis matrix rather than probing it away.

Phase 5, Closing (2 min). Resolves: missed evidence and follow-up permission.

• "What did I miss that matters for [situation]?"
• "Is there a message, doc, screen, or handoff you could safely share that would help me understand the sequence?" Do not push if sharing could expose confidential, personal, or regulated material.
• "May I follow up with one clarification question if synthesis surfaces a gap?"

Several similar stories can make a mechanism worth investigating. They still do not establish prevalence across all users or prove that a proposed fix will causally improve the outcome.

Behavior-first questions: reconstruct the incident

A useful default is to reconstruct one concrete event before asking for generalization. Phase 1 of the script bank is how you run this; the table below is why each rewrite produces better evidence.

Then reconstruct the incident:

• When did this last happen?
• What triggered it?
• What happened first?
• What happened next?
• Who was involved?
• What tool, document, or process did you use?
• Where did the workflow change or break?
• What did you do instead?
• What consequence followed?

When appropriate and safe, “Can you show me how you do it?” can turn a vague description into concrete evidence: a workflow, spreadsheet, document, dashboard, email pattern, or tool configuration. Do not encourage participants to reveal confidential, personal, or otherwise sensitive material they are not permitted to share.

Problem interview vs concept research vs usability test

These methods can be combined deliberately, but do not collapse their evidence into one category.

• Problem discovery interview: understand the current world, behavior, context, constraints, and consequences.
• Concept research: expose a proposed concept to understand comprehension, reaction, trade-offs, or fit with existing behavior.
• Usability test: observe whether a participant can complete relevant tasks with an interface or prototype.

A positive reaction to a concept does not retroactively establish that the underlying problem is severe or prevalent. Likewise, a sales conversation can surface useful evidence, but a pitch followed by “Would you buy?” is not the same research job as discovery.

3. Run: follow the story without steering it

The participant's real story is the work. Use the discussion guide to stay aligned with the research goal while following decision-relevant detail.

Good facilitation behaviors include:

• probe concrete moments rather than completing the participant's answer;
• clarify ambiguous language using the participant's words where possible;
• tolerate short silences instead of filling them;
• follow unexpected evidence when it could change the Product decision;
• keep the session comparable enough that cross-interview synthesis remains possible;
• separate problem discovery from solution pitching unless concept research is an explicit objective.

Facilitation checklist: follow the story without steering

Keep this open during the session. The left column is the move; the right column is what it sounds like.

Three lines cover most steering risk: "Say more about that moment." / "What happened next?" / "What did you try when the normal path did not work?" If you catch yourself about to ask a "Would you…?" or "Is this important?" question, convert it into a reconstruction request: "Tell me about the last time that mattered."

Leading questions are only one source of bias

Neutral wording reduces an avoidable source of distortion, but it does not eliminate researcher bias. Bias can also enter through:

• recruiting only enthusiastic customers or obvious detractors;
• probing positive stories more deeply than contradictory ones;
• dismissing disconfirming cases as “edge cases” without examining context;
• selective note-taking;
• cherry-picking memorable quotes;
• creating synthesis categories around the team's existing hypothesis;
• stopping the round as soon as the desired answer appears.

A useful question is:

What evidence would make us less confident?

A contradiction is not automatically noise. It may expose a segment, role, maturity, workflow, environmental, or support difference that the original model missed.

Recording, consent, and sensitive research

If you record a session, be explicit about what is being recorded, why, who can access it, how it will be stored, and how long it will be retained according to the policies and requirements that apply to your situation.

Recording, consent, privacy, data handling, and retention requirements vary by jurisdiction, organization, participant relationship, and research context. Do not rely on a universal script as legal advice. Research involving sensitive health, financial, employment, minors, or similarly sensitive contexts can require additional internal policy, legal, privacy, or ethics review.

4. Capture: keep evidence separate from conclusions

Use a lightweight structure that keeps the source and context visible.

Three rules prevent a large share of weak synthesis:

Quote ≠ finding

A quote is one piece of participant evidence. It becomes useful for a decision only when you preserve context and examine the behavior/mechanism, other observations, contradictions, and why it matters.

Request ≠ problem

Participant:

“We need CSV export.”

Weak synthesis:

Customers need CSV export.

Stronger research asks: What job requires the export? What happens after export? Which current system fails? What consequence follows? Is export the desired outcome, a workaround, or one plausible solution?

Pain word ≠ severity

“It's annoying” does not establish frequency, consequence, economic cost, risk, or strategic relevance. Probe what happened, what they did, and what changed because the problem existed.

Needs-and-frustrations capture template (copy-ready)

Fill one copy per interview, within a day, before you compare across sessions. It keeps evidence separate from conclusions and feeds the synthesis matrix and the decision log below.

# Needs & frustrations, P[ ] / [date] / [role + context]

Situation + trigger:
[What event did we reconstruct? When, and what started it?]

Steps observed:
[1. … 2. … 3. …, concrete actions, actors, tools, handoffs]

Workaround:
[What did they do when the normal path failed? Why that workaround?]

Need (inference, label it as such):
[The underlying job they were trying to get done.]

Frustration + consequence:
[What broke, and what did it cost: time, rework, delay, escalation, money, risk?]

Evidence strength:
[Directly observed / reconstructed story / vague recall + artifact available? Y/N]

Contradiction / exception:
[What did not fit the emerging pattern? Which context might explain it?]

Open question:
[What remains unknown or needs another source/session?]

Source:
[Session reference or timestamp for traceability.]

Short hypothetical illustration (invented to show the standard, not a research finding): Situation, P2, finance operations admin, invited users then hit an approval rule. Workaround, removed and re-added users after checking with a manager. Consequence, one-week rollout delay plus rework. Need (inference), a way to see approval constraints before inviting. Contradiction, P4 with implementation support skipped the friction entirely, suggesting support context matters.

Turn contradictions into synthesis instead of averaging them away. For each contradiction: (1) preserve the verbatim observation with its full context; (2) test a segment, role, maturity, workflow, or support explanation before discarding it; (3) carry the survivor into the cross-interview synthesis matrix above as a boundary condition, and if it still challenges the pattern, record it as an unresolved unknown in the evidence-to-decision log rather than letting frequency voting bury it.

If you have several sessions, the Insight Clustering Helper can help organize observations. Feed it observations and context rather than conclusions that have already stripped away where the evidence came from.

5. Synthesize: preserve mechanism, context, and contradiction

Use this sequence:

individual observations → recurring mechanisms → contradictions → context / segment differences → candidate problems → assumptions → decision implications

Observation → pattern

Do not cluster two statements merely because the wording is similar. Ask whether the underlying behavior or mechanism is actually the same.

Two people might both describe a process as “manual.” One may mean time-consuming data entry. Another may mean cross-team approval coordination. Same word; different problem.

Pattern → candidate problem

A recurring pattern is not automatically a problem statement. Before framing a candidate problem, preserve:

• affected user and context;
• observed behavior/workflow;
• consequence;
• supporting evidence;
• contradiction or boundary conditions;
• unresolved uncertainty.

Once these are clear enough, the Problem Statement Generator can help turn the evidence into a concise Product problem statement.

Frequency ≠ priority

A frequent annoyance may be low consequence. A rarer failure may be expensive, risky, or strategically important. Interview frequency informs a prioritization decision; it does not replace one.

When several credible problems compete, use Prioritization to compare user impact, consequence, strategic relevance, evidence confidence, risk, effort, and opportunity cost rather than allowing mention counts to become the roadmap.

Cross-interview synthesis matrix

Use a small comparison matrix before creating abstract themes:

| Participant / context | Trigger | Workflow | Workaround | Consequence | Contradiction / exception | Open question |
|---|---|---|---|---|---|---|
| P1 / ... | ... | ... | ... | ... | ... | ... |
| P2 / ... | ... | ... | ... | ... | ... | ... |

The matrix is useful only if it preserves enough context to explain differences. It is not a scoring system.

Keep five labels visible

• Evidence: what was observed or reported, with source/context.
• Inference: what you think the evidence may mean.
• Assumption: what remains unverified.
• Unknown: explicit unresolved information that matters to the decision.
• Decision: the Product choice made using evidence plus strategy, constraints, risk, and judgment.

An AI transcript summary can compress what was said. It does not automatically perform this synthesis. AI can help organize candidate themes or surface possible contradictions, but the team still needs provenance and decision reasoning. For the specialist AI workflow and its risks, see Customer Interviews With AI.

Turn interview evidence into a Product decision

Use this after a round to prevent raw observations from silently becoming requirements.

# Interview Evidence → Product Decision

Product decision:
[What choice are we trying to make?]

Evidence:
[What was observed? Keep source/provenance.]

Context:
[Where, for whom, under what trigger or constraint?]

Pattern / mechanism:
[What appears to recur, and why do we believe it is the same underlying mechanism?]

Contradictions:
[Which observations do not fit? Is there a segment/context explanation?]

Inference:
[What might explain the evidence?]

Assumption:
[What remains unproven?]

Unknown:
[What unresolved uncertainty still matters to the decision?]

Decision implication:
[What could this evidence change?]

Needed next evidence:
[What would materially reduce the remaining uncertainty?]

Decision:
[Act, reframe, prioritize, test, gather another method, or stop.]

6. Decide: define the evidence threshold before declaring victory

Ask:

What evidence would be enough to change the Product decision?

There is no universal interview count or confidence score. The threshold depends on the decision, uncertainty, participant variation, consequences of being wrong, reversibility, and what other evidence exists.

Examples:

• Problem-framing decision: enough contextual evidence to redefine the affected user, workflow, consequence, or problem boundary.
• Segment decision: stronger evidence that workflows or constraints differ in a way that materially changes the Product choice.
• Build/investment decision: interviews may clarify mechanism and value, but the decision may also require behavioral, technical, economic, market, or experimental evidence.

Research may legitimately end in no action because the consequence is weak, the opportunity is too small, the current workaround is adequate, another opportunity matters more, or uncertainty remains too high for the cost of action.

Research may also lead to another research step. Before scheduling more interviews, ask:

Will another interview plausibly change the decision?

If the answer is no, stop interviewing or switch methods. More transcripts are not automatically more confidence.

When interviews should hand off to another method

Use Research Triangulation when the decision needs multiple evidence sources. Do not flatten interviews, analytics, surveys, observation, and experiments into one artificial confidence score: they answer different questions and carry different limitations.

Worked example: B2B workspace onboarding research

Hypothetical example, the observations below are invented to demonstrate the method, not presented as CraftUp research findings.

Decision

Which onboarding friction deserves deeper Product investment before the team chooses a solution?

Known evidence

Activation data shows a meaningful drop between workspace creation and the first successful multi-user setup. That signal identifies where a problem may exist, not why it occurs.

Unknown

Which part of multi-user setup creates consequential friction for new workspace administrators, in which contexts, and what do they do when setup stalls?

Method fit

Interviews fit because the team needs to reconstruct workflow, roles, coordination, workarounds, and consequences. Interviews alone will not estimate the market-wide prevalence of each mechanism or prove a proposed feature would improve activation.

Participants

Recruit recent workspace administrators who personally set up users/permissions. Do not substitute executives who only approved the purchase if the unknown is daily setup workflow.

Evidence needed

Recent setup stories showing trigger → steps → actors → breakdown → workaround → consequence, plus at least one case where setup worked smoothly enough to challenge the emerging explanation.

Hypothetical observations with traceability

Observation A, P1, small IT team
P1 described pausing setup to ask a colleague which permission level external contractors should receive. They kept a separate spreadsheet of people and access decisions until the configuration was complete.

Observation B, P2, finance operations
P2 invited users first, then discovered that approval policy required a different access structure. They removed and re-added several users after checking with a manager. The consequence was rework and a delayed internal rollout.

Observation C, P3, operations lead
P3 said “inviting people is manual,” but reconstruction showed the time was mostly spent collecting approval from two stakeholders, not typing email addresses. The word “manual” described a different mechanism from simple data entry.

Contradicting observation D, P4, enterprise administrator
P4 completed the same setup without notable friction because an implementation specialist had already mapped roles and permissions with the team before the administrator opened the product.

Pattern

Several observations point toward uncertainty about role/permission decisions and coordination, not simply the mechanics of entering invites. The contradiction suggests support/context may materially change the workflow.

Inference

The activation drop may be partly associated with administrators lacking a clear model of who should receive which access, especially when approvals are distributed across people.

Assumption

The permission/coordination mechanism is not yet proven to be the dominant cause of the activation drop. The interviews also do not establish how common it is across all new workspaces.

Product decision

Do not jump to “build bulk invites” or “add CSV import.” First investigate the permission/configuration workflow and its relationship to activation before selecting a solution.

Next evidence

Segment activation and setup events by relevant account/context signals where possible, inspect support/onboarding records, and observe a small number of admins completing setup. If the mechanism still appears important, move into solution exploration and usability testing.

This is the standard to aim for: each synthesis statement can be traced back to an observation, and a contradiction changes the model instead of being discarded.

Research anti-patterns and corrections

Where to go next

• Need exact questions or probes? → Customer Interview Questions.
• Know the decision and need an editable guide? → Interview Script Generator.
• Unsure how many more interviews to run? → Sample Size & Saturation.
• Need to reconstruct switching/progress forces? → JTBD Interview Questions.
• Need stronger mixed evidence? → Research Triangulation.
• Need help organizing multiple observations? → Insight Clustering Helper.
• Have credible evidence and need problem framing? → Problem Statement Generator.
• Have several credible opportunities and need to choose? → Prioritization.

A compact end-to-end customer interview workflow

Learn

Decide whether interviews fit the uncertainty. Be explicit about what they can and cannot establish.

Prepare

Write Decision → Unknown → Participant → Evidence needed, identify contradicting evidence, then create the discussion guide.

Run

Reconstruct concrete experiences, probe for mechanism and consequence, preserve surprise, and avoid steering the participant toward the team's preferred answer.

Synthesize

Keep observations traceable. Compare recurring mechanisms, contradictions, context differences, inferences, assumptions, and unknowns.

Decide

State what the evidence changed. Frame a problem, prioritize an opportunity, switch method, test a solution, gather more evidence only when it can change the decision, or stop.

Continue learning and practicing Product Discovery

The methodology on this page stands on its own. If your gap is broader Product Discovery capability, the Product Discovery course covers discovery methods, recruiting and sampling, the insight pipeline, opportunity mapping, assumptions, and moving from insight to bets.

For direct learning around interviewing, use the Master Customer Interviews module. For deliberate PM decision practice, use Product Management Exercises. If you are deciding what to learn next rather than solving a live research problem, use the Product Management Learning Path.

Research-method references

The workflow above is CraftUp's practical synthesis of established qualitative research practices. For methodological depth, see:

• Nielsen Norman Group: Interviewing Users, interview strengths, limitations, critical incidents, and method triangulation.
• Nielsen Norman Group: Avoid Leading Questions, how wording can alter participant responses and behavior.
• Nielsen Norman Group: Writing an Effective Guide for a UX Interview, research questions before interview questions and flexible semistructured guides.
• GOV.UK Service Manual: Using in-depth interviews, planning, participant recruitment, discussion guides, open neutral questions, and real examples.

The key test is not whether the team “completed interviews.” It is whether the research reduced an important uncertainty without pretending the evidence proves more than it does.