What a PRD was supposed to do
A product requirements document is a written description of what a product should do, why, and for whom. Product managers write it. Engineering reads it, interprets it, and turns the interpretation into code. Designers read it and turn it into screens. QA reads it and turns it into test plans. Everyone reads the same document; everyone builds a slightly different mental model of it.
That gap — between the document and the mental model — used to be filled by people. Engineers asked clarifying questions in standup. Designers pinged the PM in Slack. QA logged bugs when the interpretation diverged from intent. The PRD wasn't the source of truth. The humans reading it were.
Why PRDs fail in an AI-built world
Four things break the moment an AI agent joins the team:
- Interpretation drift. The PRD's ambiguity used to be resolved in hallway conversations. Agents don't ask; they guess. Every ambiguous sentence becomes a plausible-looking but wrong implementation.
- No verification loop. A PRD describes intent in prose. Prose can't be executed. There's no way to check, automatically, whether the code an agent produced matches what the PRD asked for.
- One-way handoff. PRDs flow from product to engineering and then die. When behaviour changes, the PRD isn't updated, because nothing depends on it staying accurate.
- Staleness by default. Six months in, the code is the truth and the PRD is fiction. New teammates read the PRD, form a wrong mental model, and start shipping bugs.
These problems existed before AI. Agents didn't create them — they exposed them. Fast code generation makes ambiguity expensive in a way that slow, human-only code generation never did.
From documenting intent to specifying behaviour
The shift isn't "write better PRDs." It's a change in what the artefact is for. A PRD documents intent for humans to interpret. A specification describes behaviour precisely enough that both humans and machines can act on it and verify it — the core idea behind spec-driven development.
The difference in one line: a PRD says what we want; a specification says how we'll know we got it.
What replaces the PRD
A specification that survives contact with an AI-built codebase has three layers:
- Structure. A product taxonomy — capabilities, features, journeys — so every requirement has a durable place. New behaviour slots into the map instead of scattering across docs and tickets.
- Context. Jobs-to-be-done anchor each capability to a real user situation and desired outcome. The why lives alongside the what, so agents (and new hires) don't have to guess.
- Verification. Behaviour-driven development scenarios describe expected behaviour as executable checks. If the code passes the scenario, it matches the spec. If it doesn't, you know exactly which behaviour drifted.
Together, these three layers do what a PRD tried to do — communicate intent — but with a property the PRD never had: the spec and the running software stay in sync automatically, or the tests fail.
What this looks like in practice
Executable is built around the artefact staying alive: the spec lives next to the code it describes and syncs with it, so it can't quietly rot into fiction the way a PRD does. You still need product judgment and a way to communicate direction — but the thing carrying that direction is durable, verifiable, and legible to the agents doing the writing.