The PRD Lifecycle: Five Statuses From Draft to Superseded

Most specs carry a status, and a surprising number of those statuses are wrong. The PRD marked "In review" that was approved in June. The one marked "Approved" that was built differently, or not built at all. The one called "Final" that has been replaced twice.

A status is a promise to the reader about what they can do with the document: comment on it, build from it, quote it to a customer. That is why a wrong status does more damage than a missing one. It gives a stale page the authority of a current one.

Five statuses cover the life of most specs. The names matter less than the PRD workflow around them: what moves a spec from one status to the next, and who is allowed to move it.

The five, and what each lets a reader do

Status	What it means	What a reader may do
Draft	The owner is still deciding	Comment if asked. Do not build from it.
Review	Decided enough to attack; named reviewers have a deadline	Comment, raise blockers
Approved	The commitment is made	Build from it. Propose amendments.
Built	Shipped, and reconciled with what actually went out	Cite it for how the feature works
Superseded	Replaced, in whole or in part, by a newer document	Follow the forward link

The right-hand column is the useful one. Two questions get asked constantly by people who were not in any meeting: can I build from this, and can I quote this? Every status should answer both.

What moves a spec forward, and who moves it

Draft to review: the owner, when there is something to attack. Not when it is finished. A spec is ready for review when the problem, scope, exclusions and states are written down and the open questions are listed as questions. The pre-read ask goes at the top. The owner makes the move because only the owner knows whether the remaining gaps are deliberate.

Review to approved: the approver, not the author. The move happens when blockers have been closed by the people who raised them, through resolution rules everyone knows, and sign-off is recorded: who signed, for what, on which version. If authors can mark their own specs approved, the status records the author's confidence, which nobody needed recorded.

Approved to built: the owner, when it ships. Ships means released to the people it was for, not merged. Before making the move, the owner reconciles the spec with what shipped. Anything that changed during the build and never made it back into the document gets written in now, so that "built" means "describes the product".

Built to superseded: whoever writes the replacement. When a later spec changes the behaviour, the person getting the new spec approved marks the old one superseded and adds a forward link at the top. That is part of the new spec's job, not a cleanup task for later, because later does not come.

The backward move

Specs go backwards less often than people fear. The distinction that matters is between a change and a reset.

Most changes are amendments, and they leave the status alone. A limit moves, a state gets added, a permission rule is clarified. The spec stays approved. The change goes into the document with what changed, why and who agreed, and the people who signed for that section re-sign. Approval fixes the commitment, not the text. Changing a spec mid-sprint shows the change block those amendments go in.

A reset is when the premise breaks. The customer segment turns out to be wrong, the dependency will not ship this year, the metric was measuring the wrong thing. Then the spec goes back to review, explicitly, with a line saying why, because what people approved is no longer what they would be building.

Teams that treat every change as a reset stop changing their specs. Teams that treat a broken premise as an amendment build the wrong thing with a clean audit trail.

One exit that is not superseded

Some specs never get built: a draft that dies in review, an approved spec whose priority evaporated. These need a terminal status too, because an approved spec nobody built reads, from search, exactly like one that is about to be.

Call it withdrawn, with one line saying why and a link to the decision log entry if the reason is worth keeping. "Withdrawn 14 Nov: segment moved to the enterprise plan, see decision log" saves the next person with the same idea from rediscovering why it stopped.

Where the status lives

On the first line of the document. Not in a properties panel, a database column or a tracker nobody opens. Where a PRD should live makes the case: a reader who arrives from search should know within two seconds whether they are in the right place.

An illustration of a status line that does the job:

APPROVED · v3 · 9 Oct · Owner: product lead · Approver: head of product
Changes since approval: 2 (listed below)

And for a replaced spec:

SUPERSEDED IN PART, 2 Mar: §3 (delivery) replaced by "Scheduled exports v2".
Sections 1, 2 and 4 still describe current behaviour.

That second block is among the most useful sentences in a documentation system and among the least often written. Partial supersession is the normal case. A later spec changes the delivery rule and leaves everything else standing, and a reader needs to know which half to trust.

About the PRD tracker

Teams often want a PRD tracker: one view of every spec and its status. It is worth having, on one condition. It reads the status from the documents; it does not hold its own.

A tracker with its own status column is a second source of truth, and it drifts from the documents the first week someone forgets to update it. The spec says approved, the tracker says review, and the reader trusts whichever they found first. If your tool can build the view from a field inside each document, use that. If it cannot, a plain list of links with no statuses beats a list with stale ones.

The same goes for the ticket tracker. A ticket's status says whether a piece of work is done. It says nothing about whether the spec behind it is still current.

The second reader cares too

Specs are now read by tools as well as people: assistants that pull context from past documents, generators that draft from what a workspace already contains. Our generator reads the workspace Brain, meaning past docs, decisions and team standards, before it drafts. Any tool doing that has the same problem a new hire has. A superseded spec, unmarked, looks exactly like a current decision.

A status on the first line is cheap context for both readers. It is the difference between "we decided this" and "we decided this, then changed our minds in March".

Signs your statuses have stopped meaning anything

• Most specs are in draft, including ones that shipped.
• Approved specs exist that nobody built and nobody withdrew.
• Specs marked built describe a version of the feature that never shipped.
• Two documents both claim to be current for the same feature.
• Nobody can say who is allowed to move a spec to approved.

Each one has the same fix: decide who makes which move, and attach the move to an event that already happens. The review closing, the release going out, the replacement being approved. A status change that depends on someone remembering to do it later will not happen.

FAQ

What are the stages of a PRD? Draft, review, approved, built and superseded, plus withdrawn for specs that are never built.

Who moves a PRD to approved? The accountable approver, once blockers are closed and sign-off is recorded. Not the author.

Does changing an approved PRD send it back to review? Only if the premise breaks. Ordinary changes are amendments, written into the document.

Should PRD status live in a tracker or in the document? In the document, on the first line. A tracker should read it from there.