What you will learn
Stakeholder interviews, Process mapping, Baseline measurement, Assumptions, Problem selection.
Engineering the capability
A customer request usually describes a desired solution before the underlying workflow is understood. Ask users to demonstrate a recent task with its actual inputs, systems, waiting periods, and exceptions. Observe where judgment is needed and where the work is already deterministic.
Map stakeholders separately: daily users, data owners, security reviewers, operators, and the person deciding whether the pilot succeeds. Their constraints can conflict. A manager may value throughput while operators care about control and error recovery. Record these differences rather than treating one interview as the whole customer perspective.
Measure a baseline on a small but varied sample. Separate active work from waiting time, and note case complexity. Keep assumptions in a register with an owner and a validation step. The purpose of discovery is a bounded, testable problem, not a large feature list.
Worked case
Support staff spend six minutes per ticket, but four minutes are waiting for a slow internal API. Better drafting can save at most part of the remaining two minutes. An AI demo that ignores this bottleneck may impress users while barely changing the workflow’s total time.
Put it into practice
Continue with the next lab: run a simulated discovery session. Build the artifact, record the failure cases, and explain the tradeoff before moving on.