Phase 0 agreed on the problem and one number that means "solved." But an AI can't build a problem — it can only build instructions.
Phase 1 is where the problem becomes a list of exactly what the system must do, written so precisely that two people couldn't build two different things from it.
Every idea below is paired with the real thing — examples come from a fictional but fully worked engagement, Harbor Mutual, a regional insurer.
Why this phase exists at all
An AI builds the instructions, not the intent
A coding agent does exactly what the requirement says. If the requirement is vague, the agent fills the gap with a guess — confidently, at 2 a.m., in week seven, with nobody watching. The whole point of Phase 1 is to leave no gaps worth guessing about.
A vague line isn't a small problem. It's an open invitation for the build to drift away from what anyone actually wanted — and you won't notice until the wrong thing is already running.
So Phase 1 turns the agreed problem into requirements precise enough that there's nothing left to invent. Each requirement carries the checks that prove it's met. A wish caught here is a sentence rewrite; the same wish caught in the build is a feature thrown away.
Harbor's whole reason for hiring the pod was a number from Phase 0: a claim takes a median of 11.4 days from being reported to a decision, and slow claims cost renewals. The target is half that.
A number like that isn't moved by good intentions. It's moved by a buildable, testable list of behaviors — which is exactly what this week produces.
You hand an AI a goal instead of instructions, and it builds a confident, well-tested answer to a question nobody actually asked.
Go deeper — the full method
Phase 0 agreed on the problem and one measurable number. But a coding agent cannot build a problem — it builds instructions, and it does exactly what the instruction says. Phase 1 is where the signed problem becomes a requirements baseline: a list of exactly what the system must do, written so precisely that two people could not build two different things from it.
Phase 1 answers four questions, and nothing else:
- What must the system do? Functional requirements with testable acceptance criteria.
- How well must it do it? Non-functional requirements, each with a measurement basis.
- In what order does value ship? Epics, sequenced against the outcome, priorities set by the product owner.
- What is explicitly out? Scope boundaries written down before pressure arrives.
Everything that looks like architecture, technology selection, data modeling, or estimation is deliberately out of scope — that work belongs to Phase 2 and beyond. A requirement says what and how well, never how. A wish caught here is a sentence rewrite; the same wish caught three weeks into the build is a feature thrown away.
The rule that governs everything
Claude drafts and interrogates; humans decide and own
This is the busiest drafting week of the whole engagement — and the rule from Phase 0 binds harder than ever. The AI writes the requirements, finds the conflicts, and keeps the running list of decisions nobody's made. People make every one of those decisions and sign for them.
There are three things the AI is never allowed to do in this phase, because each is a human's accountability:
- It never sets a priority — what ships first is a product call.
- It never accepts a requirement as good enough — a person confirms it says what they meant.
- It never decides what's in or out — scope is owned, not generated.
The AI's job is to make every decision visible and cheap to make. The human's job is to actually make it.
The clearest example: should the system that spots a "simple" claim decide it, or just recommend and let an adjuster confirm?
"Does the fast-path decide a claim, or recommend one for a human to confirm?"
"v1 recommends; an adjuster confirms with one click. Regulatory caution until 'simple' is proven against a year of data."
An unanswered question like that is exactly what an agent resolves silently in week seven. Here it got a named human and a recorded reason.
Go deeper — the full method
Phase 1 is the drafting-heaviest phase of the engagement, and the rule from Phase 0 still binds: Claude drafts and interrogates; humans decide and own. Concretely, Claude does a great deal:
- Decomposition drafting. From the Phase 0 artifacts and the document corpus, Claude drafts the candidate epic map and candidate requirements — every one carrying a source trace (a document reference like DOC-003, or "elicitation session, day 2").
- The decision list, continuously. Every draft regenerates the list of decisions no human has made yet ("you haven't decided what happens when a duplicate arrives"). The list is the PO's work queue, on a visible 2-business-day clock.
- Conflict and gap checks. Claude cross-checks every requirement against the constitution and the Phase 0 constraints ("REQ-014 implies storing claimant documents; constraint C-05 says PII stays in the client tenant — reconcile") and flags requirements that trace to nothing.
- Drafting the structure that makes review cheap. Stable requirement IDs, acceptance criteria in checkable form, error behavior spelled out for the highest-priority items (what it accepts, what it returns, what it does on failure).
What Claude never does in Phase 1: set a priority, accept a criterion, or make a scope call. Those are the product owner's, and in proxy mode they are logged, not just made.
What the week must answer
Four questions — and deliberately nothing else
Phase 1 answers exactly four questions about the system. Anything that smells like how to build it — the technology, the data model, the diagrams — is off the table. A requirement says what and how well, never how.
- What must the system do? Behaviors, each with the checks that prove it works.
- How well must it do it? Quality targets — speed, capacity, uptime — each with a real way to measure it.
- In what order does value ship? The work sliced and ranked by what moves the goal first.
- What is explicitly out? The not-now list, written down before the pressure to cram it in arrives.
- Every claim, from any channel, shows up in one queue within five minutes; duplicates get merged, never rejected.
- The queue handles 40,000 claims a year and a 10x storm surge; coverage status ready the same business day.
- Queue first (everything lands in it), then coverage, then the fast-path for the simple majority of claims.
- Out of v1: auto claims, SMS, fraud scoring, payment changes, and the adjuster dashboard rebuild.
It feels efficient to start naming technologies now — "we'll use a message queue." That's design leaking upstream. Write the behavior it wanted instead ("intake must keep accepting claims even when downstream systems are down"), and let Phase 2 choose the how.
Go deeper — the full method
Everything Phase 1 produces exists to answer exactly four questions, and nothing else:
- What must the system do? Functional requirements with testable acceptance criteria.
- How well must it do it? Non-functional requirements, each with a measurement basis — the number, how it is measured, and where it is read from.
- In what order does value ship? Epics, sequenced against the outcome, with priorities set by the product owner inside a top-tier budget.
- What is explicitly out? Scope boundaries written down before the pressure to cram them in arrives.
Everything that looks like architecture, technology selection, data modeling, or estimation is deliberately out of scope — that work belongs to Phase 2 and beyond. A requirement that names a technology ("the system shall use a message queue") is design leaking upstream; rewrite it as the behavior it wanted ("intake must accept submissions during downstream outages"), and let Phase 2 choose the how.
The technique that earns the phase
The vague-line test: could two people build two different things?
Every requirement gets one brutal question asked of it: could two people read this line and build two different things? If yes, it's a wish wearing a requirement's clothes — and it goes back to be sharpened, not quietly into the pile.
Words like "promptly," "intuitive," "robust," and "clearly visible" feel like requirements but specify nothing. An AI handed "respond promptly" will pick a number for you — and it won't be the one you'd have picked.
A dedicated person — the testability conscience — runs every acceptance check through this test before it's allowed to stand. This is the enforcement point: catch the vagueness here, on a Wednesday, not three weeks into the build when it's expensive.
On day 3, the testability pass caught five of thirty-one acceptance checks failing the test. The fixes turned wishes into things you can actually verify:
"The new claim appears in the queue promptly and is clearly visible."
"A claim submitted via portal at 14:00 is visible in the queue with status 'new' by 14:05 — same for phone-entered and parsed-email claims."
Go deeper — the full method
Every acceptance criterion gets one question asked of it — the vague-line test: could two people read this line and build two different things from it? If yes, it is a wish wearing a requirement's clothes, and it goes back to be sharpened, not quietly into the pile.
The Quality Engineer is the testability conscience. On day 3, every acceptance criterion goes through the vague-line test; criteria that fail go back to the Pod Lead, not quietly into the pile. This pass is the enforcement point — not the build loop three weeks later, where the same vagueness is expensive.
"Intuitive," "robust," "fast." The vague-line test exists for exactly this. An AI handed "respond promptly" picks a number for you — and it will not be the one you would have picked.
The quality targets, made real
"Fast" is an opinion — until you say where the number is read
Beyond what the system does, there's how well it has to do it: speed, capacity, uptime. The trap is writing "the system shall be fast." A quality target without a way to measure it is just a wish with a number attached.
Every quality target must carry three things: the number, how it's measured, and where that measurement is read from. "Fast" becomes "95% of requests under 800ms, measured at the gateway, read off the monitoring dashboard."
And the number itself comes from a human — the client's own data or a stated target. If nobody on the client side ever said the number, it doesn't get invented into the draft; it goes on the decision list for someone to answer.
Writing the quality targets surfaced a gap nobody had named: storm season. The Phase 0 sizing said 40,000 claims a year — and said nothing about peaks.
"A catastrophe event spikes intake to roughly 10x normal daily volume — about 1,600 claims a day — for a week straight."
"Sized for 40,000 claims/yr steady state and a 10x storm surge; load-tested at the surge profile before go-live."
A genuinely buildable spec has to survive a hurricane, not just an average Tuesday.
Quality targets get written as theater — impressive-sounding numbers nobody can ever read. If you can't say where the number will be measured, the target isn't done.
Go deeper — the full method
Beyond what the system does is how well it must do it: speed, capacity, availability. Every non-functional requirement carries a measurement basis — the number, how it will be measured, and where it will be read ("p95 API response under 800ms, measured at the gateway, read from the monitoring dashboard," where p95 means 95% of requests come in at or under the number). An NFR without a measurement basis is an opinion.
The numbers themselves come from humans — elicitation, the constraints, the client's own data. A target nobody on the client side stated goes on the decision list, not into the draft.
Non-functional requirements with no measurement basis are wishes. If nobody can say where the number will be read, the NFR is not done.
Deciding what ships first
If everything is top priority, nothing is
Left alone, every requirement becomes "must-have." That's not a plan — it's a refusal to plan. The defense is a hard cap on the top tier, set before the room can argue, and the product owner does the cutting.
The pod sets a budget for the top priority tier — sized to what can credibly ship in the first stretch of building — and announces it when the priority session opens. The product owner ranks within that budget.
The pod advises on cost and risk; it never sets the order. And it refuses to start building from a list where the top tier is over budget — because a blown budget just means the hard choices got deferred to a worse time.
The priority session: a top-tier budget of 12 slots, and 19 candidates fighting for them. Luis did the cutting, not the pod.
"We survive with the current screens one more quarter."
That cut hurt — which is exactly what a real priority decision is supposed to feel like. The budget held.
Go deeper — the full method
Left alone, every requirement becomes "must-have." Priority inflation is the default state of nature, and it is a refusal to plan. The defense is a hard budget for the top tier, enforced in the priority session.
The Pod Lead sets the budget before the session — sized to what the pod can credibly deliver in the first stretch of Build — and announces it when the session opens. Every requirement gets a priority the PO assigns: the pod advises on cost and risk, the PO owns the order and ranks within the budget. The pod refuses to start a phase where the top tier is over budget, because a blown budget just means the hard choices got deferred to a worse time.
If everything is top priority, nothing is. The budget is the only thing that forces the real choice — and the PO, not the pod, makes the cut.
Every requirement earns its place
Where did this come from, and what does it serve?
A requirement that can't say where it came from and what goal it serves is usually someone's pet feature in disguise. So every one has to point backward to a source and forward to the outcome it moves.
Backward: this requirement traces to a real document or a named working session — a human said it. Forward: it traces to one of the agreed outcomes — it actually helps.
A requirement that traces to nothing gets challenged on the spot. And a special trap: the client's original hiring document is evidence, not a requirements list. Anything that traces only to that document and was never confirmed by a person is a candidate, not a commitment.
The traceability check claimed one casualty: a requirement for SMS notifications that traced to nothing — no document, no session, no stakeholder.
"It came from the boilerplate appendix of the RFP — the hiring document — and no human ever confirmed it."
"Cut on day 5; recorded in the explicit not-in-v1 list so the choice is visible, not silent."
The hiring document feels authoritative, so its every line gets treated as a requirement. But Phase 0 already proved the client's own documents contradict each other. Untraced lines are leads to confirm, not orders to build.
Go deeper — the full method
Traceability means every requirement points backward to its source (a document or a named session) and forward to the outcome it serves. A requirement that can say neither is usually someone's pet feature wearing a requirement costume, and it gets challenged on the spot.
On day 5 the traceability check verifies that every top-priority requirement traces both ways. The traceability matrix — requirement → source and requirement → outcome — is populated for the top tiers by the Quality Engineer.
The RFP is evidence, not a baseline. Requirements that only trace to the RFP and were never confirmed by a human in elicitation are candidates, not commitments — Phase 0's contradictions already proved the corpus disagrees with itself.
A fresh pair of eyes, on purpose
Have someone who didn't write it try to break it
The people who wrote the requirements share the same blind spots that produced them. So before the phase closes, fresh reviewers — who didn't write a word of it — attack the whole set from the product, quality, and security angles.
The review hunts for the things authors can't see: conflicting requirements, missing failure paths, unstated assumptions, regulatory gaps. It's adversarial by design — the goal is to find the holes now, cheaply, instead of in production.
For the top-priority items, this is also where error behavior gets nailed down: what each operation accepts, what it returns, and what it does on every way it can fail. That's where most confident-wrong builds get prevented.
The day-5 review produced two catches the authors had missed because they shared the draft's blind spots:
"The acknowledgment requirement had no plan for a bounced email — against a state rule that demands a written acknowledgment. Added a postal fallback."
"A 'recommend' fast-path could let a claim sit unconfirmed past the regulatory clock. Fixed by adding the clock to the fast-path's escalation rule."
Go deeper — the full method
The people who wrote the requirements share the same blind spots that produced them. So on day 5, before the phase closes, a structured adversarial review runs: fresh eyes — a review agent that did not write the draft, plus the Quality Engineer — challenge the set from product, quality, and security angles, hunting for conflicting requirements, missing error paths, unstated assumptions, and regulatory gaps.
For the top two priority tiers, error behavior is spelled out explicitly: what each operation accepts, what it returns, and what happens on each failure mode. This is where most confident-wrong builds get prevented — an agent that knows exactly what to do on a bounce, a not-found, or a stale read cannot improvise the wrong thing at 2 a.m.
Now watch the whole thing happen
The week, end to end
You've got the ideas; here's the actual rhythm at Harbor. The week is front-loaded with conversation — the open questions, the working sessions, the full draft — and back-loaded with verification — the priority cut, the checks, the review, the gate. Five days, assuming Phase 0 did its job. Step through it.
Close the loose ends, draw the map
The two questions Phase 0 carried forward come due — and both get answered the same day: every channel gets the 15-day acknowledgment clock (one state needs it in writing), and 61% of claims turn out simple enough to fast-track. The AI drafts a candidate map of the work — six big slices — and the Pod Lead corrects it and plans the sessions.
Draw the requirements out of the people who do the work
Five working sessions, the right person in each room. Crucially, not just the managers: the intake clerks reveal a duplicate-claim workaround nobody had documented — the same loss reported by phone and portal gets two claim numbers today. By evening, the AI has structured the notes into 31 candidate requirements, each traced to its source.
The complete draft — and what it exposes
The AI produces all 31 requirements plus 7 quality targets, each with a real way to measure it. One target exposes the storm-surge gap nobody had named. The decision list regenerates — nine open product calls for Luis — and the testability conscience sends five vague lines back to be sharpened. A 30-minute sponsor checkpoint keeps the day-5 review from holding surprises.
The product owner does the cutting
The 90-minute priority session: a 12-slot budget, 19 candidates, Luis ranking within it and cutting seven. The work gets sequenced by what moves the goal first. Stories get written under each slice with real, named stakeholders — no invented users. And the top-priority items get their error behavior spelled out in full.
Break it, check it, sign it
The traceability check cuts the untraced SMS requirement. Fresh reviewers attack the set and find two real holes. The automated gate check runs clean. The AI drafts the handoff to the design phase — decisions, open questions, risks, a recommended starting point. The product owner confirms the requirements say what he meant; the sponsor sees the not-in-v1 list with her own eyes. Sign-off. The engagement advances — billing milestone.
Go deeper — the full method
The default calendar is 5 business days — one week, assuming Phase 0 did its job (a signed problem statement, a verified metric, resolved contradictions, a working PO arrangement). It stretches to 8–10 days when the epic count is large, the domain is heavily regulated, or proxy mode adds ratification latency. The week is front-loaded with conversation and back-loaded with verification.
- Day 1 — handoff intake and the elicitation plan. The pod works the open questions Phase 0 carried forward (each with an owner and a "this week" due date). Claude drafts the candidate epic map from the Phase 0 artifacts — 4–8 epics, each traced to one of the three outcomes — and the Pod Lead corrects it and plans one elicitation session per epic area. If the success metric could not be read end-to-end, the instrumentation epic goes on the map first. Orchestrators start the read-only feasibility spikes the handoff flagged.
- Day 2 — elicitation. Working sessions with domain experts and the PO, one per epic area, 60–90 minutes each, run by the Pod Lead. The people interviewed are the ones who live the work — the intake clerk knows the duplicate workaround; the manager knows the org chart. By end of day, Claude has structured the notes into draft functional requirements with stable IDs and source traces.
- Day 3 — the full draft and the decision list. Claude produces the complete draft: functional requirements with acceptance criteria, plus NFRs each carrying a measurement basis. The decision list regenerates and the PO starts working it on the 2-business-day clock (now the phase's critical path). The Quality Engineer runs the testability pass. A 30-minute sponsor checkpoint reads the draft epic map and emerging scope-out, so nothing at the day-5 review is a surprise.
- Day 4 — priorities and stories. The 90-minute priority session, PO driving, ranking within the announced top-tier budget. Epics get sequenced by which moves the metric first. User stories are drafted under each epic with real stakeholder justifications — no fabricated personas. For the top two tiers, error behavior is spelled out. Feasibility spike results land and anything they contradicted gets reconciled.
- Day 5 — verification, review, and the gate. The traceability check; a structured adversarial review; the automated gate check (placeholders fixed today); Claude drafts the Phase 2 handoff (summary, decisions with rationale, numbered open questions with owners, design risks, recommended starting point). At the phase review the PO confirms the requirements say what they meant and the sponsor sees the scope-out list. Sign-off recorded; the engagement advances; the first biweekly steering is scheduled.
The PO can't keep the 2-day clock → escalate to the sponsor by name; the clock is in the SOW. Elicitation keeps finding new epics past 8 → the outcome is too broad; take it to the sponsor as a scope conversation, not a longer phase. Proxy mode → add 2–3 days for decision-log ratification and batch the log for one sponsor session.
How it goes wrong
The failure modes, and the defense against each
Every one of these has happened to someone. Knowing them by name is half the defense — and Harbor's structure caught several of them in the act.
| The trap | What it looks like | The defense | At Harbor |
|---|---|---|---|
| Everything is top priority | Every requirement gets stamped "must-have" and the plan means nothing | A hard budget for the top tier; the product owner ranks within it. | Held — 19 candidates, 12 slots, 7 cut |
| Design in disguise | "Shall use a queue," "shall be microservices" written as if it were a requirement | Rewrite as the behavior that motivated it. Phase 2 chooses the how. | Behaviors only; no technology named |
| The hiring doc as gospel | Every line of the RFP treated as a committed requirement | It's evidence, not a baseline. Untraced lines are candidates. | Caught — SMS line cut on day 5 |
| The untestable line | "Intuitive," "robust," "fast" — nothing you can verify | The vague-line test, enforced before the line can stand. | Caught — 5 of 31 sent back |
| Quality-target theater | Impressive numbers nobody can ever actually read | Each target names where the number gets measured. | All 7 carry a measurement basis |
| Only hearing managers | Every session attendee has "manager" in their title | Talk to the people who live the process daily. | Caught — clerks found the dupe workaround |
Go deeper — the full method
Every one of these has happened to someone. Knowing them by name is half the defense:
- Everything is P0. Priority inflation is the default state of nature. The defense is a budget for the top tier, enforced in the priority session — the PO ranks within it, and the pod refuses to start a phase where the budget is blown.
- Design wearing a requirements costume. "Shall use a queue," "shall be built on microservices." Each forecloses Phase 2 before it starts. Rewrite as the behavior that motivated it.
- The corpus treated as requirements. The RFP is evidence, not a baseline. Requirements that only trace to the RFP and were never confirmed by a human in elicitation are candidates, not commitments.
- The untestable criterion. "Intuitive," "robust," "fast." The vague-line test exists for exactly this, and the QE's testability pass is the enforcement point, not the build loop three weeks later.
- NFR theater. Non-functional requirements with no measurement basis are wishes. If nobody can say where the number will be read, the NFR is not done.
- Silent proxy drift. In proxy mode, the pod starts making product calls without logging them — each one a liability that surfaces at the worst time. The decision log is cheap; the month-six dispute is not.
- Elicitation that only hears managers. The people who live the process know where the bodies are buried. If every attendee has "manager" in their title, the requirements describe the org chart's beliefs, not the work.
- The decision-list stall. The PO's clock slips, the pod fills the silence with guesses, and Phase 1 quietly becomes proxy mode without the rider. Escalate the clock breach instead — it's in the SOW precisely so this moment has teeth.
When Phase 1 is done
You have a list precise enough to build from — and a list of what you won't
Requirements doesn't end in a wish list. It ends with a buildable set of behaviors, each with the checks that prove it, ranked within a budget, traced to the goal — and an explicit record of what's out, seen by the person who'd otherwise ask "I assumed that was included" in month four. Where to go next: