Discover Customer Problems Through Real Work Episodes

The method, in brief

Which observed problem deserves further investigation?

Investigate recent work rather than asking customers to endorse a proposed solution. Compare episodes, workarounds, consequences and negative cases before choosing the next problem hypothesis.

Why this framework matters

Discovery should explain what happens in the work and preserve the evidence that could contradict the team's preferred story.

Investigate recent work rather than asking customers to endorse a proposed solution. Compare episodes, workarounds, consequences and negative cases before choosing the next problem hypothesis.

Audience and decision

For founders, researchers, product leads and operational improvement teams deciding whether a recurring problem deserves further investigation. The output is a bounded problem statement and a justified next step: investigate, test an intervention, narrow the segment or stop. It is not a survey claiming to represent an entire industry.

Use this when a team says “customers need AI” but cannot name the last occasion on which a customer struggled. The unit of analysis is a recent work episode, such as reconciling a supplier delivery, preparing a quote or handling an exception. Episodes expose triggers, actions, constraints and consequences more reliably than abstract preference questions alone.

Research and source ledger

Accessed 16 September 2026.

These are established methods, primarily practical guidance. dotSuper's episode record, contradiction register and stopping decisions are original synthesis. No source establishes that this protocol yields complete needs discovery in Gulf manufacturing.

Existing approaches and limitations

Personas can organise what a team already knows, but an imagined persona is not evidence. Surveys can estimate prevalence when sampling and questions are sound, but early surveys often ask respondents to agree with a problem the sponsor has already chosen. Unstructured conversations reveal unexpected issues but can leave the team remembering only vivid anecdotes. Solution demonstrations can elicit useful usability feedback while contaminating a discovery interview with the proposed answer.

The proposed protocol combines a consistent episode structure with room for surprises. It keeps an explicit place for customers who manage the issue well or do not experience it. A competitor's existence is a signal worth investigating, not proof that the same need or budget exists in the selected customer group.

Structure and rationale

Create one episode record for each concrete occurrence, one cross-episode comparison and one decision memo. Each record follows trigger, intended result, actual sequence, obstacle, workaround, consequence and evidence. Separate quotations, observations and researcher interpretation. Link each interpretation back to a record ID.

The comparison examines recurrence, variation and contradictory cases. Do not collapse different jobs into a single “efficiency problem.” A purchasing delay caused by an absent approver requires a different response from a delay caused by unclear specifications, even if both appear in the same departmental KPI.

Inputs and recruitment

Prepare a list of role and context differences likely to matter: plant size, workflow volume, shift, language, software, customer type and decision authority. Choose a first wave of roughly six to eight participants for practical discovery, including frontline users and at least one budget holder. This is a scheduling suggestion, not statistical adequacy or a claim of saturation. Record who declined and which groups remain inaccessible.

Bring a neutral discussion guide, an episode sheet, a secure note location and a clear explanation of intended use. Ask for permission before recording or viewing documents. Accept redacted examples. A participant should be able to decline without a manager treating that as poor performance. Where translation is needed, brief the interpreter to preserve uncertainty and technical terms. Check interpreted meaning with the participant instead of smoothing it into confident English.

Facilitation and use

1. Define the uncertainty. Write one question such as “Where does a supplier quotation review become difficult, for whom, and with what consequence?” List the team's preferred answer separately so it can be challenged. 2. Select contrasting participants. Recruit people who experience both normal and difficult work. A founder's friendly contacts may be a starting point, but label that selection bias. Include a non-buyer or a team using an effective workaround. 3. Reconstruct a recent episode, 20 minutes. Ask the person to choose the last relevant occurrence. Establish when it happened, what triggered it and what counted as finished. Walk through the sequence without introducing the proposed product. Ask what happened next and who became involved. 4. Inspect evidence, 10 minutes. With permission, view a redacted ticket, spreadsheet, document or timestamp. Note what it corroborates and what it cannot show. A timestamp may establish delay without revealing active labour time. Do not infer employee motivation from a late response. 5. Explore consequences and alternatives, 10 minutes. Ask what changed because of the obstacle, how the person responded and why that workaround was acceptable. Distinguish inconvenience from an outcome that someone is willing and able to fund. 6. Test your interpretation, 5 minutes. Summarise the episode in neutral language. Invite correction. Ask for an example when the problem did not occur and what was different. Close by explaining how observations will be used. 7. Compare records. Within a day, have the interviewer and note-taker independently propose the problem mechanism. Reconcile differences against the notes. Build a table showing corroboration, uncertainty and counterexamples by context. 8. Make the next decision. Choose one mechanism to investigate or one low-risk intervention to test. Write the evidence that would make the team change direction. Recruit the next participants to resolve the largest gap rather than simply repeating the most convenient interview.

