Customer Discovery: Build a Problem Model Before You Build

Sales has heard repeated requests for automatic reassignment. Support can point to painful incidents. Product analytics shows people editing assignments again and again.

Everyone agrees that a problem exists. They do not agree on what the problem is.

Perhaps the interface is cumbersome. Perhaps the underlying rules change too often. Perhaps reassignment is a negotiation between several people, not a task for one user. Each explanation leads to a different product.

This is where customer discovery earns its place. Its job is not to collect more requests or manufacture confidence. It is to build a problem model strong enough to change the next decision.

Give customer discovery one narrow job

Customer discovery investigates a present situation before a team commits to a response. It should explain:

• who is involved, including people who do not touch the product;
• what triggers the situation;
• what happens, in what order, and across which tools or hand-offs;
• where the difficulty comes from;
• what people do instead;
• what the consequences and constraints are;
• when the pattern does not hold.

That is narrower than product discovery as a whole. If the uncertainty concerns desirability, usability, feasibility, commercial fit, or impact, build a broader evidence portfolio.

Customer discovery also does not establish market size, prove product-market fit, or validate a proposed feature. It can produce a credible, bounded explanation of how a problem occurs.

It cannot tell you how common that explanation is without further evidence.

This boundary matters. Teams often ask one research effort to prove the problem, size the market, select a solution, and predict adoption. The result is usually an overextended conclusion resting on a few conversations.

Start with the commitment, not the interview guide

Before recruiting anyone, write down the decision that the work will inform. A useful form is:

We are deciding whether this problem, for this group in this situation, deserves this next investment.

Name the investment. It might be another research round, an instrumentation change, opportunity sizing, a concept test, or a decision to stop. “Learn about customers” is not a decision.

If the team cannot state the commitment, work through the nine product discovery questions first. Otherwise, research will accumulate facts without resolving a choice.

Then define the unit of investigation. “How do dispatchers work?” is too broad. “The most recent time a dispatcher had to replace a technician after a same-day cancellation” gives the team an event it can reconstruct.

Set boundaries as well. Specify the customers, circumstances, geography, product state, or time window that the research can reasonably speak about. A precise claim is more useful than a sweeping one with invisible exceptions.

Map the roles around the event

The person operating the interface may not initiate the work, approve it, pay for it, or absorb the consequence when it fails.

For the event under study, identify the likely roles:

• the person who encounters or initiates the situation;
• the operator who performs the work;
• the approver or buyer who controls a constraint;
• the recipient who experiences the outcome;
• the support or operations role that repairs failures.

Do not turn this into a ceremonial stakeholder map. Include a role only when it can change the explanation or the decision.

A manager may call a workflow inefficient while an operator sees a necessary control. A buyer may value auditability while a user values speed.

These are not inconsistent opinions to average. They describe different stakes in the same event.

Recruit for variation and disconfirmation

Customer discovery is not a miniature opinion poll. Its early purpose is to expose mechanisms and meaningful differences, not to estimate prevalence.

Recruit against the decision and the event. The UK Government Service Manual recommends criteria tied to the research question, such as recent experience, the relevant situation, access needs, or the way someone uses a service.

Build a small variation matrix before choosing participants. Useful dimensions may include:

• role in the event;
• successful, failed, delayed, or abandoned outcome;
• current workaround or alternative;
• new, established, former, or prospective relationship;
• operating constraint, access need, or context.

Include negative cases deliberately. Speak to people who appear eligible but do not experience the problem, or who handle the same event without difficulty. They help reveal which conditions are actually doing the work.

There is no universal interview count that makes a claim true. Review sample adequacy as the work proceeds.

A study of interview saturation distinguishes identifying themes from understanding their meaning and variation.

It analysed 25 interviews in one specific health context, so its counts are not a product-research benchmark. Its useful warning is that repetition can precede adequate understanding.

For this discovery decision, expand when evidence remains thin for a material role, boundary, or competing explanation.

Stop when the sample can support the bounded problem model, not merely when interviews feel repetitive.

Record who is missing. Convenient recruitment creates a convenient picture of the world. Current, engaged customers are often easiest to reach and least able to represent people who left, failed to adopt, or chose another route.

Reconstruct a recent episode

General questions produce polished summaries. “How do you normally handle cancellations?” invites a policy answer. “Tell me about the last cancellation you handled” gives the participant something concrete to recover.

The Government Service Manual advises researchers to seek stories and real examples rather than general statements about what people usually do or what should happen.

Follow the episode from trigger to resolution:

1. What first made the person act?
2. What did they do next, and with whom?
3. Which tools, records, messages, or approvals entered the sequence?
4. Where did they pause, repeat work, improvise, or abandon it?
5. What consequence followed, and who noticed it?
6. How was the situation resolved, if it was resolved at all?

When appropriate and with consent, ask to see the artefacts involved: a spreadsheet, message thread, ticket, calendar, form, or handwritten note. Artefacts can expose dependencies that a fluent retelling leaves out.

The craft still matters. Neutral prompts, patient follow-ups, and careful handling of consent are covered in these interview design principles.

