When an AI writes the code, the hard part isn't writing it. It's knowing what to build — and being sure it's the right thing.
Phase 0 is where you find that out, before a single line gets written.
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
Why Phase 0 exists
An AI agent can produce a working feature in an afternoon. That speed is only an advantage if the feature is the right one. Build the wrong thing quickly and you've just arrived at the wrong place sooner.
So the most valuable move at the start isn't to build — it's to make sure everyone agrees what "done" means, that the goal can be measured, and that the client's own documents don't quietly contradict each other.
A wrong assumption caught in week one is a twenty-minute conversation. Caught in month three, it's a rebuild — because real code now depends on it. Phase 0 trades a little time now for a lot of rework avoided.
Harbor had already lived this. An earlier attempt to modernize the same system was cancelled in its sixth month — it launched with no internal owner, and the real integration work wasn't discovered until month five.
"Cancelled in month six. No single internal owner; integration scope only surfaced in month five."
Phase 0 is the countermeasure: surface that scope in week one, not month five.
You build the wrong thing precisely — a polished, well-tested solution to a problem nobody actually had.
Go deeper — the full method
An AI coding agent can produce a working feature in an afternoon. That speed is only worth anything if the feature is the right one. Build the wrong thing quickly and you have simply arrived at the wrong place sooner — and now real code depends on the mistake. Phase 0 is where the engagement makes sure it is solving the right problem before a single line gets written.
Phase 0 answers four questions, and nothing else:
- What problem are we solving, and how will we know we solved it? One measurable metric — not a feature list.
- Who decides product questions during the build? The PO decision.
- Can we legally and technically work? Tooling, access, the data boundary.
- What constraints are non-negotiable? Technical, regulatory, organizational.
Everything that looks like requirements, design, or planning is deliberately out of scope. That work has its own phases. Pulling it forward before these four answers exist is how engagements end up building the wrong thing precisely — a polished, well-tested solution to a problem nobody actually had. A wrong assumption caught in week one is a twenty-minute conversation; caught in month three it is a rebuild, because real code now depends on it.
Anything built before the four answers exist gets rebuilt once the answers arrive. Pulled-forward work is not a head start — it is rework with a delay.
The rule that governs everything
The one rule
Claude drafts and interrogates; humans decide and own. This single sentence is the spine of the whole method. The AI does the reading, the summarizing, the questioning, and the first drafts. People make every decision and carry the accountability. A machine reports; a named human signs.
Phase 0 applies the rule at its strictest: the AI never invents the problem. What the project is actually for is written by a human, full stop.
- Claude reads every document, finds the contradictions, lists the open questions, writes the first drafts.
- People decide what the problem is, settle the contradictions, choose the measure of success, and correct & sign the drafts.
Drafting is cheap; truth is expensive. So the humans spend their time on is this true? — not on typing.
Claude drafted Harbor's problem statement from the workshop notes — and framed it as a claims-team efficiency problem, because that's what the documents emphasized.
On day 5, hearing it read aloud, the sponsor stopped and corrected it:
"Adjusters are overloaded; the goal is to make the claims team more efficient."
"Customers leave when claims drag. This is about renewals — roughly $3.4M a year."
The AI produced the draft; a human owned the truth.
Go deeper — the full method
One sentence is the spine of the whole method: Claude drafts and interrogates; humans decide and own. The AI does the reading, the summarizing, the questioning, and the first drafts. People make every decision and carry the accountability. A machine reports; a named human signs.
Phase 0 is the phase with the strictest human-in-the-loop rule in the whole standard: the problem statement is human-authored. Claude never invents the problem. What the project is actually for is written by a human, full stop. What Claude does do, heavily:
- Document intake. The corpus is ingested on day 1–2: per-document summaries, a registry with DOC-NNN IDs for traceability, and a contradiction list ("the RFP says X, the architecture deck says Y").
- Interrogation. Before the workshop, Claude generates the question list from the corpus — gaps, ambiguities, unstated assumptions. After the workshop, it generates the decision list: every decision the humans have not made yet, named explicitly.
- Drafting. Every artifact is drafted by Claude from human-generated raw material (workshop notes, interview notes), then corrected by the Pod Lead and ratified by the sponsor. Drafting is cheap; the humans spend their time on whether it is true.
What Claude is not in the room for: the workshop itself and the interviews. Those are human conversations. Claude preps the questions going in and structures the notes coming out. The mandatory human stops in this phase are two: problem framing is human-authored, and the phase advance is a named human sign-off.
Claude reads every document, finds the contradictions, lists the open questions, writes the first drafts. People decide what the problem is, settle the contradictions, choose the measure of success, and correct & sign the drafts.
The cast for the two weeks
Who's involved
Phase 0 is deliberately thin on our side — two people plus Claude. The weight sits on the client: the sponsor who owns the outcome, the data owner who can produce the number, and the people who actually live the problem every day.
A small pod by design. Two named humans carry the work, and Claude drafts under them — never deciding.
- Pod Lead — runs the workshop and interviews, owns every artifact's content, gets the sponsor's signature.
- Setup Owner — chases access, the repo, and the data-flow brief, so the slow plumbing never holds up the phase.
- Claude — reads the corpus, surfaces contradictions, writes first drafts. Drafts, never decides.
The rest of the cast is the client's — and the hardest to book is usually the data owner. Get them on the calendar first.
Pod
- Maya Chen — Pod Lead
- Rob Feld — Setup Owner
- Claude — drafts, never decides
Harbor
- Karen Voss — VP Claims Ops, the sponsor
- Luis Ortega — Claims PM, the eventual PO
- Priti Shah — BI lead, the data owner
- Dan Kowalski — IT Security
- Gail Tran & Marcus Webb — senior adjusters
- Dee Alvarez — intake supervisor
Go deeper — the full method
Phase 0 is deliberately thin on our side. Most of the pod is not yet billing; the work is two people running two parallel workstreams, with Claude doing the reading and drafting.
Our side
| Person | Load | Workstream |
|---|---|---|
| Pod Lead | 60–80% | Understanding — the workshop, stakeholder interviews, every artifact's content, the decision list, sponsor sign-off |
| Setup Owner | 40–50% | Enablement — Anthropic procurement, repo and access checklist, the data-flow brief to client security, the empty delivery repo with the engagement structure initialized |
| Quality Engineer | ~10% | One job: vet the success criteria for measurability ("what query, on what system, produces this number?") |
| Orchestrators | 0–10% | Not yet staffed, or assisting document intake; they arrive for real in Phase 1 |
If the engagement is multi-pod from the start, the Engagement Lead runs Phase 0 once for the engagement; pods do not run separate discoveries.
Client side
| Person | Needed for | How much |
|---|---|---|
| Sponsor (owns budget and outcome) | The workshop, the PO decision, phase sign-off | Workshop half-day + two 30-min checkpoints |
| Candidate PO | The workshop; the PO-mode commitment decision | Workshop + one conversation |
| Security / IT | Anthropic procurement, repo access, data-flow brief review | Hours, but with lead time — engage day 1 |
| Domain experts (2–4 who live the problem) | Interviews in week 1 | 45–60 min each |
| Ops / data owner | Verifying the success metric is actually readable | One working session |
The hardest person to get is usually the data owner. Book them early — an unverifiable success metric is the most common Phase 0 failure.
What the two weeks must answer
The four questions
Everything Phase 0 produces exists to answer exactly four questions. Each is non-negotiable, and each has a specific way of going wrong when you skip it.
- What problem, and how will we know we solved it? A problem and one number — not a feature list.
- Who decides product questions during the build? Someone client-side has to own the daily calls.
- Can we legally and technically work? Tooling, access, and what data the AI sees.
- What's non-negotiable? The constraints that can't be designed away.
- Customers leaving at renewal; success = median days from claim to decision (11.4 today).
- Luis Ortega, the Claims Product Manager — 6 hours a week.
- Cloud is Azure-only; customer data stays inside Harbor's own tenant; AI access under Harbor's account.
- The once-a-night core system stays; two states mandate a 15-day acknowledgment clock.
It feels productive to start sketching requirements or architecture now. Don't. Each has its own phase, and anything built before these four answers exist gets rebuilt once the answers arrive.
Go deeper — the full method
Everything Phase 0 produces exists to answer exactly four questions. Each is non-negotiable, and each has a specific way of going wrong when it is skipped.
- What problem are we solving, and how will we know we solved it? A problem and one number. The success metric is a single measurable thing, not a deliverables list. If the answer names a system instead of a number, it is a feature list wearing an outcome costume.
- Who decides product questions during the build? Once building starts, product questions arrive every day. Someone client-side has to own the daily calls — a named PO with committed hours, or a signed proxy arrangement. This is the PO decision, and it carries billing teeth.
- Can we legally and technically work? The AI needs a contract and keys, and the client's security team needs a written answer to one question: what data does this thing see, and where does it go? Tooling, access, and the data boundary — settled before anyone opens a terminal.
- What constraints are non-negotiable? The technical, regulatory, budget, timeline, and political facts that cannot be designed away. Each gets recorded with a rationale and a fixed-or-negotiable flag.
It feels productive to start sketching requirements or architecture now. Don't. Each has its own phase, and anything built before these four answers exist gets rebuilt once the answers arrive.
The technique that earns the phase
Reading the documents against each other
A client hands over a stack of documents written by different people at different times. They disagree constantly — and those disagreements are exactly where the project's biggest risks are hiding.
The AI doesn't just summarize the pile. It reads it against itself, finding every place document A says one thing and document B another.
A contradiction isn't an embarrassment — it's a decision nobody realized they had to make, surfaced while it's still cheap. Each gets sized two ways: how much it matters (blocks the goal, or just nudges a design choice?) and where it's answered (a quick email, or a decision that needs the right people in a room).
Reading Harbor's eight documents against each other surfaced four contradictions. The one that earned the phase:
"Real-time claim decisions at the moment a claim is reported."
"Records sync only once a night; during the day you see yesterday's data."
"Same-day decisions for v1; real-time deferred. Caught on day 3 — not month 3."
Go deeper — the full method
A client hands over a stack of documents written by different people at different times: RFPs, prior vendor docs, API specs, strategy decks. They disagree constantly — and those disagreements are exactly where the project's biggest risks are hiding. Claude does not just summarize the pile; it reads it against itself.
On day 2, the most tool-dense day of the phase, every corpus document is cataloged with a stable ID (DOC-001, DOC-002…). The Pod Lead reviews the catalog and sets priorities — which documents matter most, which to skip. Claude then writes a budgeted summary per document (capped by priority so the whole corpus stays loadable in one later session), a human-readable registry, and a condensed index that loads at the start of every later session. The catalog is locked once complete, so document references stay stable all the way into requirements traceability.
A fresh analysis agent — one that has not been part of the conversation so far — then compares the documents against each other and produces two artifacts:
- The contradiction list (CON-01, CON-02…) — every place the documents disagree, each entry carrying two verbatim quotes with their sources, a severity rating, and the question a human must answer to resolve it.
- The question list (Q-01, Q-02…) — everything no document answers, grouped by workshop agenda block.
Each item is sized two ways. Severity: does it block an outcome, or merely shape a design choice? Routing sends each question one of three ways — workshop (only the room can answer it), pre-workshop (answerable by email before day 3, sent the same day so room time is spent only on what the room can uniquely answer), or interview (better asked one-on-one on day 5).
A contradiction is not an embarrassment. It is a decision nobody realized they had to make, surfaced while it is still cheap to make it.
The one measure of success
The success metric
"Reduce processing time by 30%" sounds like a goal. It's worthless if nobody can produce today's processing time. A target with no readable baseline is a wish.
The success metric must be read live from a real system, with the current number written down and its source named. Promised isn't good enough; proven is the bar.
And if the number can't be produced? That's not a footnote — it's a finding. Either the metric changes to something measurable, or "build the measurement" becomes the very first job of the next phase. Decided now, not discovered in week nine.
The team sat with the data owner and produced the number on screen, from the real report:
They even caught that the report's label was wrong while its underlying number was right — something you only see by actually running it.
Everyone nods along to a goal nobody can measure. Months later there's no way to tell if the project worked. That's why proving the metric is a whole day's work.
Go deeper — the full method
"Reduce processing time by 30%" sounds like a goal. It is worthless if nobody can produce today's processing time. A target with no readable baseline is a wish. The success metric must be read live from a real system, with the current number written down and its source named. Promised is not good enough; proven is the bar.
On day 6 the pod sits with the client's data owner and actually runs the query, opens the
dashboard, or pulls the report the metric will be read from — and records the baseline
number in success-criteria.md with its source named. The Quality Engineer then
vets every success criterion: baseline, target, measurement method, reading cadence.
If the number cannot be produced, this is a Phase 0 finding, not a footnote. Either the metric changes to something measurable, or "instrument the metric" becomes the first epic of Phase 1 — decided now, not discovered in week nine.
Everyone nods along to a goal nobody can measure. Months later there is no way to tell if the project worked. That is why proving the metric is a whole day's work.
Who answers the daily questions
Who decides (the PO)
Once building starts, product questions arrive every day. There are two honest ways to handle who answers them — and one dishonest way that quietly poisons the engagement.
- Named-owner mode — the client commits a person, with hours, who answers within a couple of business days.
- Proxy mode — no owner available, so the pod decides on the client's behalf, logs every call, and the client ratifies the log at each check-in.
- × "We'll figure it out as we go" — proxy mode by accident, with no agreement and no log. The worst of both. The workshop forces the choice out loud.
Harbor committed a named owner:
6 hours a week · product decisions answered within two business days
Because this is a contract precondition, the build clock couldn't start until it was settled — no shrugging it down the road.
Go deeper — the full method
Once building starts, product questions arrive every day. There are two honest ways to handle who answers them — and one dishonest way that quietly poisons the engagement. The workshop forces the choice out loud, and the answer is recorded in writing so it is durable.
- PO mode. The client commits a named PO at ≥ 4 hours/week with a 2-business-day decision turnaround. Triage invitations go on their calendar and the PO onboarding guide is delivered.
- Proxy mode. No owner is available, so the pod answers day-to-day product questions itself under a signed rider, logs every decision, and the client ratifies the log at each steering meeting.
- × "We'll figure it out as we go." Proxy mode chosen implicitly, without the rider and without the decision log — the worst of both modes. The workshop agenda exists to prevent exactly this.
The decision is finalized on day 7 as a PO decision record: the mode chosen in writing, with the PO named and their calendar commitments captured, or the rider signed and the decision log created with ratification added to the steering agenda. Because this is an SOW precondition with billing teeth, the build clock cannot start until it is settled — there is no shrugging it down the road.
Can we even work here?
Tooling & the data boundary
The AI needs a contract and keys, and the client's security team needs a clear, written answer to one question: what data does this thing see, and where does it go?
- Default — the client procures access under their own agreement; keys live in their vault; their contract, their audit trail.
- Fallback — if procurement is slow, start under our keys with the client's written consent and a fixed date to migrate to theirs.
- High-compliance — the AI runs inside the client's own cloud tenant, for the strictest environments.
Harbor took the default path:
The fallback sat ready the whole time, just in case procurement slipped. It didn't.
Live access (or a signed fallback) is a condition of closing Phase 0. The next phase doesn't begin without it.
Go deeper — the full method
The AI needs a contract and keys, and the client's security team needs a clear, written answer to one question: what data does this thing see, and where does it go? The data-flow brief answers it; the access path settles the keys. There are three paths.
| Path | When | How it works |
|---|---|---|
| Default | Normal case | The client procures Anthropic access under their own agreement; keys live in their Key Vault; the pod runs on client-issued seats. Their contract, their audit trail. |
| Fallback rider | Procurement stalled | The firm's keys under a signed client consent rider, with a named migration date to move to client keys as soon as procurement lands. |
| High-compliance | Strict tenancy needs | Claude runs inside the client's own Azure tenant (Foundry). Verify model availability and Claude Code compatibility at Phase 0 before promising it. |
Live access under the client's account — or a signed fallback rider — is a precondition of closing Phase 0. The next phase does not begin without it, and because billing is gate-based, an unresolved tooling state on day 10 is the client's problem to unblock, not the pod's to absorb.
Now watch the whole thing happen
How the two weeks unfold
You've got the ideas; here's the actual rhythm at Harbor. Two streams run in parallel the whole time — one chasing understanding (the workshop, the metric, the artifacts), another chasing enablement (access, the repo, the data boundary) — so the slow, waiting-on-other-people work never holds up the phase. Step through it.
Get both clocks running
A short kickoff explains how the work will run. The client hands over everything they've written about the problem. In parallel, the slow things start today — getting AI access approved and repo access sorted — because those wait on other people.
The AI reads everything
Every document gets cataloged and summarized. Then a fresh pass hunts for contradictions and unanswered questions. The cheap questions go out by email the same day — no need to spend a meeting on them.
The one meeting that must happen in a room
Three hours, the right people, no AI in the room. The contradictions get settled, the real problem gets named in the sponsor's own words, and the single measure of success gets chosen.
Drafted by the AI, corrected by a human the same day
The problem statement, the success measures, and the constraints get drafted from the workshop notes — then corrected while everyone's memory is fresh. Drafts age badly.
The cheap-correction point
Talk to the people who live the problem daily, then read the draft problem statement aloud to the sponsor. This is where "that's not actually the problem" surfaces — and at Harbor it did: what looked like an efficiency problem was really about customers leaving. The single most valuable correction of the phase.
Produce the number, live
Sit with the data owner and actually run the report on the real system. Read the starting number off the screen and record it with its source. A promised metric isn't good enough.
Write the thing the sponsor will sign
A short identity document for the project — what it is, what done means, the goal, the constraints. Kept short enough that the sponsor will actually read it. And who owns product decisions gets put in writing.
Access goes live; the repo becomes home
AI access turns on under the client's own account. The project repository is created inside the client's organization, and everything produced so far moves into it. From here, the repo is the only home.
The machine checks the work
Automated checks run over everything; anything incomplete gets fixed. Any still-open questions are written down to carry forward. A plain-language summary is prepared for the sponsor's review.
A signature, and the meter starts
A 45-minute review: the project's identity, the metric with its proven starting number, the constraints, the ownership decision, the open questions. The sponsor signs. The phase closes and the build can begin — the first billing milestone.
Go deeper — the full method
The default calendar is 10 business days. The constraint is rarely effort — it is lead time on the client side (procurement, security review, calendars). The two workstreams, understanding and enablement, run in parallel the whole way so that lead-time waits never idle the phase.
Before day 1 (no billing): the SOW is signed with the Phase 0 preconditions in it; the workshop is scheduled for day 3–4 (getting the sponsor, the candidate PO, and the right domain experts in one room is the long pole); and the document corpus is requested — "everything written about this problem, unsorted is fine."
Week 1 — understand
- Day 1, kickoff. A 60-minute kickoff: introductions and the how-we-work briefing (the build loop, the gates, what the client sees biweekly, what we need from them and when). The Setup Owner opens the enablement workstream with client IT — Anthropic procurement started, data-flow brief handed to security, repo/access checklist issued. The corpus is received; intake begins.
- Day 2, intake and prep. The most tool-dense day. Claude catalogs every document, then a fresh agent produces the contradiction and question lists. The cheap (pre-workshop) questions go out by email today. The workshop brief is drafted by Claude, curated by the Pod Lead down to one page, and sent personally — Claude never sends anything to the client.
- Day 3, the outcome workshop (the anchor event). Half a day, humans only, run by the Pod Lead: the problem in the sponsor's words (45 min); the three outcomes — business, software, capability, each one sentence (45 min); the one metric with its baseline and named source system (30 min); constraints (30 min); the PO decision, forced explicitly (20 min); and tooling status with the fallback trigger date agreed (10 min).
- Day 4, first drafts. Claude drafts
problem-statement.md,success-criteria.md, andconstraints.mdfrom the workshop notes; the Pod Lead corrects them the same day, because drafts age badly. Claude generates decision list v1 — every unmade decision the workshop surfaced or dodged. - Day 5, interviews and the first checkpoint. Stakeholder interviews with the people who live the problem daily, not just the people who fund it; contradictions with the sponsor's framing get flagged, not smoothed over. Then a 30-minute sponsor checkpoint reads the draft problem statement out loud — the cheap-correction point, where "that's not actually the problem" surfaces on day 5 rather than day 50.
Week 2 — verify and close
- Day 6, the metric gets proven. A working session with the data owner runs the query live; the baseline is recorded with its source named. If the number cannot be produced, it becomes a finding. The Quality Engineer vets every criterion.
- Day 7, constitution and the PO decision land. Claude drafts
constitution.md— the project's identity document, kept short enough that the sponsor actually reads it. The PO decision is finalized in writing: PO mode or proxy mode. - Day 8, enablement converges. The tooling checkpoint with teeth: Anthropic access goes live, or the fallback rider is invoked today — not "next week." The delivery repo exists in the client org and all Phase 0 artifacts move into it; from today the repo is the only home. The access checklist is closed out or escalated to the sponsor by name.
- Day 9, the gate run. Claude drafts
phase1-handoff.md; the automated gate check runs against the artifacts and any placeholder content or missing sections gets fixed today; the narrative companion for the sponsor is generated. - Day 10, phase review and sign-off. A 45-minute review walks the constitution, the metric with its verified baseline, the constraints, the PO decision, and the open questions. The sponsor signs the outcome statement; the human sign-off is recorded; the engagement advances to Phase 1. This is billing milestone 1.
Procurement stalls → invoke the fallback rider on day 8 as planned; don't extend the phase waiting. The workshop can't be scheduled inside week 1 → move the phase start, don't stretch it, since billing is gate-based. Useful idle time → deepen intake, draft syntheses, prep the Phase 1 workspace. What the pod never does is start Phase 1 work early "since we're waiting" — requirements built on an unsigned problem statement get rebuilt.
How a phase actually ends
The gate
A phase doesn't end because two weeks went by. It ends when a specific list is true and a named human signs to advance. Automated checks confirm the mechanical parts; a person owns the judgment. Gates report; humans decide.
These gates are also the billing milestones — the moment a phase closes is the moment that work is accepted and paid for. That's what gives two of the checklist items below their weight.
If a teeth item isn't met on the last day, the phase doesn't close — and because billing is tied to the gate, that becomes the client's problem to unblock, not the pod's to quietly absorb.
At Harbor's gate run, the automated check found one problem — a leftover placeholder in the constraints file. It was fixed, the check re-ran clean, and the next day the sponsor signed.
The full checklist — tick it:
- The automated checks pass — every artifact exists, is complete, has no leftover placeholders
- The sponsor has signed off on what the project is and what success means
- The success metric was read from its real source, and the starting number is recorded
- Who owns product decisions is settled in writing
- AI access is live under the client's account, or the fallback is signed
- The project repository exists in the client's organization, with everything committed
- Every still-open question is written down, numbered, with an owner
- A named human has approved the move to the next phase
Go deeper — the full method
A phase does not end because two weeks went by. It ends when a specific list is true and a named human signs to advance. Automated checks confirm the mechanical parts; a person owns the judgment. Gates report; humans decide. Phase 0 closes when all of these are true, verified at the day-10 review:
- The automated gate checks pass: artifacts exist, are complete, contain no placeholders.
- The sponsor signed the outcome statement (constitution).
- The success metric was read from its source system at least once, baseline recorded.
- The PO decision is in writing — named PO with calendar commitments, or signed proxy rider. (billing teeth)
- Anthropic access is live under the client's account, or the fallback rider is signed. (billing teeth)
- The repo exists in the client org with artifacts committed; the access checklist is closed.
- The handoff document carries every open question, numbered, with an owner.
- A named human (sponsor side) approved the advance.
These gates are also the billing milestones — the moment a phase closes is the moment that work is accepted and paid for. Two of the items are SOW preconditions with billing teeth (the PO decision and tooling). If either is unresolved on day 10, the phase does not close, and the SOW's gate-based billing is what makes that the client's problem to unblock rather than ours to absorb.
How it goes wrong
How it goes wrong
Every one of these has happened to someone. Knowing them by name is half the defense — and Harbor's structure caught two of them in the act.
| The trap | What it looks like | The defense | At Harbor |
|---|---|---|---|
| A feature list in disguise | "Build an API, a portal, a dashboard" written down as if it were the goal | A real goal survives the feature list changing. If the sentence names a system, keep asking why. | Goal stated as renewals, not features |
| The unmeasurable metric | Everyone agrees to a target nobody can produce a number for | Produce it live, or change it. | Caught — the day-6 live run |
| The dodged owner | "We'll sort out who decides as we go" | The workshop forces the choice; the contract records it. | Luis named, in writing |
| Tooling drift | "Access will sort itself out next phase" | A hard checkpoint, with a fallback ready. | Signed day 8, fallback on standby |
| The sponsor who nods | A beautiful draft, skimmed and approved, wrong months later | Read it aloud; interview the people who live the problem. | Caught — the day-5 reframe |
| Discovery that won't end | Week four of "just two more interviews" | Four questions, not all questions. Open ones get carried forward. | Two questions handed to Phase 1 |
Go deeper — the full method
Named failure modes, because every one of these has happened to somebody. Knowing them by name is half the defense.
| The failure mode | What it looks like | The defense |
|---|---|---|
| The deliverables list wearing an outcome costume | The workshop produces "build an API, a portal, and a dashboard" instead of an outcome. | An outcome survives the deliverable changing. If the sentence names a system, keep asking why. |
| The unreadable metric | Everyone agrees on "reduce processing time 30%" and nobody can say what query produces the current number. | Day 6 exists for this. Produce it live, or change it; if the baseline can't be read, instrumenting it is Phase 1's first epic — decided now, not discovered in week 9. |
| The dodged PO decision | "We'll figure out product ownership as we go" — proxy mode chosen implicitly, without the rider, without the log. | The workshop agenda forces the question; the decision record makes the answer durable. |
| Procurement drift | "Tooling will sort itself out during Phase 1" — and the pod is three weeks in under our keys with no rider. | Day 8 is the hard checkpoint, with the fallback rider ready. |
| The sponsor who nods | Claude drafts a beautiful problem statement, the sponsor skims and nods, and on day 50 the problem turns out to be something else. | The day-5 checkpoint read out loud, plus interviews with people who live the problem — their disagreements are the most valuable finding Phase 0 produces. |
| Discovery that won't end | Week 4 of "just two more interviews." | Phase 0 answers four questions; it does not achieve certainty. Open questions go in the handoff, numbered, with owners — that's what the list is for. |