Everyone's building faster than ever. But is anyone building the right thing?
There's a conversation happening across Slack channels, product forums, and LinkedIn threads right now. Teams are shipping in hours, not sprints. Engineers are prototyping from a prompt. PMs are being told to just build. And somewhere in the chaos, someone decided that the humble Product Requirements Document had finally had its day.
They're wrong. But they're not entirely wrong either.
What the PRD Was Built For
Cast your mind back to the waterfall era. Software development was expensive, sequential, and unforgiving. You had one shot. Requirements had to be locked before a single line of code was written, because rewrites cost months and budgets that most organisations simply didn't have.
The PRD was the answer. A single document — sometimes 30 pages deep — that captured everything. Purpose, features, user personas, functional requirements, non-functional requirements, assumptions, constraints, dependencies. The complete picture. As Ben Horowitz and David Weiden put it back in 1997, it was "the most important document a product manager maintains." A product Bible, shared with design, engineering, and marketing alike.
It was exhaustive because it had to be. Nothing could be left to interpretation. If it wasn't in the PRD, it wasn't in the release.
The document served a real purpose: it forced rigorous thinking upfront, created alignment across teams who might not speak again for weeks, and gave QA a testable, traceable specification. It was the blueprint before the build.
Why AI Is Changing Everything
Fast forward to now, and the assumptions that made the PRD indispensable have quietly collapsed.
The cost of building has cratered. What once took a sprint now takes an afternoon. Tools like Cursor, Lovable, and Claude Code have compressed the gap between idea and working prototype to hours. Teams are discovering requirements by building, not by speccing. Vibe coding — the practice of describing what you want in plain language and letting AI generate the code — isn't a gimmick anymore. Carnegie Mellon is teaching it. Google, Stripe, and Netflix are testing for it in PM interviews.
The old critique of the PRD — that it's a rear-view mirror document, built on historical research and assumptions that evaporate the moment a user touches the product — has only intensified. Agile was supposed to fix this. It didn't kill the PRD, it just made it shorter. AI is doing something more fundamental: it's collapsing the distance between thinking and shipping so dramatically that the very act of writing a requirements document can feel like it's slowing you down.
And then there's the LLM problem. Post-ChatGPT, something uncomfortable happened: PMs started using AI to generate PRDs. The result was exactly what you'd expect — bloated, verbose documents that said a great deal about nothing. Documents so padded with filler that engineers stopped reading them entirely. The PRD, already on the defensive, became a symbol of performative process rather than genuine alignment.
Some leaders responded by killing the format altogether. Build first. Write later. Ship and learn.
What the PRD Is Now
Here's the thing: the problem was never the PRD. It was what we put in it — and who we thought it was for.
The modern PRD isn't a specification manual. It's a clarity document. It's shorter, sharper, and written in plain language that excites the team as much as it informs them. It reads less like a legal contract and more like a well-argued pitch: here's the problem, here's who has it, here's what success looks like, and here's what we're not building.
In fact, AI has quietly made the PRD more important in one critical context: feeding AI coding tools. When you're using Cursor or Claude Code to build, the spec you provide determines the product you get. Garbage in, garbage out. Teams who ship slop aren't failing because they moved too fast — they're failing because they didn't define what they were building clearly enough before they let the AI run. The spec doesn't disappear in an AI-first workflow. It becomes the most consequential input in the process.
Some teams are calling this "context fuel." The idea is that AI agents need rich, structured, intention-clear information to generate accurate output. The PM's job isn't to write less — it's to write better. Tighter problem statements. Sharper user outcomes. Explicit scope boundaries. The format changes; the thinking doesn't.
OpenAI still considers the spec one of the most important documents a product team produces. The format has evolved. The function has not.
The PRD Is Changed — But More Important Than Ever
Let's be direct about what happens when you ditch the PRD entirely.
You get drift. Without a shared, written definition of success, every team member carries a different model of what's being built. Decisions get made in isolation. Features creep in that nobody asked for. The product that ships is nobody's vision — it's a composite of a hundred small, undocumented choices.
You get slop. AI will build what you describe. If you describe nothing — or describe it vaguely — you get something technically functional and strategically hollow. The vibe coding era hasn't made clarity optional. It's made it load-bearing.
You lose the customer. This is the one that stings. Speed is seductive. It feels like progress. But customers don't care how fast you shipped something they didn't need. The PRD, at its best, was always a customer document — a record of what the user needs, why they need it, and how you'll know when you've built it. Without that anchor, you're optimising for output, not outcome.
The teams winning right now aren't the ones who've abandoned specs. They're the ones who've learned to write better ones, faster. A sharp one-pager that captures the job to be done, the success metric, and the out-of-scope list is worth more than thirty pages of requirements nobody read.
The PRD didn't die. It had its jargon stripped away, its page count slashed, and its purpose clarified. It grew up.
Your job as a PM isn't to write less. It's to think harder and write only what matters — then make sure the AI, the engineers, and the customer are all pulling in the same direction.
That document has a name. It still matters.
Brendan Tack is a Product Manager and AI Strategist. He writes about product, AI, and building what actually matters.