2 Discover intent through conversation

A good discovery conversation changes what the participants understand. It does not merely collect answers for headings in a plan.

Puma's concern is that consequential details often remain unstated because they seem obvious, have not yet occurred to the requester, or only become visible when a proposed solution is examined. An agent can fill those spaces with reasonable assumptions. The resulting design may look complete precisely because its assumptions are internally consistent.

The conversation should therefore expose choices that matter, while leaving room for both the person and the agent to revise the picture.

Ask questions that can change a decision

Consider the resource acquisition example. Asking “What programming language should we use?” may be premature if the work belongs in an existing component. Asking “What should the consumer see while the new version is being checked?” may reveal a product invariant.

The second question can change the design. The person might require the old version to remain usable, accept a temporary unavailable state, or want both versions addressable. Those answers imply different identity and publication behavior. A useful question has a plausible connection to a decision; it is not simply something the agent could ask.

Questions also need sequence. Begin with concrete situations the person understands. Ask how they use the current system, what goes wrong, and what they expect next. Introduce technical alternatives once the distinction they represent is clear. Otherwise the person may choose an option based on a name while misunderstanding its consequences.

Avoid leading formulations. “Wouldn't a reusable service be better?” invites agreement with an unexplained conclusion. “Two applications need this behavior; should they share one process, or is independent operation important?” identifies a real tradeoff. Even that question may need an example before the person can answer.

Keep different kinds of statement separate

The discussion may contain an intention, an observation, a constraint, a preference, a hypothesis, and a decision. They do not need six files, but they should not collapse into one undifferentiated list.

“The model must work offline” could be a firm requirement. “The existing runtime fails on this machine” is an observation with a particular environment. “I think a graph would make it easier” is a hypothesis. “I prefer one screen” is a preference whose importance may depend on the task. “We will preserve the current version until the replacement is ready” is a decision once the authorized person agrees.

When the agent presents its synthesis, it should retain those distinctions. Turning every suggestion into a mandatory requirement overconstrains the design. Treating every requirement as negotiable removes the person's control over the outcome.

The published Coding-Standards discovery procedure makes these distinctions explicit and asks what could make a technically correct implementation wrong for its intended use. It also preserves the boundary between discovery and implementation authority: research or a polished visual does not approve an unresolved design. This is a statement about the inspected policy, not evidence that every development session follows it. Discovery and Design at the inspected revision.

Use examples to find the omitted rule

People often recognize a bad result before they can formulate the rule that prevents it. Ask about a normal case, an interrupted case, and an awkward boundary.

For acquisition, a normal case is a new resource becoming usable. An interrupted case is a cancelled operation. A boundary case is cancellation arriving after the bytes finish but before the resource is published. The last case exposes whether cancellation means “stop future work where possible,” “guarantee no publication,” or something else.

Do not treat the first answer as an implementation detail the person should have known. The whole point of the conversation is to make the consequence visible. The agent can explain the possible behaviors and their costs, then ask which outcome matters.

Examples should not become an exhaustive catalog. If ten examples all exercise the same distinction, another may add little. Seek a case that could change the rule. That is the difference between exploring the problem and making the conversation longer.

Explain back without claiming certainty

A useful synthesis describes what will be built, what the person will experience, and which consequences were added by the proposed solution. It also identifies the remaining question whose answer could change the direction.

For example: the current version remains usable during preparation; the new version becomes visible only after verification; cancellation before publication preserves the old version; a missing runtime is reported rather than silently installed. The person can now challenge a picture of the behavior rather than inspect a list of internal tasks.

Nuseibeh and Easterbrook describe requirements work as interpretive and iterative, with tacit knowledge limiting what interviews alone can uncover. Their roadmap supports combining conversation with observation, modeling, and revision. It does not promise complete understanding before implementation. Requirements Engineering A Roadmap.

When conversation is enough

A clear repair may need only one exchange. If a label shows the wrong unit, the correct unit is known, and no underlying semantic change is involved, extended discovery may delay a useful fix.

A small patch can still require substantial discovery if it changes a coupled decision. Moving one success response earlier may alter what multiple consumers assume about readiness. The size of the diff does not measure the amount of shared understanding required.

For your own task, identify the next question that could materially change the outcome, design, scope, or acceptance. If there is none, explain the direction and proceed within the available authority. If there is one, resolve it through a question, a source check, or a small experiment. The conversation should remain responsive while that investigation happens.