Treat every account as situated evidence. Memory is incomplete, people rationalise, and an observed episode does not represent a population. The answer is not cynicism. It is a clearer record of what each piece of evidence can support.

Combine evidence without forcing a vote

Different evidence streams answer different questions. They should meet in the analysis, but they are not interchangeable.

• Interviews and observation can explain sequence, meaning, constraints, and workarounds.
• Product telemetry can show instrumented behaviour and variation at scale, but not the reason behind it.
• Support and operations records expose breakdowns, while over-representing people who report or escalate them.
• Sales and commercial evidence reveals buying language and constraints, not necessarily everyday use.
• Existing policies and service records show the intended system, which may differ from practice.

Do not settle disagreement by counting sources as votes. Three support tickets and one behavioural pattern do not become “four pieces of proof”. Ask whether they describe the same event, role, segment, and mechanism.

Maintain an evidence ledger with five fields: claim, supporting observation, counterevidence, boundary, and next evidence. This keeps a vivid quotation from quietly turning into a universal truth.

Preserve competing explanations

Suppose telemetry shows several edits before an assignment is saved. That observation has multiple plausible explanations:

• the interface makes a simple change difficult;
• several people negotiate the assignment;
• eligibility data is missing;
• policy requires an approval sequence;
• the instrumentation records one action more than once.

A weak synthesis chooses the explanation the team already prefers. A stronger one names the alternatives and looks for observations that could distinguish them.

Keep observation, interpretation, and action separate. The Government Service Manual’s analysis guidance follows the same sequence: capture what was seen or heard, identify findings, then decide what to do.

Contradictions are often the most valuable result. If one group experiences urgent failure and another handles the event easily, the useful move may be to narrow the segment rather than produce an average customer.

End with a disposition

Discovery should finish with a decision about the problem, not a deck of themes. There are only a few honest dispositions:

• Narrow it. The problem is real under more specific conditions than expected.
• Reframe it. The observed mechanism differs from the initial explanation.
• Size it. The mechanism is credible, but its prevalence and value remain unknown. Move to opportunity sizing.
• Explore responses. The problem is coherent enough to compare possible responses, then test a concrete one through concept validation.
• Investigate a conflict. Competing explanations still imply materially different decisions.
• Stop. The consequence is weak, the existing alternative is adequate, or the problem sits outside the strategy.

“Customers mentioned it” is not a disposition. Neither is “more research”. State what changed, what remains uncertain, and why the next investment follows.

A worked example: the requested AI scheduler

The following case is fictional. It shows the reasoning, not a claim about a real company.

A field-service product team hears requests for “AI scheduling”. Sales sees an attractive differentiator. Support has tickets about urgent reassignments. Telemetry shows repeated edits to jobs after a technician cancels.

The team’s decision is whether last-minute reassignment deserves solution discovery. It studies recent cancellation episodes rather than reactions to an AI concept.

Participants include dispatchers, technicians, service managers, and an operations administrator. The team also recruits organisations that recover from cancellations without visible difficulty.

The episodes reveal that finding an open calendar slot is rarely the hardest part. Dispatchers must verify certification, travel range, technician acceptance, customer access, and responsibility for the change.

In failed cases, one of those conditions remains in a private message or a separate system. In negative cases, stable teams have shared context and can resolve the same event through a short call.

The problem model becomes more precise: during an urgent exception, the team cannot hand off a job with verified eligibility and accountable acceptance across roles.

That model does not prove demand for an AI scheduler. It suggests two better next steps: estimate how often the bounded situation occurs, and test whether a controlled hand-off improves it.

The original feature request has become a testable decision.

Write the problem-evidence brief

The final artefact can be short. Its purpose is to preserve the reasoning well enough for another person to challenge it.

Include:

• Decision: the commitment this work informs.
• Episode: the bounded event investigated.
• Roles: who acts, decides, pays, receives, or repairs.
• Problem model: trigger, sequence, mechanism, consequence, and current alternative.
• Evidence: observations by source, with counterevidence beside them.
• Variation: where the pattern changes and which cases are missing.
• Limits: what this work cannot establish.
• Disposition: narrow, reframe, size, explore responses, investigate, or stop.
• Next evidence: the smallest evidence that could change that disposition.

A useful brief makes uncertainty visible without becoming vague. It gives the team something more demanding than empathy and more honest than certainty.

Customer discovery earns its cost when it makes a plausible problem smaller, stranger, or less valuable than the organisation hoped. A problem model can disappoint the roadmap before delivery does.

Sources

• User research in the discovery phase, UK Government Service Manual
• Using in-depth interviews, UK Government Service Manual
• Finding participants for user research, UK Government Service Manual
• Analyse a research session, UK Government Service Manual
• Code Saturation Versus Meaning Saturation: How Many Interviews Are Enough?, Qualitative Health Research

Read next

• Product Discovery Techniques: Build an Evidence Portfolio

• Research-Driven Opportunity Sizing

• B2B Product Discovery When Buyers and Users Disagree