Before I ask for codebase access on a new engagement, I want an hour with whoever does the work. That might be the ops person with eleven browser tabs, the coordinator who knows which customers call instead of emailing, or the reviewer who spots a bad record without being able to explain the judgment yet. I ask them to walk through yesterday, including the workaround missing from the process diagram.
Several expensive failures I have seen in client AI work started before the first line of code. A team chose a capability, found a plausible place for it, and built a system that did not remove the bottleneck. The implementation worked as designed, leaving no bug that could explain why the project changed so little.
Set the solution aside
The first founder conversation usually arrives with a solution attached: "we want an agent for X." I set that solution aside long enough to ask about the working day.
- Where does work pile up?
- What gets dropped when things are busy?
- What does someone retype from one screen into another?
- What do your best people do that your newest people can't?
Those answers reveal where work waits, gets copied, or depends on judgment that the requirements document has flattened into a box on a diagram.
Listening notes
The real workflow contains the decisions the summary skipped
A fictional workflow applies the article’s discovery questions: compare the reported shortcut with the judgments between messages, a route sheet, and the CRM.
Scenario
Fictional discovery example: a tidy description hides decisions.
Sequence
- Hear the summaryCurrent
- See the apparent resultUpcoming
Hear the summary
“User reviews incoming requests” records what the workflow is called, but leaves out the decisions an operator makes.
Read the full explanation
As reported
Fictional discovery example: a tidy description hides decisions.
- Hear the summary. “User reviews incoming requests” records what the workflow is called, but leaves out the decisions an operator makes.
- See the apparent result. The reported process jumps directly to a CRM record. Watching the work reveals the missing dependencies.
As observed
A fictional walkthrough applying the article’s questions, not the author’s field notes.
- Watch both channels. In this fictional example, a coordinator works across Gmail and WhatsApp Web while keeping a CRM and a route sheet open.
- Interpret the shorthand. The coordinator manually interprets sender abbreviations while copying fields between screens.
- Use domain judgment. The reviewer catches bad city matches using lane history. The extracted city field alone is insufficient evidence.
- Resolve duplicate demand. Check sender, route, and timing together when the same demand arrives through multiple channels.
- Write the resolved record. Remove copy-paste only after entity resolution and duplicate handling are understood.
Judgment still needed
A useful first build keeps unresolved judgment visible.
- Watch both channels. In this fictional example, a coordinator works across Gmail and WhatsApp Web while keeping a CRM and a route sheet open.
- Expose the ambiguity. Abbreviations require interpretation; keep the original message available to the operator.
- Consult the history. Bring route-sheet and lane-history evidence into view rather than hiding it behind an extracted field.
- Check before writing. Compare sender, route, and timing before creating a second CRM row.
- Hand off the unresolved case. When the workflow judgment is still unclear, preserve source messages and the open question for an experienced operator.
As reported
Fictional discovery example: a tidy description hides decisions.
- Hear the summary. “User reviews incoming requests” records what the workflow is called, but leaves out the decisions an operator makes.
- See the apparent result. The reported process jumps directly to a CRM record. Watching the work reveals the missing dependencies.
As observed
A fictional walkthrough applying the article’s questions, not the author’s field notes.
- Watch both channels. In this fictional example, a coordinator works across Gmail and WhatsApp Web while keeping a CRM and a route sheet open.
- Interpret the shorthand. The coordinator manually interprets sender abbreviations while copying fields between screens.
- Use domain judgment. The reviewer catches bad city matches using lane history. The extracted city field alone is insufficient evidence.
- Resolve duplicate demand. Check sender, route, and timing together when the same demand arrives through multiple channels.
- Write the resolved record. Remove copy-paste only after entity resolution and duplicate handling are understood.
Judgment still needed
A useful first build keeps unresolved judgment visible.
- Watch both channels. In this fictional example, a coordinator works across Gmail and WhatsApp Web while keeping a CRM and a route sheet open.
- Expose the ambiguity. Abbreviations require interpretation; keep the original message available to the operator.
- Consult the history. Bring route-sheet and lane-history evidence into view rather than hiding it behind an extracted field.
- Check before writing. Compare sender, route, and timing before creating a second CRM row.
- Hand off the unresolved case. When the workflow judgment is still unclear, preserve source messages and the open question for an experienced operator.
Uncover the decisions before choosing the first build
A fictional request-processing workflow applies the article’s discovery questions. Open each observation, then compare possible first interventions. These are teaching examples, not the author’s field notes.
Sample observation: an operator copies the same request between messages and a record form.
Unknown dependency. A tidy process description does not resolve it.
Unknown dependency. A tidy process description does not resolve it.
Unknown dependency. A tidy process description does not resolve it.
Inspect the field-note logic
The exercise requires all four sample observations before endorsing the assisted form as a candidate to validate. This is not a discovery score or a universal checklist. In a real engagement, the operator’s bottleneck and unresolved judgments determine scope; a model may not be needed.
Preserve screen reality, judgment moments, failure smells, and a bounded first intervention. Do not convert “we watched it happen” into “the system is authorized to do it.”
Screen reality: apps open, tabs used, sheets copied from, messages checked, and the order they actually happen in.
Judgment moments: places where an experienced operator sees something the system cannot infer from one field alone.
Failure smell: duplicate entry, stale context, retyping, waiting, unofficial spreadsheet, or "ask the senior operator because she knows."
First build candidate: the smallest intervention that removes the bottleneck without pretending the whole workflow is understood.
- Product discoveryDefines product discovery as understanding customer needs and context before deciding what to build.
- Teaching Customer Development and the Lean StartupThe older version of the same discipline: get outside the building when customer needs and features are still unknown.
- A Day in the Life of a Palantir Forward Deployed Software EngineerDescribes embedded engineers translating observed workflows into software rather than collecting requirements from a distance.
- Shadowing success team as means to product discoveryA practitioner thread that captures the same instinct: awkward workflows often become visible only by watching the work happen.
What the listening buys
Two weeks of observation can look slow to a founder paying for visible progress. It often changes the first build. The worst bottleneck may need a queue and a form, or the useful AI intervention may sit one step earlier than the task everyone complains about.
A requirements document records how the organization describes its work. A walkthrough exposes the copied spreadsheet, the unofficial approval, and the customer exception that experienced operators handle without mentioning it.
Current AI capabilities make it tempting to begin with the toolkit. For those two weeks, the domain experts know more than the engineers about why the workflow has its present shape. The engineer's job is to notice where their explanations and their actions diverge without treating either as a mistake.
Across the deployments I have shipped, weak discovery has been harder to recover from than a mediocre first implementation. Code can be replaced once the team understands the workflow. A mistaken account of the work keeps sending each revision in the wrong direction.