Test the stated request against the work people actually do

TL;DR: Treat a requested feature as a hypothesis about a need, then compare it with specific work, evidence and constraints. Combine observation with questions and measurement before deciding what to build, change or leave alone.

Where you are. The role module established the engagement loop. Discovery now turns a broad request into a problem statement that can support a bounded scope and an honest evaluation.

A request may contain an answer worth testing

“We want a chatbot over our documentation” proposes an interface, source and interaction pattern. It may address a real search problem. It may also miss an earlier identification step or a later approval delay. Neither accepting nor rejecting it on wording alone establishes the right solution.

Ask what happened the last time someone needed the information: who was doing what, which record or decision was missing, what they tried and what happened next. Preserve the person's explanation rather than translating it immediately into your preferred architecture.

A useful discovery result can confirm the requested feature. It can also support a smaller workflow change, a source repair or a decision not to proceed. Do not assume every customer has misunderstood their own problem or that an expensive step must be obvious after one short visit.

Ask questions that reveal evidence

Walk me through the last specific instance. A concrete case exposes details that a general description may omit. Follow up on unusual steps, but also ask whether this case was typical and what differs across teams, channels or shifts.

How long does each step take, and how often? Distinguish active effort from elapsed waiting, one case from a batch, and an estimate from a measured value. Frequency times an appropriate mean can estimate total effort under explicit assumptions. Multiplying a median by volume or overlapping work by several users can misstate the total.

What happens if nothing changes? The consequence may be labor, delay, errors, missed obligations, inaccessible service or staff burden. A problem need not appear as immediate cash expenditure to matter. Ask how it competes with other priorities and who can decide, rather than dismissing it as merely annoying.

What evidence would change your view? This invites the user and team to name a disconfirming case. If a candidate identifier repair is correct but the task still takes just as long, another step may dominate. Plan to observe the whole task after the intervention.

Observe with a clear purpose

GOV.UK's contextual-research guidance describes observing activities in their everyday setting to understand needs, barriers and workarounds. For this course, use observation alongside interviews and records so each can expose what the others miss.

Agree what may be observed or recorded and protect confidential information. Avoid interrupting a critical task to ask a question; note it for a suitable pause. The observer's presence and an unusual day's workload can change behavior, so record context and seek additional cases where needed.

Someone may omit a routine step because it feels obvious. They may also deliberately choose a shortcut for a reason the observer has not understood. Ask neutrally: “What tells you these IDs refer to the same customer?” is more useful than “Why do you still fix this manually?” Do not turn workflow research into an evaluation of the employee.

Read the supplied observation before proposing a fix

This fictional note preserves a detailed workflow. The quotes are teaching material, not statements from real customers.

notesSynthetic observation notes · Tuesday 08:50 to 09:30

Discovery notes, day two: the request at the top, the workflow underneath

The stated request (the director, kickoff call): "We want a chatbot over our documentation. People can never find anything."

What the analyst said when asked how the morning report works: "I pull the report and check it. Twenty minutes, most days."

What we watched, 08:50 to 09:30:

1. Opens the reporting tool, runs Daily Orders, exports it to a spreadsheet
2. Opens yesterday's spreadsheet beside it and copies her own formula columns across
3. Sorts by customer name and scans for names that appear twice
4. For each doubled name, opens the CRM in a second tab and searches to establish whether the two identifiers are the same customer [1]
5. Fixes the identifiers by hand, from a mapping she keeps in a personal file called fixes-do-not-delete.xlsx [2]
6. Re-totals the affected customers and overwrites the report's numbers
7. Spot-checks the three largest accounts against the billing system
8. Deletes the overnight test orders, which she recognizes by their delivery address
9. Pastes the totals into the team's running workbook
10. Writes two lines of commentary
11. Sends to the distribution list at 09:28

Steps 4 to 6 suggest identifier reconciliation is a candidate problem. The observation does not establish its typical duration, correctness or whether document search is also a problem.

1. [1] Observed reconciliation motivates a mapping investigation. Check the source rules rather than assuming duplicate names mean the same customer.
2. [2] The personal file is a dependency to understand. Verify its owner, provenance and changes before treating its mappings as authoritative.

