Teams often choose customer research by naming a method: “Let’s run interviews,” “We need a survey,” or “Can we test the prototype?” That jumps over the harder question. Which decision is currently blocked, and what uncertainty prevents the team from making it responsibly?
A focused study begins with that decision. The method follows.
GOV.UK's discovery guidance starts with understanding the problem, users and context before committing to a solution discovery guidance.
The method still needs to match the uncertainty. Nielsen Norman Group maps research methods by the kinds of questions they answer, the context of use, and the product-development stage research-method framework.
Start with a decision statement
Use this sentence:
We need to decide [decision] for [audience or situation], but we do not yet understand [uncertainty].
For example: “We need to decide which onboarding handoff to improve for first-time workspace administrators, but we do not yet understand where confidence breaks during their first invitation flow.”
This is more useful than “We need onboarding feedback.” It identifies the audience, the moment, the decision, and the knowledge gap. It also creates a boundary: a study about first invitations should not silently become a general review of every setup feature.
Match the study to the evidence you need
| If you need to learn | Start with | Listen for |
|---|---|---|
| Why people struggle with a workflow | Problem discovery | Sequence, workarounds, constraints |
| How customers describe value | Value and messaging | Language, proof, alternatives |
| Why adoption stalls | Adoption diagnosis | First-use moments, handoffs, missing confidence |
| Which concept deserves a test | Concept exploration | Expected outcomes, objections, decision criteria |
These are starting shapes, not rigid product labels. A study can combine elements, but it should still have one primary learning job. If every stakeholder adds a different goal, the study becomes broad while the eventual decision stays unclear.
Work through a concrete selection
Suppose a B2B product team sees a drop between account creation and the first invited teammate. Three explanations are circulating:
- administrators do not understand why inviting someone matters;
- they worry about permissions before adding colleagues;
- they intend to invite later but lose momentum.
The decision is not yet “Which new onboarding screen should we build?” The first decision may be “Which mechanism deserves a focused product test?” A problem-discovery study with recent administrators is a better starting point than showing three polished concepts immediately.
The interview should reconstruct the latest setup attempt: what triggered it, who was involved, what the administrator expected, when the invitation decision appeared, what they checked, and what they did next. If the study instead begins with a proposed permissions explainer, the team risks measuring reactions to its own idea before understanding the original hesitation.
After the mechanism is clearer, a concept study can compare whether a proposed change improves comprehension or confidence. The two studies answer different questions; combining them too early can make supportive concept feedback look like proof of the underlying diagnosis.
Write one learning goal
A useful goal names the audience, situation and decision. For example: “Understand how first-time team leads prepare customer updates so we can decide which handoff to improve first.”
Pressure-test the goal with four questions:
- Audience: Is the group specific enough that their context is comparable?
- Situation: Does the goal point to a real moment or process?
- Uncertainty: Can the team name what it genuinely does not know?
- Decision: If the study succeeds, what choice becomes easier?
If the final answer is “We will know our customers better,” the goal is still too broad.
Keep the first study narrow
- Focus on one meaningful audience.
- Ask about one recent process or decision.
- Decide in advance what evidence would change your mind.
- Leave room for an unexpected explanation.
Narrow does not mean asking only one question. It means every question contributes to the same decision. You can explore triggers, sequence, alternatives, constraints, evidence, and consequences while staying inside one learning boundary.
Decide what could change your mind
Before recruiting, write down the team’s current explanations and the evidence that would weaken each one. This reduces the temptation to treat every comment as confirmation.
For the invitation example:
| Current explanation | Evidence that would weaken it |
|---|---|
| People do not see the value | Participants clearly describe the collaboration benefit but postpone for another reason |
| Permissions create fear | Participants understand permissions and show no concern at the decision point |
| The task is forgotten | Participants deliberately defer because another stakeholder must approve access |
This is not a statistical hypothesis test. It is a discipline for making assumptions visible and noticing disconfirming evidence.
Choose participants from the decision context
Recruit people who have encountered the situation you need to understand. A convenient customer who has never invited a teammate cannot reconstruct that handoff. Likewise, an expert administrator may have built routines that hide the difficulties faced by a first-time administrator.
Write eligibility around observable experience:
- completed or attempted the relevant process recently;
- held the role involved in the decision;
- encountered the trigger or constraint under study;
- can discuss the event without exposing prohibited confidential information.
Avoid recruiting only people who already love the product. Their experience may be valuable, but it cannot stand in for the range implied by the learning goal.
Know when not to run interviews
Interviews are useful for reconstructing context, behaviour, meaning, workarounds, and decision criteria. They are not the only source of evidence.
- If you need to know where a measurable funnel drop occurs, start with reliable behavioural data.
- If you need to verify whether a specific interface can be completed, use an appropriate usability evaluation.
- If the decision depends on prevalence across a defined population, pair qualitative learning with a measurement approach suited to that claim.
- If the team already understands the mechanism and needs to compare implementation performance, move to the relevant product test.
The choice is not “qualitative or quantitative” as a matter of identity. It is which evidence reduces the present uncertainty.
Use a one-page study brief
Before fieldwork, record:
- Decision to improve
- Primary learning goal
- Audience and eligibility
- Situation or recent event
- Current explanations
- Evidence that could change the team’s mind
- Interview themes or other method
- Excluded questions
- Planned synthesis and decision meeting
The excluded-questions section matters. It gives the team a respectful place to park useful topics that do not belong in this study.
Finish with a decision, not a deck
Plan how the team will use the evidence before the first session. A completed study should make the original decision clearer, reveal that the decision was framed incorrectly, or show which uncertainty requires another method. “We produced a presentation” is an output, not the research outcome.
Strong questions still matter after the research type is chosen. See How to ask customer interview questions that move beyond surface answers.
