The Stated Problem Is Rarely the Real Problem

Ask a stakeholder what they need and you'll usually get a solution, not a problem: "we need a chatbot for customer support." Solutions arrive pre-scoped to whatever the stakeholder has seen elsewhere, which means they're frequently wrong for this customer's actual constraints. The discovery job is to work backward from the proposed solution to the underlying problem, then forward again to the solution that actually fits.

A reliable technique is asking "what happens today when this goes wrong?" three times in a row, each time one layer deeper. "We need a chatbot for customer support" becomes "agents take too long to find the right policy" becomes "our policy documents are scattered across four systems and nobody trusts which version is current" — at which point the real project might be a unified, versioned retrieval layer with a simple search UI, not a conversational chatbot at all.

Four Questions That Separate Good Use Cases From Bad Ones

  • Is there a measurable baseline? If nobody can state today's error rate, cycle time, or cost for the task, you have no way to prove improvement later — and no way to know if you're actually helping. Insist on a number before you write a line of code, even a rough one.
  • Is the failure mode tolerable? Some tasks can absorb a wrong answer occasionally (a first-draft summary a human reviews); others can't (an automated decision that denies someone a service). Match the use case to how much autonomy the failure mode allows, not to how impressive full autonomy would look in a demo.
  • Does the data exist, and can you see it? A brilliant use case blocked on data you can't access for six months is not this quarter's use case. Confirm access — not just existence — before committing to scope.
  • Is there an owner who wants this to succeed? Use cases sponsored by someone with genuine stake in the outcome ship. Use cases sponsored by "innovation budget" with no operational owner tend to stall the moment the first obstacle appears.

Reading the Room vs. Reading the Data

Stakeholder interviews and real data disagree more often than either side expects. A support lead may describe ticket volume as "mostly billing questions" from memory, while a sample of 50 real tickets shows billing is a third, shipping issues are another third, and the rest is a long tail nobody mentioned. Discovery isn't complete until you've looked at real artifacts — real tickets, real documents, real transcripts — not just descriptions of them.

The fastest way to do this: request 20–50 recent, real, representative examples of the task on day one of discovery, before any architecture discussion. Skim them for format consistency, edge-case frequency, and how much implicit knowledge a correct answer requires. This single step surfaces more real constraints than a week of stakeholder meetings.

Scope to the narrowest slice that proves the thesis

"Automate customer support" is not a scope; "automatically draft a response to billing-status questions, with a human approving every send, measured against current average handle time" is. The narrow version is boring, fast to build, and — critically — it tests the same underlying thesis (can the model handle this domain reliably) as the ambitious version, just with less risk and a faster feedback loop.

Writing a Scope Document That Survives Contact With Reality

A useful scope document for an FDE engagement is short — one to two pages — and answers five things plainly: the specific task in scope (and, explicitly, what's out of scope); the success metric and its current baseline; the data sources involved and who owns access to each; the human-in-the-loop model (full autonomy, approval-required, or advisory-only); and the timeline to a first demonstrable result, which should be measured in days for the prototype, not weeks.

Circulate this document to the technical champion and the economic buyer separately, and ask each to push back before you start building. Disagreements surfaced now cost an afternoon; the same disagreements surfaced after three weeks of building cost the whole engagement's credibility.

Common Scoping Traps

  • The kitchen-sink pilot — trying to prove five capabilities at once because five stakeholders each wanted their pet feature included. Split it; run the narrowest one first.
  • The unmeasurable win — "make support better" has no way to fail, which sounds safe but means you can never prove success either. Insist on a number.
  • The invisible dependency — a use case that quietly requires an integration, an approval, or a dataset nobody has secured yet. Surface every dependency explicitly in the scope document, with an owner and a date next to each.
  • Scoping to the demo instead of the outcome — building for a single impressive show-and-tell moment rather than for the workflow the metric depends on. Demos convince budget-holders; outcomes renew contracts.

Frequently Asked Questions

How long should discovery take before starting to build?
Enough to identify one narrow, well-bounded use case with a measurable baseline — typically a few days to two weeks, not months. The goal of discovery is to earn the right to build something small and real, not to produce an exhaustive requirements document.

What if the customer insists on a use case that is a bad fit for AI?
Say so early and explain why in terms of their own success metric, not in terms of model limitations they don't care about. Propose the adjacent use case that shares their goal but plays to the technology's strengths. Customers generally respect a scoped no over a vague yes that fails in month three.

How do you size a use case before you have real data to test against?
You rarely have to guess blind — ask for a sample of 20 to 50 real, recent examples of the task during discovery itself. Skimming real examples surfaces edge cases, format inconsistencies, and volume patterns far faster than any amount of stakeholder interviewing.