The PRD Was Never the Point: Product Definition in the AI Era

Everyone is excited that AI can help write PRDs. Paste in a problem, get back a tidy doc with goals, user stories, acceptance criteria, the works. A few minutes. And it's fine. It's genuinely fine.

So why does it feel hollow?

Because the PRD was never the point. The document was always a stand-in for something else, and it helps to be honest about what it was actually doing for you.

It was a place to think. Writing it was how you organized your thoughts and got the whole bet out, the hypothesis, the problem you thought you were solving, the solution you were betting on. It carried the evidence, the receipts that said this is worth building. It carried the non-functional stuff, performance and security and scale, though for me those rarely survived that first phase, because the point was getting the bet out, not getting lost in detail yet. The detail surfaced later in the work tree, and the PRD never caught up. It implied the learning was over. These are the REQUIREMENTS, capital letters. Except the world doesn't hold still for that anymore. We're always in discovery now, so the doc went stale the second the work hit refinement, and almost no one went back to update it.

Recently I watched a team produce a great PRD. A few bullet points, but they nailed the bet, the what, and the evidence behind it, and that was enough. Some teams skip the doc entirely and work off a Miro board with a mock. For a tight team that sits together, that's often fine. The PM isn't being lazy. The doc is tedious, it eats time, and the team next to you doesn't always value it enough to justify the effort.

But all of it, the bullets, the board, the doc no one updated, leaned on the same crutch. The complete understanding never lived in the document. It got built in the gaps, in the questions engineering and design and support and sales asked you, in the "wait, did you mean this or that," in the Slack thread where someone pushed back and you realized you hadn't actually decided the thing you thought you had. The doc was the artifact. The understanding was the product. I've said for years that the truth lives in the code, and that's still true. But the understanding that produces the right code used to live in a person.

And that person is getting thinner.

The engineer was your error correction

When I talk to PMs, what lands is that the spec was always underspecified on purpose, and it worked because a competent engineer filled the gaps with taste. You'd write "users should be able to filter the list," and you never had to spell out the empty state, or that the filter persists across navigation, or that zero results shouldn't be a blank screen. Design already had a system that solved it, a platform component for filtering and sorting and moving columns that worked one standard way, and the team just adopted it. Writing that down would have been a waste, and probably wrong.

More than that, they pushed back. This conflicts with last sprint. This is three weeks, here's a version that's three days. They called out the component you should reuse and the things you forgot, performance, security, scalability, the integration that breaks if you build it that way. The spec started a conversation. The friction was the feature.

Now put an agent in that seat. Its whole demeanor is to tell you what a brilliant idea you have and then go build it. I feel pretty smart after some of my LLM sessions, right up until I remember it would have said that about almost anything I typed. I've had to tell mine to argue with me, because I want feedback, not flattery. It makes whatever assumptions it needs and moves forward. The human isn't gone, there's still an engineer reviewing the pull request, but that review checks whether the code works, not whether you defined the right thing. The agent already made a hundred small calls about what you meant before anyone looked. Sometimes it asks a clarifying question, inconsistently, and you can't build a process on hoping it does. Its default is to proceed. Vague in, wrong out, now at machine speed.

So the question stops being "can AI write my PRD" and turns into something harder. What does a definition contain when the thing reading it won't argue, won't get stuck, and will just confidently build the wrong thing? And the flip side, if I have AI generate a giant doc, is anyone going to read it?

I'm not suggesting you write more

The second you say definitions need to be more rigorous, people brace for the heavy spec, and they're right to. The spec is never done. You can't make it so complete that no two people read it differently. That's not a milestone, it's an asymptote. The job is doing enough without doing too much.

So I'm not suggesting you specify more. I'm suggesting you specify different things. The mistake of the heavy spec was specifying the how, pages of detail that went obsolete the moment refinement turned your requirement into work items, then tripled them to cover what the requirement got wrong. The how was always dev's to own. The good news is that's the part you can now hand to the machine, and your requirements can finally be smart about the how because you spent your effort on the why and the what instead.

"I expect my PMs to produce the mockup on eighty percent of their features." A senior product leader told me that recently, and it's exactly what I'm hearing from dev and design everywhere. No one wants to build a feature without the mockup anymore. Now they want the evidence behind the why and the expected outcomes up front. AI turned every engineer and designer into part-PM, grilling the business with the questions they always should have asked. And it isn't only dev. Eng, CS, the solutions architects, all of them can double-check your hypothesis with AI in thirty seconds. Prepare for higher scrutiny. The bar for a defensible product definition has never been higher.