Evidence definitions and stopping logic

Classify each statement as reported, observed, corroborated or inferred. Reported means a participant described it. Observed means the researcher saw it within a defined occasion. Corroborated means a separate record or perspective supports that particular statement. Inferred means the team proposes an explanation. These labels describe provenance, not a universal hierarchy of truth. A system log can be incomplete; a participant can accurately explain what a log misses.

Stop the first discovery wave when the team can specify the work episode, actor, mechanism and consequence and can identify meaningful counterexamples. This permits a next experiment, not a market-wide conclusion. Continue recruitment when new contexts keep changing the mechanism, only senior staff have been heard, or the apparent problem depends on one unverified anecdote.

Worked example: illustrative, not a documented case

A Sharjah packaging supplier believes its sales team needs an AI quote writer. Eight exploratory interviews cover four estimators, two salespeople, one production planner and a commercial manager. This is one firm's discovery sample, not evidence about UAE packaging businesses generally.

Three reconstructed episodes show substantial waiting for material specifications. Two show rework when a customer changes quantities. One difficult quote is delayed because only a single manager can approve a nonstandard margin. In two ordinary episodes, templates already support quick quote preparation. These counts describe the records gathered and cannot estimate prevalence across all quotes.

The initial interpretation, “writing is the bottleneck,” has weak support. A redacted email sequence corroborates a missing specification in one episode. The planner explains that an apparently complete request lacked tolerances needed for costing. The team records this as an explanation to check against further requests rather than declaring a root cause.

The next decision is to test a structured intake checklist for one quote category and log how often estimation must return to the customer. AI drafting remains a possible later intervention. The problem statement becomes: “Estimators cannot begin reliable costing for this category when required specifications are missing; sales currently resolves gaps through repeated messages.” The commercial consequence remains unquantified until workflow measurement supplies a baseline.

Outputs, failure modes and validation limits

Deliver de-identified episode records, a recruitment coverage table, a contradiction register, a problem statement and a next-test memo. Preserve unknowns. If participants describe inconvenience but no actionable consequence, further investment may not be justified.

Leading questions, presenting the solution too early, treating all interviewees as independent accounts and counting repeated comments from one company as separate market evidence are common errors. Another failure is interpreting polite interest as purchase intent. A participant may welcome research while having no budget or authority to buy.

A counterexample is a seasonal workflow: interviews conducted in a quiet month can miss the peak-period constraint. Interviewing people after a recent outage can overstate how typical that outage is. Include period and workload context in every record and use operational logs to investigate frequency where available.

Validate the protocol by asking another researcher to reconstruct the same conclusion from the evidence. Test whether affected people recognise the problem statement. Stronger commercial claims need broader sampling or observed commitments; stronger causal claims need an appropriate intervention design. This worksheet does not provide either automatically.

Working files and reuse

The five-page PDF includes a visual reference, two fillable worksheet pages, an illustrative worked example and a facilitator/source guide. An expandable CSV working log is also available.

All examples are illustrative, not measured client results. Original episode and contradiction protocol. Combined method not field validated. A small discovery wave does not estimate market prevalence or prove purchase intent. No proprietary toolkit or Test Card is reproduced.

Original dotSuper material prepared for review. No public reuse licence has been assigned. Third-party source material retains its own terms.

The PDF is not represented as a tagged PDF/UA document. The text on this page provides a readable alternative to the diagram and method.

Sources, context and limits

Keep the evidence beside the method.

• Original episode and contradiction protocol. Combined method not field validated. A small discovery wave does not estimate market prevalence or prove purchase intent. No proprietary toolkit or Test Card is reproduced.
• This combined dotSuper method is research-informed and has not been field validated. Workshop agreement and a completed template are not proof of effectiveness.
• Worked examples are hypothetical. Country examples and intended regional audience do not establish country-wide or region-wide effectiveness.
• Source access and adaptation limits are recorded in the source ledger. Attribution does not imply endorsement or a licence to reproduce third-party artwork.

1. Customer Development Manifesto

   Steve Blank · accessed Sep 16, 2026

2. Design Kit: Interview

   designkit.org · accessed Sep 16, 2026

3. Framework for Innovation

   designcouncil.org.uk · accessed Sep 16, 2026

4. Test Card

   Strategyzer · accessed Sep 16, 2026

Bring it into the work

Start with one real decision

Bring one customer problem hypothesis and plan the observations needed to challenge it.