Every product manager I know writes PRDs with AI now. If yours doesn't, that's the bigger problem — the tooling is here, it's good, and the productivity gap is real.
But look at what actually happened. The PRDs got longer.
More sections. More edge cases. More user stories, acceptance criteria, personas, and appendices. Each document is more thorough than anything a PM would have hand-written two years ago. And somewhere in the middle of all that thoroughness, the developers quietly stopped reading them.
You've probably seen it on your own team. The engineer opens the doc, scrolls, scrolls again, and then walks over to ask: "So what am I actually building?" The PRD answered that question. It just buried the answer under thirty other things.
This is the inversion I want to talk about. AI should have made PRDs shorter and sharper. Instead it made them longer and softer. And I don't think that's what any of us intended.
Why longer happened
Writing used to be expensive. Think about shooting on film versus digital. When every frame cost money to expose and develop, you composed the shot before you pressed the shutter. You waited. You chose. Digital made each frame free, and we all started spraying — hundreds of shots to find the one we used to get in three. The cost wasn't a limitation. It was a filter.
Writing a PRD was film. When every paragraph took real effort, you thought hard about which paragraphs earned their place. Length forced prioritization.
AI made writing digital. Producing detail is now nearly free, so we produce more of it. The constraint that used to force us to choose — this matters, that doesn't — is gone. We stopped choosing. We just generated.
The problem is that the developer's attention didn't get cheaper. It's the same as it ever was.
Cognitive science has a boring, stubborn finding here: working memory holds about four items at once. Not four pages — four things. A developer scanning a forty-section document for "what do I build, and what are the boundaries" is doing unpaid archaeology. Studies on developer experience put the cost of poor documentation at 15 to 25 percent of engineering capacity, and a fair share of that isn't missing information — it's information you can't find fast enough to use.
More words did not add signal. They buried it.
"But agents need more detail"
Here's the counter-argument, and it's a good one, so I want to take it seriously.
We're moving toward a world where PRDs aren't written for human developers at all. They're written for AI agents that read the spec and build directly from it. In that world, more detail is genuinely better. An agent can't infer scope from what you left out. If you don't say "don't touch the auth flow," it might touch the auth flow. Silence, to a machine, is not a boundary — it's an invitation.
I fully agree with that direction. Non-goals stated positively, constraints made explicit, context handed over instead of assumed — that's the future, and it's coming faster than most teams are ready for.
But two things are true at once.
First, we're not there yet. Today, humans still read these documents. Your developers read them. Your designers read them. Optimizing a PRD purely for a machine, right now, means writing something your actual team can't use — and your actual team is who ships this quarter.
Second — and this is the part people miss — more words is the wrong answer for the machine too. The model vendors say so themselves. OpenAI's own guidance for its coding models tells you to avoid overly detailed prompts. Cursor found that "maximize context" prompts made the model too cautious and slower to act. Practitioners running frontier agents report that instruction-following degrades once you pile on too many rules. Over-specification doesn't make an agent more precise. It makes it hesitant, literal, and prone to convoluting a simple task.
So the length problem isn't a human problem that agents will solve. It's the same mistake in two costumes. Writing more serves neither reader. The fix isn't length. It's structure.
The real problem: one blob, two readers
Today, a PRD has two audiences. A human who needs to understand and decide, and increasingly an agent that needs context to execute. The failure mode almost every AI-written PRD falls into is trying to serve both with one undifferentiated wall of prose.
The human reader wants the decision. The agent wants the detail. When you braid them together into a single narrative, the human has to dig for the decision and the agent gets a diluted context. Nobody is served well.
So stop writing one blob. Separate the document by what each reader needs. I've been structuring PRDs in three layers, and it's changed how fast my teams move.
The Decision Layer. This is what a human should absorb in about sixty seconds. The problem, in two or three sentences. The one outcome that actually matters — not ten goals, one. What we are explicitly not doing this time. And the three to five decisions that constrain everything downstream. If a developer reads only this layer, they should know what they're building and why. Everything else is support.
The Detail Layer. Flows, edge cases, acceptance criteria, the corner conditions. This is the part everyone writes and nobody reads front to back — and that's fine, because it's not meant to be read front to back. It's meant to be retrieved. When a developer hits a specific question, they pull the specific answer. Write it to be searched, not to be recited.
The Context Layer. The context a machine needs and a human takes for granted. Non-goals stated positively ("do not modify X"). Hard constraints. Pointers to the live systems, schemas, and existing patterns the agent should conform to. Today this layer helps whoever is vibe-coding a prototype. Tomorrow it's most of what you hand to an autonomous agent. Either way, isolating it means you're not smuggling machine-context into the human's decision path.
The governing principle underneath all three: write for retrieval, not for reading. A PRD is no longer a document you read cover to cover. It's a structured source you query. Design it that way.
Two smaller rules that do a lot of work. One outcome, not a menu of goals — if everything is a priority, you've delegated prioritization to whoever reads it, and they'll guess wrong. And state boundaries positively — never rely on omission to communicate scope, because neither a tired developer at 5pm nor an agent at any hour will read your silence the way you meant it.
Where this connects
Regular readers will see the thread to something I've written about before: agency is a budget, not a switch. A PRD is where you set that budget. Every decision you nail down is interpretation you're keeping. Every gap you leave is interpretation you're delegating — to a developer, or to an agent. The three-layer structure just makes that allocation visible instead of accidental. When you can see what you've locked and what you've left open, you're deciding how much judgment to hand off. When you can't, you're handing it off by accident.
That's really the whole point. The bloated PRD isn't over-specified. It's un-specified in the places that matter, padded everywhere else. It has the volume of a decision and the clarity of a suggestion.
The bridge, not the destination
I want to be honest about what this is. It's not the spec-driven endgame everyone's writing about. It's the on-ramp.
The teams betting entirely on PRD-for-agents are building for a world that isn't fully here. The teams still shipping forty-page docs are optimizing for a world that's already gone. The practical move today is the one in between: a document a human can act on in sixty seconds, with the detail and machine-context separated cleanly enough that handing the right layer to an agent later is a copy-paste, not a rewrite.
AI didn't have to make our PRDs worse. It made writing free, and we mistook free for good. The fix isn't to write less because writing is cheap, or more because agents are hungry. It's to write with structure — so the human finds the decision fast, the agent gets clean context, and the length of the document finally stops standing in for the quality of the thinking.
The best photographers shooting digital didn't get sloppy just because frames went free. They kept composing the shot. That's the discipline worth carrying over. Shorter isn't the goal. Sharper is. Length was never the thing we were paying for.