Scoping an AI project when the client doesn't know what they don't know

A client arriving with a fully specified, technically precise brief is rare, and treating that as a prerequisite for starting a scoping conversation excludes most of the businesses that would actually benefit most from the engagement, the ones who know something is inefficient but don't yet have the vocabulary or exposure to specify exactly what a solution should look like.

The scoping approach that works with genuine uncertainty isn't extracting a complete spec upfront, it's a structured discovery phase explicitly designed to produce the spec as an output, not assumed as an input: shadowing the actual current process, asking what a good day and a bad day look like, and translating vague frustration into specific, measurable friction points the client recognizes once they're named.

This discovery phase should be scoped and billed as its own distinct deliverable, not folded invisibly into the first month of a build engagement, because conflating the two creates pressure to rush discovery in order to start building, which routinely produces a solution built against an incomplete or wrong understanding of the actual problem.

A client who doesn't know what they don't know isn't underprepared, they're describing the normal starting condition for most real problems worth solving. The discipline is scoping engagements to actually account for that discovery cost upfront, rather than pretending every client arrives with a build-ready spec.