The death of the PRD-as-document.

There is a notary in a small office on the second floor above the medicine shop in Sutrapur. The desk is wooden, lacquered three times since the seventies, with a rubber stamp with a brass handle resting on a red ink pad and a register bound like a ledger, where every page begins with the date in Bangla and the year in Roman. Kazi saheb has been stamping documents in that office for 35 years. The seal is the same stamp with the brass handle he was given on the morning of his first appointment in 1991. What has changed, page by page in the register, is the kind of document the stamp lands on.

I have been thinking about Kazi saheb's register for a year, because the product requirement documents I see being written in the agentic teams I work near have started to behave like the printouts people bring in after clicking through some agreement on a Sunday afternoon. The PRD is still produced, still routed for review, still pasted into the bottom of a Jira epic the way the printout is still folded into the manila envelope the customer carries out of the office. It is treated, by everyone who is being honest about it, as paperwork. The thing the team is actually contracting against has moved.

The PRD was a real artifact in 1995. The world it described was a waterfall world. Requirements were gathered in March, locked in April, designed in May, built across June and July, tested in August, and released in October to a customer base that had agreed in writing that this was what would be built. The document was the thing everything else leaned on, because every downstream rite, the design spec, the test plan, the user acceptance script, was a translation of the same set of requirements through a different professional vocabulary. The PRD was the contract those translations all signed off on. Like Kazi saheb's stamp on a 1991 kabin-nama, it certified that the parties had agreed.

That world is mostly extinct in the kind of software I write near. The team that ships an LLM feature facing the customer in 2026 does not first agree on a document of thirty pages and then build to it across two quarters. They agree on a tight set of capabilities the system must demonstrate on the eval suite, write the prompts and the retrieval against those capabilities, and watch the trace logs in production for the first week to see whether the agent is doing in the wild what it did on the bench. The artifacts the team is actually contracting against, by that point, are the eval set, the prompt, and the trace, with the long PDF parked in a Jira ticket that approximately no one will return to.

The shift was named, in the older idiom, more than five years ago. Marty Cagan had been writing about the death of the PRD since at least 2019, on the grounds that the document had stopped being a useful coordination artifact the moment teams started discovering customer behaviour iteratively rather than declaring it in advance. The argument was correct on its own terms, and it was about empowered product teams rather than agents. The current accelerant is different. What has finished the PRD off as the artifact carrying the real weight is not the empowered team but the executable spec, which now exists in a form the document never could.

The eval set is the part of the new spec that takes over the PRD's old job of saying what the system must do. The pass rate on quotes grounded in retrieval, the row for refusal calibration, the line checking whether a tool call's arguments have the right shape, the latency budget against the percentile that matters to the customer; each is a row on a card that the build server regrades on every push. Hamel Husain has been arguing for two years that the eval is the only honest unit of progress in an LLM product, and the field has, more or less, conceded, which is why the eval set is what the team pulls up in the Wednesday review while the PRD sits in the ticket where it was filed.

The prompt is the part of the new spec that takes over what the old design document used to do, which was to specify the system's behaviour at the level of how it speaks. A 2018 design spec used to say "the system shall respond to a successful order lookup with a confirmation message containing the order number and the expected delivery date." A 2026 prompt, in roughly the same number of words, says "when the customer asks about an order you have just looked up, confirm the order number, give the expected delivery date in the customer's local idiom, and do not promise anything the order system hasn't returned to you." The prompt is shorter, more honest about its own ambiguity, and, crucially, it is the actual artifact the model reads. The PRD was a translation step that the model has skipped.

The trace is the part of the new spec that takes over what the user acceptance test plan used to do, which was to record what the system did in the hands of a real customer at the end of the chain. A 2009 UAT script was a Word document with 38 rows and a screenshot column. A 2026 trace is a sequence of model calls, tool invocations, retrieved chunks, and final tokens, captured by an observability layer the way a structured log was captured by Datadog a decade ago. The trace is what gets read when something has gone wrong in production at half past nine on a Sunday night. Nobody, in that moment, opens the PRD.

There is a temptation, when an artifact dies, to declare the seal that used to land on it dead as well. The PRD as a document being on its way out does not mean the function the PRD performed has gone. Somebody on the team still has to write down, in language the lead for customer success and the compliance officer and the next PM can both read, what the system is supposed to do and why. That writing is now distributed across the README of the eval repository, the comments inside the prompt file, the dashboard label on the trace panel, and the migration note attached to the model version. It is the same craft as writing a PRD, paid the same respect on the team, and read by more people more often than the PRD ever was, because the executable artifacts force the reader back to the prose every time they fail.

The thing the executable spec cannot do, and the thing the older PRD was at its best at, is record the why across long stretches of time. An eval row tells you the system is currently passing on quotes grounded in retrieval, but it says nothing about why that row was chosen as the one that mattered back in March of last year, when the team spent two weeks arguing between three different framings of the same capability. A prompt shows you how the model is currently told to speak, not which six earlier prompts were tried and discarded first, or what got learned from each attempt. And the trace only tells you what happened in production, never what the team had hoped would happen, which is the only thing the actual behaviour can honestly be judged against.

This is the part of the PRD that still wants writing down somewhere, and where the discipline has not yet settled on a clean form. The best teams I work near have started keeping a thin log of decisions beside the eval repository, in the spirit of the architecture decision records Michael Nygard's old post described, with one entry per real decision, dated, and never edited once it's written, only added to. The entry is two paragraphs at most, recording what the team had decided that week, which two or three alternatives had been ruled out and on what grounds, and which named people had been in the room when the call was made. It is, in a workable sense, the PRD's surviving sentence, with the remaining 29 pages of the old document quietly retired to the archive folder.

I run no codebase of my own in 2026; the work that pays me is mostly steering small agentic teams through the same realisation, one Wednesday after another, that the document they are arguing about is not the document the system is reading. The PMs who survive the transition most cleanly are the ones who let the artifact running thirty pages shrink down to a README of one page at the top of the eval repository, and let the executable artifacts carry the rest. The PMs who fight the shift are still printing the long PDF, still walking it to the steering committee. They keep finding that the engineer in the next room has already shipped against the eval row, the prompt file, and a trace dashboard the steering committee will never see.

Kazi saheb was still in the office above the medicine shop when I visited in March. The ledger has changed three times since his appointment and the current one is bound in green canvas, bought for him from Nilkhet by a nephew in 2023. The stamp is the one from 1991, its brass handle dulled by 35 years of palm oil and rosewater. He has no opinion about LLMs and would not pretend to have one.

What he does have is a division of labour that the discipline of product has not managed yet. The document a visitor carries up the stairs belongs to the visitor. It changes every year, it arrives in whatever form the parties have agreed on, and he does not much care what is in it. The register belongs to him, it does not change, and every line in it is a fact about who stood in that room and what they said they meant. So he reads the page, identifies the parties, watches them sign, and lands the stamp once, with the year in Bangla in the upper right corner.

Then he closes the ink pad with the small click the office has been making since the Ershad years.

Ask him which of the two matters more and he would look at you as though the question were badly formed, because in his line of work the answer settled itself sometime before either of us was born. Ours has taken about twenty years to start guessing at it, and we are still mostly printing the document.