The status report read green. Every task in the milestone was checked off. The plan document was thorough — three pages, stakeholder names in the right columns, dependencies listed. It had been drafted by an AI in minutes, the PM had cleaned it up, and it looked exactly like what a finished milestone looks like.
The milestone was not done. The user acceptance criterion — a working demo of the checkout flow in the staging environment, signed off by the product owner — had never been attempted. The tasks were closed; the exit criterion was unmet. Nobody had noticed, because no one had written it down as the thing that actually had to be true.
This is the specific failure that floods PM work now that AI makes plans, status updates, and risk logs nearly instantaneous to produce. The output looks complete. The checklist is empty. The goal is not met.
This post applies AI-Driven Development — a method built for software — to project management. The translation is direct, because the failures are identical. (The framework post at ADD Beyond Code covers the universal form; this post spends its words on the PM translation.)
The four failures, in PM language
The four AI-era failures from the original ADD method appear in project delivery under their own names.
Fast waste. AI generates a plan or status update that looks finished but is built on assumptions nobody confirmed. A milestone plan with a vague definition of done, a status report with no supporting artifact — both read as complete and both hide the gap. The AI sprints through the template; the gap survives review.
Context rot. The baseline plan, the stakeholder sign-off, the agreed scope — these live in email threads and the PM’s memory. A new AI session, a new collaborator, or simply next week re-guesses the constraints. Each re-guess accumulates invisible drift between what was agreed and what is being tracked.
Trust-by-inspection breaks down. A status update that reads “on track” is not evidence of progress. An AI-drafted risk log that identifies the right categories of risk is not evidence the risks were actually assessed. Plausible formatting is not verification.
Verification ceiling. As AI accelerates plan and report production, the PM’s capacity to verify the claims in those documents becomes the bottleneck. A portfolio of twenty AI-generated status reports cannot be read carefully in ten minutes — and skimming for plausibility is not review.
The loop, translated
0 · Ground: the project’s actual state
Before the AI drafts anything, it loads the real project context: the signed charter, the baseline plan, the per-milestone exit criteria, the dependency map, and the open risk register. This is not aspirational documentation — it is the current state of the project as it actually is, including dependencies that have slipped and scope that has drifted.
A PM who skips Ground gets AI output aimed at a project the AI imagined. Ground aims the output at the project as it is.
1 · Specify: what the milestone must deliver
The brief for a milestone is not a task list. It names what the milestone must deliver, what it must not allow, and the after-state that proves the milestone is complete. Each refusal is paired with a named code so the AI can invoke it when it detects a violation.
# MILESTONE SPEC — M4: Checkout Flow Ready for UAT
Must: - Deliver a working checkout flow in the staging environment covering the three user journeys defined in scope-doc v2.1 - Provide a recorded walkthrough artifact for the product owner - Obtain signed UAT acceptance from the product owner before the milestone is marked complete
Must NOT: - Mark complete without a signed acceptance artifact [EXIT-CRITERIA-UNMET] - Add payment method types not in scope-doc v2.1 [SCOPE-CREEP] - Proceed past UAT gate if a P1 defect is open [EXIT-CRITERIA-UNMET] - Treat a closed task count as evidence of delivery [STATUS-WITHOUT-EVIDENCE] - Ignore an outstanding dependency on the payment gateway cert [DEPENDENCY-IGNORED]
After-state: Signed UAT acceptance on file; staging environment passes the three UAT scenarios; no P1 defects open; payment gateway cert dependency resolved or formally deferred with owner named.The refusal codes — EXIT-CRITERIA-UNMET, SCOPE-CREEP, DEPENDENCY-IGNORED, STATUS-WITHOUT-EVIDENCE — are the PM’s vocabulary for escalation. The AI uses them in status output when it detects the condition. The PM uses them in conversation with stakeholders when a boundary is being pushed.
2 · Scenarios: three cases every milestone needs
One scenario for the model path (everything proceeds as planned), one for an edge (a dependency slips), and one for the failure that status theater hides.
Model case. All tasks complete; the demo is recorded; the product owner reviews it, raises a minor defect, the team fixes it within the sprint, and the product owner signs the acceptance form. The milestone closes.
Edge case. The payment gateway certificate is delayed by two days. The PM invokes DEPENDENCY-IGNORED to surface the dependency formally, logs it in the risk register with an owner and a resolution date, and adjusts the milestone’s completion window. Status correctly reads “at risk — dependency: payment gateway cert” rather than “on track.” The milestone does not close until the dependency resolves.
Failure case. Every task is checked off by end of sprint. The AI drafts a status update: “M4 complete — all tasks closed.” The product owner was never given the demo. No acceptance form exists. The exit criterion was EXIT-CRITERIA-UNMET from the moment the sprint ended. The dynamic goal-loop (below) exists precisely for this case: the milestone reopens, the demo task is resurfaced, and the status rolls back to “in progress” until the criterion is met.
3 · The frozen contract: the baselined plan
The one human gate is stakeholder sign-off on the baselined plan — including the per-milestone exit criteria. This is the moment when the plan stops being a draft and becomes the governing document. Changes after baseline are change requests: they require a new stakeholder decision, a new sign-off, and a new version of the plan.
The PM owns this gate. The AI can draft and revise the plan as many times as needed before baseline. After baseline, it cannot change the scope, the exit criteria, or the milestone definitions without a human decision on record. This is what prevents scope creep from accumulating invisibly in the plan document itself.
4 · Acceptance checks: the milestone’s red tests
Before work begins, write the exit criteria as checkable conditions — not tasks, not deliverables, but the observable outcomes that must be true for the milestone to close. These are the project’s equivalent of failing tests. They are written before the work exists, and they fail by default until the evidence arrives.
# EXIT CRITERIA CHECKLIST — M4: Checkout Flow Ready for UAT# Status: OPEN (failing) — updated as evidence arrives
[ ] Staging environment accessible and stable (uptime > 99% for 24h prior to UAT) Evidence required: monitoring dashboard screenshot with timestamp
[ ] All three UAT scenarios executable without critical blocker Evidence required: recorded walkthrough video (link in delivery notes)
[ ] Product owner UAT sign-off obtained Evidence required: signed acceptance form (PDF attached to milestone record)
[ ] No P1 defects open at milestone close Evidence required: defect tracker export showing zero P1s open
[ ] Payment gateway certificate dependency resolved or formally deferred Evidence required: cert installed (confirmation from infra lead) OR deferral record with named owner and new target date
[ ] Scope matches scope-doc v2.1 (no unrequested additions) Evidence required: PM sign-off that no SCOPE-CREEP codes were invoked and resolved without stakeholder approvalA milestone is not done when the checklist of tasks is empty. It is done when every item in this checklist is checked and the named evidence artifact is on record. A task list can empty while this list stays open — and the dynamic goal-loop keeps the milestone open until the list closes.
5 · Produce: AI drafts plans, updates, and risk logs
With the spec and exit criteria fixed, the AI does what it is fast at: drafting the milestone plan, generating status update templates, producing risk log entries, writing stakeholder summary emails. The how of drafting is unconstrained. The PM chooses the format, the level of detail, the tone. The AI produces a draft; the PM reviews it against the spec and the exit criteria.
Constrain the what — the exit criteria and the refusal codes. Free the how — the drafting. Verify the result through evidence, not by reading the update and finding it plausible.
This is the reframe that makes AI useful in delivery rather than dangerous. The PM is not reading the status update to see if it sounds right. The PM is checking whether each claim in the update is backed by a named artifact in the exit criteria checklist.
6 · Verify by evidence: artifact-backed status
Status verified by evidence looks different from self-reported green. The difference is specific and checkable.
| Self-reported green | Evidence-backed status | |
|---|---|---|
| Source of 'done' | Task count closed in the tracker | Exit criteria checklist complete with artifact links |
| How the PM confirms | Reads the status update; it sounds right | Checks each criterion against a named artifact |
| A slipped dependency | May not appear if no task covers it | Surfaces as DEPENDENCY-IGNORED; milestone stays open |
| UAT not yet done | 'All tasks complete' hides it | EXIT-CRITERIA-UNMET holds the checklist open |
| What 'green' means | The checklist of tasks is empty | Every exit criterion is met and the evidence is on file |
| Durability | Invisible in a week; no audit trail | Artifact links and sign-offs remain queryable |
The adversarial technique here is the refute-read: take a status report that reads green and actively try to find the unmet criterion underneath. Ask specifically: Is the exit criterion met? What is the artifact? Where is the sign-off? A status update that cannot answer these questions in thirty seconds is not done — it is status theater.
The dynamic goal-loop is the mechanism that enforces this. A milestone does not close when its task list empties. It closes when its exit criteria checklist completes. If tasks are closed but criteria are open, the loop surfaces the gap: the relevant tasks reopen, the status rolls back to “in progress,” and the next status cycle begins against the same exit criteria. The checklist is the engine, not the task count.
7 · Observe and fold: retro learnings into the next plan
After a milestone closes, the PM runs a structured retrospective: What did the exit criteria catch that the task list would have missed? What new risk patterns emerged? Were any refusal codes invoked repeatedly — and if so, does the next project’s spec need a stronger default on that boundary?
The findings fold back into the plan templates and the PM’s playbook. A recurring DEPENDENCY-IGNORED pattern becomes a standing dependency review in every milestone’s checklist. A stakeholder who consistently pushes scope past the frozen contract becomes a named governance note in the briefing template. The playbook stays living — not a document signed once and growing stale, but a set of templates that carry the lessons from the last delivery into the next one.
Constrain the what, free the how
The PM’s job is to own the exit criteria and the frozen contract. Every other choice — how the plan is formatted, how the AI drafts the status update, how the dependency log is structured, what tool tracks the tasks — is unconstrained. A PM who spends energy on those choices while leaving exit criteria vague has inverted the job.
The concrete form: before the AI drafts the milestone plan, the PM writes the exit criteria checklist. The AI then drafts the full plan around those criteria. The PM reviews the plan for completeness against the criteria, not for whether the plan sounds good. If the criteria are met by the plan’s delivery, the milestone is done. If they are not, the plan is incomplete regardless of how thorough it looks.
What does not transfer
Stakeholder politics. An exit criterion and a refusal code do not resolve a stakeholder who disagrees on scope. The PM’s judgment in navigating that conversation is irreducible and cannot be systematized.
Motivation and team dynamics. A milestone spec does not surface that a team member is overloaded or disengaged. The plan is not the delivery; it is a model of the delivery. The gap between them is filled by people, and people are not governed by specs.
Genuine ambiguity. Some milestones are exploratory — the exit criterion is not knowable until the work reveals what is possible. Forcing an evidence-backed exit criterion onto a discovery phase produces false precision. The spec should mark these milestones explicitly as open-ended, with the exit criterion being a structured summary of findings rather than a demonstrated capability.
Over-proceduralizing kills judgment. A PM who responds to every stakeholder request by invoking a refusal code rather than thinking will produce conflict without insight. The codes are vocabulary for escalation, not a substitute for reading the situation. The method works when the PM is exercising judgment inside a clear structure, not when the structure is executing in place of judgment.
Next in the series
The next post takes this same method one level up: ADD for Engineering Leadership — how engineering managers use exit criteria, evidence-backed status, and the dynamic goal-loop to run portfolios rather than projects, and what changes when the PM is also responsible for the people doing the work.