2. Workflow Discovery & Domain Speed

An SOP describes the job the way the organization wishes it worked. The real job is full of small, unrecorded adaptations: the spreadsheet someone keeps on the side because the CRM doesn't capture a field they need, the step that's "supposed" to require manager approval but rarely gets it under deadline, the shortcut three people use and two don't even know exists. None of that is in the documentation. All of it is in the workflow.

Shadowing — sit with someone while they do the task, in real time, without interrupting to ask why. Interruption changes behavior; watching in silence doesn't.

Contextual inquiry — ask questions in the exact moment a step happens, not afterward in a debrief. "Why did you just do that" asked live gets an honest, specific answer. Asked an hour later, it gets a reconstructed, tidied-up one.

Workflow reconstruction — after observing, rebuild the process as a diagram and hand it back to the operator to correct. The corrections, not the diagram itself, are the actual signal — they show you exactly where your model of the process was wrong.

This isn't dishonesty. People genuinely don't have full introspective access to their own workarounds — a step becomes so automatic it stops registering as a "step" at all. Asking "walk me through your process" gets you their mental model of the process, which has quietly drifted from what their hands actually do. This is precisely why observation has to come before interview, not after.

The most valuable discovery moments aren't where the documented and actual processes match — they're where they diverge. A gap usually means one of three things: the documentation is stale, the tool doesn't actually support the real need, or there's a business rule everyone quietly agrees to ignore. Each of those implies a different fix, so identifying which kind of gap you're looking at matters as much as spotting it.

Used together, in that order, they compound — shadowing generates the raw material, contextual inquiry explains it live, reconstruction pressure-tests your synthesis.

When a customer stakeholder describes their process cleanly and confidently in a kickoff call, that's not a green light to start building — it's a signal to schedule shadowing before the architecture gets locked in. The gap between the confident description and the messy reality is exactly where a deployment that "should have worked" quietly fails three weeks after launch.

Four roles rarely fully overlap in an enterprise account, and every one of them can independently make or break a deployment — regardless of which one you spent the most time with during the sales cycle.

Performs the work daily and feels the pain first-hand. The operator's buy-in determines whether the tool actually gets used once it ships — no amount of executive enthusiasm substitutes for this.

Owns the budget and signs the contract. The buyer's incentive is usually outcome-and-cost focused, not workflow-focused — they may never personally touch the tool you're building.

Benefits from the deployment succeeding and will advocate internally — but critically, may be neither the operator nor the buyer. A champion without operator or buyer alignment can talk a deal into existence that then fails to land.

Can stop the deployment regardless of title — security, legal, or even an operator who feels quietly threatened by automation. Blockers are often invisible in the sales-cycle meetings entirely.

Mapping all four roles before designing the solution — not just identifying the buyer and champion — is what prevents building something the buyer wants but the operator quietly sabotages through under-adoption. This mapping should happen in parallel with, not after, the sales-cycle conversations.

"Would an AI assistant that automates X help?" invites a polite yes almost regardless of the real situation. "Walk me through the last time X went wrong" invites a real story, with friction points you didn't anticipate and couldn't have scripted into a leading question.

A leading question produces agreement, and agreement feels like progress in a discovery call. But agreement isn't information — it's social compliance. The customer isn't lying, they're just being polite about a hypothetical they haven't actually tested against their real workflow.

Narrate a past event — "walk me through exactly what happened" forces specificity a hypothetical can't. Ask for the exception — "when does this process break down" surfaces edge cases a clean description skips over. Ask who else is affected — often reveals a stakeholder or workaround the primary contact didn't think to mention.

Any question containing your intended solution — "would X help," "wouldn't it be great if" — has already told the customer what answer you're hoping for. Removing the solution from the question is the actual discipline here, not softening the tone.

The gap between what a customer says the process is and what actually happened during their last real failure is where genuine requirements live. Non-leading discovery is how you find that gap instead of confirming whatever assumption you walked in with.

You're not trying to out-expert the customer's own domain specialists. You're trying to earn the right to ask sharp, informed questions instead of generic ones — a much lower and much more achievable bar.

Not all sources are equal. Primary industry publications and practitioner writing come first; analyst reports come second; vendor marketing comes last, since it's optimized to sell rather than to inform. Spending the first day building this hierarchy prevents wasting the other nine on low-signal sources.

Every domain has specific terms that signal whether you've done the work. Using the wrong generic term for something the domain has a precise name for is the fastest way to lose credibility in the first five minutes.

Book 2-3 expert interviews specifically to test your understanding, not to gather generic background you could have found in an article. Using new vocabulary live, in front of someone who'd notice if you used it wrong, is the fastest way to find the gaps in your grasp before the customer does.

The output of this ramp isn't a memo — it's a workflow map of the customer's actual process (from this section's earlier discovery work) plus a proposed redesign showing where AI capability fits, expressed in the customer's own vocabulary, not generic AI terminology.

Assessing data readiness before committing to an approach is what separates a deployment that survives contact with real data from one that looks great in the proposal and collapses in week three.

Does the data actually cover the cases you're proposing to handle, and is it current enough to be useful? A dataset that's 90% complete but missing exactly the edge cases you need is functionally incomplete for this purpose.

Quality isn't just "is it accurate" — it's "can anyone confidently say whether a given record is accurate." Without ground truth, you can't build a reliable evaluation set later, no matter how good the model is.

Data can exist, be accurate, and still be unusable if you can't get proper access to it — due to ownership disputes between departments, permission structures, or simply nobody knowing who's authorized to grant access.

"Who can tell me, with confidence, whether this specific record is right or wrong?" If no one in the room can answer that, you don't have ground truth — and that single gap undermines everything downstream, from evaluation to trust in production.