Process 1 — capturing intent

What you will learn How a one-line request becomes an executable specification, and why asking back is its own phase.

It starts as one line

In reality, requests arrive like this:

text

"Make coupons work in the cart"

You cannot build from that. Too much is undecided.

The asking-back phase

A PM agent removes the ambiguity with questions.

text

Q: Can several coupons be stacked?A: No, one only.Q: What happens if someone enters an expired coupon?A: Tell them it's expired and don't apply it.Q: Is there a minimum order condition?A: It varies by coupon. If they're under it, show them the condition.Q: Does the total update immediately, or at checkout?A: Immediately.Q: Does it apply to items that are already discounted?A: ...ah, I hadn't thought about that. No, it shouldn't.

The last question is the value of this phase. Something even the requester had not considered, found before building.

Why an agent asks rather than a person

A human PM can ask too. But there are differences.

	Human PM	PM agent
Timing	you have to schedule a meeting	immediately
Omissions	skips familiar territory	sweeps systematically
Record	scattered across meeting notes	becomes the specification directly

The third matters most in practice. The Q&A is the specification, so there is nothing to write up afterwards.

Output — a specification with no room for interpretation

text

[Feature] Coupon application in the cart[Behaviour]- Enter a code in the coupon field; validate and apply the discount- The total updates immediately on application[Rules]- Only one coupon applies (no stacking)- Expired coupon: "This coupon has expired"- Below minimum: "Valid on orders over $N"- Not applicable to items already discounted[Out of scope]- Coupon issuance (separate work)- Coupon analytics (separate work)

Note the "out of scope" section. Writing scope as what not to do applies here directly.

What happens to ambiguity left here

It does not resolve itself. In a later phase AI picks one option and proceeds, and that choice hardens plausibly.

graph TD
  A["Not written in the spec"] --> B["AI decides arbitrarily"]
  B --> C["It goes into the code"]
  C --> D["Tests are generated on the same assumption"]
  D --> E["Everything passes · nobody notices"]
  E --> F["Found later: 'why does it work like this?'"]

Because the tests get built on the same assumption, verification does not catch it either. That is why this is the first phase in the process.

Practical technique

Keep a list of questions to ask back

For the same kind of work, the questions are similar.

text

Common questions for screen features:  □ what is shown on failure  □ what is shown while loading  □ what unauthorised users see  □ how it looks on mobile  □ which existing features are affected

"I hadn't thought about that" is a good sign

That is exactly what asking back is for. The cost difference between deciding it now and discovering it later is large.

Check yourself

1. Why is ambiguity left in this phase not caught later?

Answer

Because after AI decides arbitrarily, the tests are generated on the same assumption. Everything passes, so verification reveals nothing, and it turns up much later as "why does it work like this?"

2. What is a PM agent's practical advantage over a human PM?

Answer

The Q&A becomes the specification directly. Nothing gets scattered across meeting notes, so nothing needs writing up. It also starts immediately and does not skip familiar territory.

3. How should you read "I hadn't thought about that" from the requester?

Answer

As a good sign. Finding exactly that is the purpose of asking back, and finding it before building is far cheaper.

Once the specification is ready, several agents attach at once → Process 2 — agent orchestration