The PRD Didn't Die. It Just Stopped Being for Engineers.

A few months ago I noticed that the engineers had stopped reading my PRDs.

Not in a rude way. They'd open the document, skim it, nod along in the meeting, and then go work out of Jira – which is where the epics and stories live, and where the actual technical shape of the thing gets argued out. The PRD wasn't failing them. It just wasn't for them, and I think we'd all quietly worked that out before anyone said it.

The people reading it closely were everyone else. A marketing lead who needed to know what we were promising before she promised it to anyone. A sales director who wanted to know which customer this was for. Designers, who needed the why before they could make anything that served it. An executive who was about to fund the thing and reasonably wanted to understand why this bet and not one of the other four.

So my PRDs changed. They got less technical and more business-focused – the why, the hypothesis, who we're serving, what we expect to happen, and which alternatives already got considered and rejected. The technical details moved into epics and stories, because realistically that's what engineers work from, and because I don't want executives and marketers down in the weeds of the how.

I thought that was a small local adjustment to how I work. Then July happened.

Two frontier product teams moved the same line

On July 26th, Dianne Penn – Anthropic's first technical product manager, now head of product for their AI Research and Labs teams – described her team's operating principle on Lenny's Podcast: "we do write some product documents and PRDs, but we actually have a saying on the team of evals are the new PRDs."

That quote traveled fast, mostly with the first half sanded off. What her team does instead of writing requirements is generate 30 to 40 representative examples of the thing working, encode them as prompts with golden answers, and use that eval set as a standing checkpoint before releases. Lenny Rachitsky's summary put the split plainly: a PRD describes what to build, an eval defines what success looks like once you've built it. And then the part that got dropped in the retelling – "PRDs still exist, though, particularly for aligning large groups across engineering, legal, and safety."

Meanwhile at Meta, product exec Jagjit Chawla described a PRD that had compressed down to one paragraph describing the problem, coupled with a prototype. "For ML-heavy areas, add an eval set."

Read those two together and the obvious headline is wrong. Nobody killed the PRD. Anthropic still writes them for cross-functional alignment, Meta still writes them at one paragraph, and both organizations took specification out of the document and moved it closer to the people doing the building – into evals, into prototypes, into the ticket. Then they kept the document anyway, for the thing it was left holding.

Both of them, separately, kept the alignment.

The category error

"The PRD is dying" is the wrong sentence. It was never primarily a specification, and treating it as one is most of why it was miserable to write and boring to read.

Think about who a real specification serves. It's for the person building the thing, and it has to be precise enough that they can act on it without guessing. That's a genuinely useful artifact, and it's also the artifact most likely to be stale within a week, most likely to be argued with, and most likely to live better in a ticket next to the code than in a document next to the roadmap. Engineers were always going to end up working from Jira. AI just made the drift impossible to ignore, by making specification cheap to generate and easy to encode as a test.

What's dying is the pretense. For twenty years we wrote a document that claimed to be a specification while doing most of its real work as a briefing, and then we graded it against the standard it was pretending to meet instead of the one it was quietly meeting. And then we wondered why it felt like paperwork.

The division I've settled on, and I'll argue it: product owns the Who, the What, the When, and the Why. Engineering owns the How and the Where. Who we're building for, what we're building, why it's worth building, when it needs to exist – that's product leadership's work, and engineering shares only a sliver of the What. Architecture, hosting, how it gets built, how it's made fast – that's engineering's, fully.

I've watched a lot of managers try to pull engineers into the Who and the Why, usually described as including the team so they can contribute their creativity. Occasionally that's real. Most of the time it's a manager handing off the hard part – the deep understanding of the user, their problem, and whether a solution is worth building at all – to people who didn't sign up for it and who, if they'd wanted it, would have become product managers.

A PRD that carries the Who and the Why isn't a diminished spec. It's the document doing its actual job, finally without apologizing for it.

Why the dashboard version worries me

The part of the Meta story that got the most attention wasn't the compressed PRD. It was the morning dashboard – an agentic system that replaced a lot of manual up-the-chain reporting, and that took about six months of tuning before Chawla trusted what it told him. It's genuinely impressive work solving a real problem at a scale most of us will never touch.

It also worries me as a replacement.

A number is clear to you because you're already holding all the context it sits inside – the belief about the user, the outcome you're chasing, the reason it's this measure and not some other one. Your team isn't holding any of that. Hand someone a number without its context and you've handed them a quiz they don't know they're failing.

A leader who owes their team clarity is an interpreter, not a translator. A translator swaps words, which is why machines mangle idioms. An interpreter sits between two people with no shared language, works out what the first one is genuinely trying to say, and rebuilds that meaning inside the second one's language – which takes fluency in both languages, the subject, and the surrounding context, all at once.

The quantitative is the last link in a long chain of thought, the part that finally got small enough to fit inside a cell on a spreadsheet. Hand people only that last link and you've given them the answer to a question they never heard you ask.

That's not a worry about Meta, who clearly still do the interpretive work somewhere. It's a worry about the teams reading about Meta. Delete the document and keep the dashboard and you've kept the last link and thrown away the chain. Your engineers will be fine – they've got the tickets. Your marketing lead, your sales director, your designers and your board have just been handed a number and asked to reconstruct twenty pages of reasoning from it.

What to do with this

If you write PRDs, the useful question isn't whether to keep writing them. It's which of the two jobs your document is currently doing badly.

Start by asking who actually reads it. Not who's on the distribution list – who reads it closely enough to change what they do afterward. If that's mostly engineers, your specification is probably in the wrong container, and it wants to be in tickets, or a prototype, or an eval set that defines what good looks like before anyone builds toward it.

If it's mostly everyone else, and in my experience it is, then stop grading the document on precision and start grading it on whether a smart person with none of your context can read it and come away understanding why this bet, for whom, and what you expect to happen. That's a harder document to write than a spec. It's also the one that decides whether anything moves after you hand it over.

The hardest part of my job has never been working out what to build. It's getting a room full of people who weren't in the research to run at the thing with conviction once we hit ready-for-design, which means walking them through a journey they didn't take and showing them that the alternatives they're about to suggest were already considered and rejected for reasons. Every month I spend closer to that problem, the more the PRD looks like the right tool for it, and the less it looks like a spec that lost an argument with Jira.

The marketing lead, the sales director, the designer, the executive about to fund it – they were reading it all along. It's finally being written for them.