Test the stated request against the work people actually do

This is lesson four of Foundations of Forward Deployed Engineering. 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.

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

A request may contain an answer worth testing. Take "We want a chatbot over our documentation."

That request proposes an interface, a source and an interaction pattern. It may address a real search problem. It may also miss an earlier identification step, or a later approval delay. Accepting it or rejecting it on wording alone doesn't establish 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. Don't assume every customer has misunderstood their own problem, or that an expensive step must be obvious after one short visit.

The lesson's diagram draws the path. From the request, you watch the work, sitting with the operator. You count the cost, in hours, errors and delay, and you reach a candidate bottleneck. Skipping straight from the request to a build leaves the fit untested.

Next, ask questions that reveal evidence. The first one: 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.

Second: 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.

Third: 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.

And fourth: what evidence would change your view? This invites the user and the 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. So plan to observe the whole task after the intervention.

Now observe with a clear purpose. The UK government'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.

Ground rules first. 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 the 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 hasn't understood. So ask neutrally. "What tells you these IDs refer to the same customer?" is more useful than "Why do you still fix this manually?" Don't turn workflow research into an evaluation of the employee.

Now read the supplied observation before proposing a fix. This fictional note preserves a detailed workflow. Its quotes are teaching material, not statements from real customers.

At the kickoff call, the director said: "We want a chatbot over our documentation. People can never find anything." Asked how the morning report works, the analyst said: "I pull the report and check it. Twenty minutes, most days."

Here's what was watched, from eight fifty to nine thirty. She runs the Daily Orders report and exports it to a spreadsheet, copies her own formula columns across from yesterday's, and sorts by customer name, scanning for names that appear twice. For each doubled name, she searches the CRM to establish whether the two identifiers are the same customer. She fixes the identifiers by hand, from a mapping she keeps in a personal file, then totals the affected customers again and overwrites the report's numbers.

Then she spot-checks the three largest accounts against the billing system, deletes the overnight test orders, which she recognizes by their delivery address, pastes the totals into the team's running workbook, writes two lines of commentary and sends it to the distribution list at nine twenty-eight.

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

The session runs from eight fifty to nine thirty, and the report is sent at nine twenty-eight. That doesn't 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. And 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 record of where a number came from and what changed it. The mapping file may contain valid domain knowledge, or stale corrections. Treat each as a question with an owner and a test, not as an automatic target for deletion.

Next, separate observation, inference and the next test. Each row of the note gets three columns.

The analyst checks doubled names in the CRM, so names alone may be insufficient identifiers. A personal mapping file supplies corrections, so a recurring source mismatch may exist. Report totals are overwritten, so output provenance may be weak. Test orders are recognized by address, so test and live classification may be heuristic. And the director asks for document search, which may be a separate unmet need.

Each inference names its next evidence: canonical identity rules and collision cases, the mapping history, its owner and source reconciliation, original values, a change record and the reconciliation process, a supported test marker and false-positive examples, and recent failed searches, with their workflow consequences.

A good problem statement names the task, affected users, observed friction and uncertainty. Like this: "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 doesn't yet prescribe a chatbot, or a new master-data system.

Finally, calculate a modest timing estimate. A separate synthetic timing fixture contains active reconciliation minutes for four observed daily report batches. It isn't the timing detail missing from the narrative note.

The four batches took 4, 6, 8 and 22 minutes. The observed total is 40 minutes, the mean per batch is 10 and the median is 7. Assume twenty monthly batches, and the projection is 3.33 hours a month. That assumes these four batches represent twenty future ones. It isn't measured monthly effort, or proven avoidable work.

The fixture shows the median trap in miniature. The median is 7 minutes, and 7 times four batches is 28. But the four batches actually took 40, because the single 22-minute case carries more than half of the total. A median hides the tail. A total counts it. Use the total, or the mean, when the question is how much work there is, and the median when the question is what a typical batch feels like.

A fix may leave review effort, add maintenance or shift work to another person. So estimate the intervention's effect separately. If the 22-minute case reflects a valid month-end condition, deleting it because it's inconvenient changes the estimate. And if a second analyst works at the same time, distinguish labor minutes across both people from elapsed task time.

Your turn. Pause the video here. 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. Then run the timing fixture, and change the last value to 10. The total becomes 28, with a mean of seven and a median of 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. Don't rank steps by count alone. Three quick corrections may matter less than one long approval delay.

To recap. 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, and leave discovery with a testable problem statement and visible unresolved questions.

That's lesson four. Next in the series, map the people, decisions and prerequisites behind the pilot. The full lesson, with its exercise and drill, is on fdeinterviews.com.