A few weeks ago, a post landed in my feed making a bold claim: the Product Requirements Document is becoming obsolete. Evals are the new standard. PMs who can't write a scoring function are going to be left behind.
This caught my attention. After some digging, and a good team discussion, here's where I landed.
The claim that started it all
The argument wasn't subtle: PRDs are dead. Evals replace specs entirely. The PM who still writes requirements documents is already behind.
It's a provocative take. And it got my attention because there's something real in it. Evals offer a genuinely different way of defining quality. Instead of describing what good looks like in prose, you prove it with a number. You feed the system a range of real inputs, score the outputs, and land on a measurable quality bar before anyone writes a single line of code.
That changes something fundamental: the PM is no longer hiding behind "the spec was ambiguous." There's a score. Either it passes or it doesn't.
The claim is bold. But is it the full picture?
But not everything we build works that way
Here's where I think it overreaches.
Most products are still full of features where there's one right answer. A user logs in or they don't. A checkout processes or it fails. A meal gets logged to the right date or it doesn't.
For those features, a clear spec still works great. You write what the feature does, the developer builds it, and a unit test verifies it cleanly. An eval that produces a score of "0.74 on login quality" isn't telling you anything useful, because the question isn't fuzzy to begin with.
Replacing a PRD with an eval for deterministic features isn't progress. It's adding complexity where there isn't a problem to solve.
Two types of features. Two different tools.
This is really the crux of it. Once you split features into two categories, the whole thing gets clearer.
AI-powered features — where the output is open-ended, generated, or variable — need evals. Think an email assistant, a content summariser, or a smart notification system. There's no single correct output. Quality has to be scored, not checked.
Traditional features — where the output is deterministic — still need specs. Think login, checkout, and form submissions. There's one right answer. A spec describes it. A unit test confirms it.
The mistake is treating these as the same problem.
Let's talk about the PRD — because it's not dying, it's changing
Here's the counter-intuitive part. At the same time everyone is declaring the PRD dead, I'd argue it's actually becoming more important. Just different.
AI is now writing more of the code
When AI is generating code from your spec, the quality of that spec matters more than ever. A vague requirement doesn't get interpreted charitably — it gets filled in arbitrarily. You want the instruction set to be precise, not because a developer will read between the lines, but because the AI won't.
The thinking still needs to be sharp.
Prototypes are the new format
The other shift is in how specs get communicated. We're increasingly leading internal conversations with prototypes instead of written documents. Rather than describing what a feature should do, we show it.
Figma's team recently wrote about this too — they're seeing the same thing. And it works. A quick prototype built with AI tooling communicates intent faster and more clearly than three paragraphs ever could.
The "what" still matters. It just lives in something you can click through, not something you read.
The spec isn't dying — it's splitting into two
What this points to is not the death of specs, but a natural split in how teams will work.
Evals for AI-led features — to score quality before code gets written.
Prototype-led and AI-assisted specs for traditional features — to show rather than tell.
Two rhythms. Same product. Running in parallel.
Hero image: Photo by Mikhail Nilov on Pexels.