The session runs from 08:50 to 09:30, and the report is sent at 09:28. That does not prove 40 minutes of active reporting effort or contradict the analyst's “twenty minutes, most days.” Questions, waiting and atypical work may account for some of the difference. The note lacks per-step timing and a representative sample.

Other risks are visible too. Recognizing test orders by delivery address may remove legitimate orders. Manual overwriting may lose provenance. The mapping file may contain valid domain knowledge or stale corrections. Treat each as a question with an owner and test, not as an automatic target for deletion.

Separate observation, inference and next test

A good problem statement names the task, affected users, observed friction and uncertainty: “In the observed morning report, the analyst reconciled customer identifiers manually before publishing totals. We need to measure that step and verify the mapping rule; document-search demand remains a separate question.” It does not yet prescribe a chatbot or a new master-data system.

Calculate a modest timing estimate

The following separate synthetic timing fixture contains active reconciliation minutes for four observed daily report batches. It is not the timing detail omitted from the narrative note.

from statistics import mean, median

minutes = [4, 6, 8, 22]
print('observed total:', sum(minutes))
print('mean per batch:', mean(minutes))
print('median per batch:', median(minutes))
assumed_monthly_batches = 20
estimated_hours = mean(minutes) * assumed_monthly_batches / 60
print('projected monthly hours:', round(estimated_hours, 2))
assert sum(minutes) == 40 and mean(minutes) == 10 and median(minutes) == 7
# observed total: 40
# mean per batch: 10
# median per batch: 7.0
# projected monthly hours: 3.33

The observed total is 40 minutes. The 3.33-hour projection assumes these four batches represent twenty future batches; it is not measured monthly effort or proven avoidable work. A fix may leave review effort, add maintenance or shift work to another person. Estimate the intervention's effect separately.

If the 22-minute case reflects a valid month-end condition, deleting it because it is inconvenient changes the estimate. If a second analyst works simultaneously, distinguish labor minutes across both people from elapsed task time. Later measurement lessons explore these distinctions in more depth.

The spine below is the whole move in order, from a request that already contains a guessed answer to a statement you can test, with the three-column split marked as the step that keeps a guess from hardening.

Do this before moving on

From the observation note, write five observations and keep interpretations in a separate column. Choose one candidate problem and specify a next test that could disprove it. Include a case where the chatbot request remains appropriate.

Run the timing fixture. Change the last value to 10: the total becomes 28, mean seven and median seven. The identical median now accompanies a different total. Explain why the sample and a volume assumption belong beside any projected effort figure.

Finally, observe or reconstruct a familiar task under appropriate permissions. Describe the complete path, including waiting, checks and exceptions. Do not rank steps by count alone: three quick corrections may matter less than one long approval delay. Your result should support a testable problem statement without pretending the next design decision is already settled.

Go deeper

• Requirements discovery covers the interview technique in more depth, including how to avoid leading the answer.
• Scoping ambiguous problems is the stage immediately after this one, and it fails when discovery was shallow.
• Stakeholder management matters because the person who described the problem is rarely the person who approves the fix.
• Data quality names the upstream breakage that most compensating workarounds are hiding.
• The most ambiguous project you have run end to end is where interviews ask you to demonstrate exactly this.

Key takeaways

• A requested feature is a hypothesis to investigate, not automatically a mistake.
• Combine specific examples, observation, interviews and records.
• Keep observations separate from inferred causes and proposed solutions.
• Distinguish active effort, elapsed time, batch volume and sampling assumptions.
• Leave discovery with a testable problem statement and visible unresolved questions.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1The director asks for document search, while one observed report needs manual ID reconciliation. What follows?

   The chatbot is definitely uselessInvestigate reconciliation and document-search needs separatelyBuild a master-data platform immediately

2. 2The timing fixture has values 4, 6, 8 and 22. Which supports the observed total?

   Median seven times four gives the totalThe values sum to 40 minutesTwenty monthly batches were actually measured

3. 3Why does watching one 40-minute session not prove the task normally takes 40 active minutes?

   Answer it, then reveal