So what is a product definition now?

It's more than a doc. When build is cheap, being clear is the bottleneck, and the definition becomes the highest-leverage thing a PM produces, rigorous enough that a person or an agent builds the right thing the first time. It's a package, and each piece carries weight it didn't have to before.

Requirements. What it must do, and what "done" means. The done is the part teams treated as optional. It isn't, when a machine checks its own work against it.

UX and mockups. What it looks and feels like, before a line ships. The one dev and design already refuse to live without.

Work tree. How it breaks into buildable pieces. The key part is the acceptance criteria, which double as the foundation for testing, the bar the work gets checked against by a person or an agent.

Tech specs. The constraints and interfaces engineering can't be left to guess. A human knew the constraint that was never written down. An agent doesn't, and won't slow down to find out. It'll confidently build the thing that's technically correct and completely wrong for this system.

Evidence. The receipts behind the decisions, where the why stops being an opinion and becomes a bet you can defend.

(And ideally) Living documents. The FAQs, the KB, the release notes, the docs that keep paying out after the feature ships.

Vague in, wrong out, now at machine speed. A real definition is how the build stays cheap and still lands.

You don't write all of that by hand

If that list made you tired, good. You don't produce it by hand. Grinding out six artifacts word by word isn't worth your time, and it's exactly what AI, skills, and tooling are for. Your job is the judgment inside the definition, not the typing of it.

And you manage it as one thing

The trap that killed the old PRD will kill the new definition too, if you let it. These pieces are not a sequence. You don't finish requirements, hand off to design, then tech specs, then walk away. They're one connected thing, and they drift the moment you treat them as a relay race. Change a feature and you change the requirement, the mockup, the work tree, the acceptance criteria, the evidence, the release note, together. A definition where the requirement says one thing and the mockup says another is worse than nothing, because now a confident agent has two contradictory truths and will happily pick one. The old doc went stale because updating it was an afterthought. The new definition only works if keeping it coherent is the job.

The PM job got more PM, not less

The conclusion people jump to is that PMs become engineers. That's not it. We can finally produce technical specs that dev will actually review, and that raises the stakes on the part of the job that was always ours. To earn the right to package work for dev and for agents, you have to nail the parts that are still purely yours. The why, the what, the bet, the vision. The mockups, in conjunction with the design. The NFRs, acceptance criteria, expected outcomes, and evidence. Get those right, then use the tools to assemble the best package for whatever picks it up next.

AI made the writing easy. It did nothing for the hard part, the thinking and the judgment that used to come from the people standing around you. That judgment now has to be built into the definition itself, because those people aren't always in the room to supply it.

Where Product Studio fits

This is what we've been building at Allstacks. Product Studio is a requirements workbench, but the real idea is the product definition. The point isn't to make you write more; it's the opposite. It frees you to unload your thinking without grinding out every word, then builds the package around it, the requirements, mockups, work tree, tech specs, evidence, and living docs, all grounded in your actual delivery and code context so the definition isn't floating free of the system you're changing. And it holds you to a real bar of readiness before anything reaches an agent.

It's also the sparring partner the blank doc never was. Instead of staring at a page, you get something that finds the detail to back your bet and then argues with you, takes the contrarian position, surfaces the obvious objections and makes you answer them before a customer does. That's what the static PRD could never do, and the part most AI tools skip, because telling you you're brilliant is easier.

The piece I'm most excited about is the digital twin. A version of you that knows your definition cold and answers questions about any part of it, around the clock, for anyone who picks the work up. The dev at 11 pm who needs to know what "done" means. The designer is checking a constraint. The agent that would otherwise guess. The understanding stops living in your head and your Slack thread and starts living somewhere the whole team, human and machine, can reach it.

If this is the shift you're feeling, two things. Take a look at what we're building: Product Studio. And if you're a PM or a product leader working through this with your team, I'd genuinely like to talk and show you what we've got.

Grab time with me directly: https://calendar.app.google/VPbM3gcACfdG6J1v7. I'm always looking for people who want to get their hands dirty with this early.