AI Discovery: Scoping Users, Needs, Constraints and Unknowns

1.The discovery brief: users, needs, experience, constraints

Discovery usually starts with a one-line request. The Anthropic Academy builder course uses this one: a community health clinic needs a way for patients to check wait times before coming in. That is the whole brief. The tempting move is to start designing a wait-time checker. Structured discovery holds off on that and produces a problem brief first, written in plain language.

The brief answers four questions, and each one is built to push past the obvious answer. Who are the users? "Patients" is too broad: which patients, and what about the staff who would have to keep the data current? What do they actually need? The real need is an outcome the user hopes for, and a feature name doesn't describe that. What does a great solution feel like to use? Here you describe the experience, not a list of features. What are the real constraints? Budget, the clinic's technical skill, patients' access to devices and privacy requirements all limit what can be built.

The constraints question also covers non-functional requirements, and discovery should draw them out of the client rather than leave them to be assumed. Anthropic's guidance on success criteria lists several to ask about: the acceptable response time, the budget for running the system, how personal or sensitive information must be handled, and how rare or awkward inputs (edge cases) should behave. Each should end up specific and measurable, such as a number rather than "fast".

The stakeholders are not one audience. Anthropic's healthcare guidance says patients and staff respond differently to AI-assisted processes. For patients, discovery should capture that the system explains what the AI can and cannot do and offers a path to a human. For staff, it should capture how the organization's existing change-management process will apply. Treat these as requirements to elicit from each group, not as afterthoughts.

Writing these down as acceptance statements closes the loop. The course asks for five to seven statements that define "done", each concrete enough that a stranger could judge pass or fail.

Sources123

2.Decompose first, then decide what AI does

Once the brief exists, the next discovery question is how to break the problem down. "Should we use AI here?" is the wrong first question, because it is answered too early. The course says to start from the customer problem, decompose it, and only then decide what role AI plays in each piece. Sometimes that role turns out to be small, or none at all. The simplest viable solution is a result of decomposition, not a gate placed before it.

For each piece, pick one of three collaboration modes. In Automation, AI does the work and you check it. In Augmentation, you and AI work on it together. In Agency, AI operates with latitude inside boundaries you set. The course has learners map the build onto a six-row table, one row per capability, with a mode chosen for each. The sources for this lesson do not list the six capabilities, so apply the modes to the pieces your own decomposition produces. The table shows stakeholders where a human stays in the loop and where the system acts on its own.

The course also states which parts can be handed off: delegating implementation is safe, and delegating judgment is not. Framing the problem, setting the bar and deciding what counts as done stay with the people doing discovery. As AI speeds up implementation, these judgment tasks become most of a builder's contribution.

The same principle applies to the architecture you scope. Building Effective Agents recommends the simplest solution that works and adding complexity only when it is needed. Discovery should record why a more complex design is justified, and should not assume one from the start.

Sources14

3.Mapping what you don't know yet

A brief only records what someone thought to say, and a model can only act on what it is told. The course puts it this way: AI cannot hear what the user did not say. Anthropic's field guide on finding your unknowns calls the gap between the description you hand over (the map) and the real constraints (the territory) your unknowns. When a model runs into one, it decides based on its best guess of what you want.

The guide sorts what you know into four quadrants:

Unresolved unknowns cause failures in both directions. If instructions are too specific, the model keeps following them even when a change of course would be better. If they are too vague, the model fills the gaps with choices based on general industry best practice, which may not fit your task. Planning ahead also has limits: some unknowns only appear deep in implementation, and some show that the problem should be solved a different way altogether.

Even experienced practitioners have unknowns left. The guide notes that the best agentic coders also assume unknowns, so a discovery brief should state which gaps remain open instead of presenting itself as complete.

Sources56

4.Techniques that surface unknowns before implementation

The field guide offers several techniques for finding unknowns. Use them before implementation, while changes are still cheap: a small change to a feature or spec can lead to a very different implementation. Only two are tied to a quadrant by the guide. The others are tied to situations.

- Blind spot pass. For unknown unknowns, such as an unfamiliar domain or codebase, ask the model to find and explain what you don't know you don't know. Tell it who you are and what you already know. - Brainstorm and prototype. For unknown knowns, where you only know the criteria when you see them, ask for several deliberately different directions or a throwaway mock-up to react to, before anything is wired up. - Interview. For the ambiguities that remain after brainstorming, have the model interview you, putting first the questions whose answers would change the architecture. The guide does not assign a dedicated technique to known unknowns. Interviewing is the closest fit, since it targets ambiguities you already know about. - References. When you can't easily describe what you want, point to an example. The guide says the best reference is source code. This is a response to a situation, not to a quadrant.

Claude Code's best-practices guide includes a structured interview prompt that ends by writing a spec:

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

Sources76

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.The first discovery question is whether AI should be used for this problem.Why is that wrong?

   Discovery breaks the customer problem down first, then decides what role AI plays in each piece. Judgment stays with people; implementation is what can be delegated. This is consistent with the simplest solution possibly involving no agentic system: that conclusion comes out of decomposition and is not a gate applied before it.

   Covered in Decompose first, then decide what AI does

2. 2.Leaving requirements vague is safe because the model will fill gaps with sensible defaults.Why is that wrong?

   The model fills gaps using general industry best practice, which may not fit this client's task. Vague requirements produce plausible results that don't fit.

   Covered in Mapping what you don't know yet