There’s a version of productivity that feels like progress but isn’t.
I experienced it firsthand during my AI experimentation. I was building prototypes, moving fast, generating output, shipping things into existence in a fraction of the time it used to take. It felt like momentum.
Then I looked at what I’d built and realized I couldn’t answer a basic question: does this solve a problem?
I had a solution. I wasn’t sure there was a problem. And no amount of speed fixes that.
Why people declare the PRD dead
The criticism is legitimate. In a lot of organizations, the Product Requirements Document became exactly what people say it is, a bureaucratic checkbox. Thirty pages of requirements written to cover someone politically, reviewed by nobody, ignored the moment development started.
If that’s your experience of a PRD, of course you’d want to kill it. The document wasn’t doing anything useful. It was just slowing things down.
Sound familiar? It should. We’ve been here before.
Jira gets the same treatment. Mention it in a room full of product and engineering people and watch the reactions. Eye rolls. War stories. Someone will call it a ticket graveyard. Someone else will say their team ditched it entirely and never looked back.
But Jira is a tool. It exists to solve a real problem: tracking work, managing dependencies, creating visibility across a team. The tool didn’t fail those teams. Their organizations created processes so tangled, so disconnected from how work actually happens, that the tool became the symbol of everything wrong with how they operated. So they blamed the software.
The PRD gets the same treatment for the same reason. The problem was never the document. It was what the document had become, a ritual divorced from the thinking it was supposed to contain.
Killing the PRD in response to that is like canceling all meetings because you’ve sat through too many bad ones. You’re solving for the symptom, not the cause.
What a PRD actually is
At its core, a PRD is just a forcing function for a few questions that are easy to skip when you’re moving fast.
What problem are we solving? Who has this problem? What does a good solution actually look like? How will we know when we’ve solved it?
That’s it. Not thirty pages. Not a template with seventeen sections. Just those questions, answered with enough clarity that everyone working on the problem is working on the same problem.
The format is almost irrelevant. What matters is that someone did the thinking — and wrote it down somewhere the team can see it and push back on it.
The shared understanding problem
Here’s what actually goes wrong when you skip this step: everyone fills the gap with their own assumptions.
Engineering builds what they think was asked. Design solves the problem they found most interesting. Marketing waits for something to launch. Leadership wonders why the thing that shipped doesn’t match what they thought they approved.
None of these people are doing anything wrong. They’re just operating without a shared frame. And you can’t fix that with better standups or more Slack messages. You fix it by creating clarity before execution starts.
That’s what the PRD is for. Not documentation. Not compliance. Shared understanding.
Why I don’t want to vibe code
There’s a trend right now toward what people are calling vibe coding, using AI to generate software rapidly, iterating on feel, building fast and figuring out the rest later. For certain contexts, personal projects, quick experiments, throwaway tools - it makes sense.
But I’m not building for the vibe. I’m building to solve problems that generate real value for customers and for the business. Those are different standards.
When the cost of building drops dramatically, and it has, the temptation is to start building immediately. Why spend time on requirements when you can have a working prototype in an hour?
Because a prototype of the wrong thing is still the wrong thing. Faster and cheaper doesn’t change that.
My AI experimentation taught me this the hard way. The speed is real. The leverage is real. But the thinking that has to happen before you build, that hasn’t been automated. It still requires someone to slow down long enough to ask whether the problem is worth solving, whether this solution actually addresses it, and whether the team understands both well enough to build in the same direction.
Clarity is the work
This is what I’ve come to believe: the PRD isn’t a deliverable you produce before the real work starts. It is the real work or at least the beginning of it.
Getting sharp on the problem. Defining what success looks like. Making sure the people building the thing and the people asking for it are looking at the same picture. That thinking is the job. The document is just how you make it visible.
You don’t need thirty pages. You need enough to fix the scope, name the problem, and create a shared understanding of what done looks like.
Everything else, the prototype, the one-pager, the priority decisions, flows from that. Skip it, and you’re just moving fast in an unknown direction.
That’s not momentum. That’s how you end up with a solution that doesn’t solve anything.