The PRD was a workaround. It existed because engineering time was expensive, misunderstanding was expensive, and the cheapest way to reduce both was to front-load thinking into a shared document passed from product to engineering. Every part of that premise has weakened. Engineering time is not cheap, but it is no longer the scarce resource. Misunderstanding still exists, but its cost has been collapsed by the ability to just build the thing and see. So for most work, kill it, and ship the replacement in its place.
What the PRD was actually doing
Before killing something, name what it did. The PRD was a container for five things: the problem statement, the proposed solution, the scope boundaries, the success criteria, and the open questions. Good PRDs did all five well. Most existed mainly so a product leader could approve something without having a real conversation with the team. Three of those five no longer need a document. Two still do, but not in PRD form.
The three artifacts
In every team I have run or advised since 2024, the replacement is the same three artifacts, none longer than a page, all producible in under a day for a typical feature.
The working prototype is the only one that is not optional. It answers three of the five containers at once: it demonstrates the problem by being built for a specific user, it is the solution in clickable form, and it collapses the scope question because the scope is whatever is in the prototype. It does not need to be production quality. It needs to be real enough that a customer can use it for five minutes and give feedback that is not polite, an engineer can tell you what is hacky, and a designer can tell you where the interaction is wrong. In Claude Code or Cursor the median time to this is four to six hours. Longer than that and the prototype is trying to do too much.
The eval rubric replaces the success criteria section. It is a scoring system, usually 1 to 5 on three to five criteria, applied to at least 20 test cases covering happy path, edge cases, and adversarial inputs, with a target threshold for ship. The rubric is both the spec and the acceptance test. Done is when the rubric passes.
The README holds the rest. One page: why in two sentences, what it is in one paragraph, out of scope as a bullet list, open questions with a specific owner each, and links. It is a navigation tool, not a plan.
What you gain
When I run this model with teams, five things show up within a quarter. Reviews get faster and better: a 20-page PRD takes 45 minutes and produces vague feedback, while a prototype, rubric, and README take 15 minutes and produce specific feedback. Scope creep drops because the prototype is a tangible boundary. Engineering trust goes up because a prototype is a serious signal a document is not. Customer feedback happens earlier. And your hiring changes, because PMs who can prototype get promoted faster.
Pick the smallest feature in your backlog. Before your team writes a PRD, describe it in Claude Code and ask for a prototype with a deploy URL, write a 10-line README, add the rubric if it is AI-driven, and share all three instead. Do it three times and going back gets hard.