Mapping the Real Work — Discovery Before Design

Every team thinks they know their workflow. Almost no team can describe it accurately on the first attempt. The version in the SOP document is rarely the version that runs on a Tuesday afternoon when the deal is mid-flight and three people are pinging the same Slack channel.

This is not a failure of documentation. It is the nature of knowledge work. The real workflow lives in muscle memory, in private heuristics, and in the small judgment calls that experienced people make so quickly they no longer notice they are making them. Discovery is the work of pulling those calls into the open so the AI workflow can be designed around them, not against them.

What discovery looks like

A discovery session is not a survey. It is a structured interview with the people doing the work, in front of a real example, while they walk through what they do and why.

The questions we keep returning to:

• Show me the last three of these you completed. Where did each one start?
• What did the input look like when it arrived, and what did you have to fix or fill in before you could begin?
• Where in this work did you have to make a judgment call? What were the alternatives?
• What is the moment in this workflow where you most often catch a mistake? Whose?
• If you could only automate one step, which would it be and why?

The answers are almost always surprising. The step the team most wants to automate is rarely the step that produces the most value when automated.

Why this matters before any model call

When a team skips discovery, the AI workflow gets designed against the documented process — which is, as we have established, partly fictional. The system runs cleanly on the demo input and falls apart on the real one. Trust erodes, adoption stalls, and the conclusion drawn is that the model "isn't good enough yet."

The model is almost never the bottleneck. The map is.

Discovery is unglamorous and time-consuming. It is also the highest-leverage hour of an engagement.