The New Bottleneck
One thing that I continue to hear over and over again in the discussion of AI driven software development is that AI simply moves the bottleneck. This is often used to explain why you can increase developer productivity but not actually increase product velocity.
As usual, DORA summarizes this well:
The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams. Without this foundation, AI creates localized pockets of productivity that are often lost to downstream chaos.
So, what does this mean to the modern AI enabled PM team?
It means that if you simply pave over the cowpath by having AI write your PRDs you'll miss the benefits of AI entirely. For example:
No. Just, no.
If you as a product team are producing PRDs that could be written by an AI, you really want to re-think your process. Of all the things that lead up to writing a PRD, the actual PRD document is the least interesting part. It's simply an artifact of the process that you use to drive alignment with engineering. The actual document without the process is completely useless.
So, let's regroup.
If we step back, what are we really trying to do? Fundamentally, the goal is to translate customer requirements into customer value. Or to put it another way, to take features from theory to practice. Everything between those two states is by definition optional. Yes, we have conventions of how to do this and yes there are best practices, but all those things are predicated on the current state of the art. If that current state moves, then we need to move also.
I think of this as the difference between outcomes and work. I often see junior PM's who are very frustrated because they are working very hard, but not really getting anywhere. This is because they are focused on the work to be done instead of the outcome to be achieved. So, in this case, the outcome is to produce a feature that provides value to the customer. This may imply work to be done, but it also may mean we do very little work. In the end, if you can provide value to the customer by doing almost nothing, shouldn't you do that? Yes, you certainly should because that's best for the customer and for you.
This brings us back to AI. Because of AI, things that used to be expensive are becoming cheap. Code is one of those things. Even though writing code was never the number one thing product teams spent time on, it was still a significant amount of labor. The better AI tools get, the less labor is involved in actually writing code. The implication here is that if code is essentially free, why would you spend any time at all debating what code to write? Just build the thing. Build it three ways. Build it six ways. Whatever. It's essentially free, so do as many as you want.
If we assume that code is essentially free (it isn't, but stay with me here) then what is expensive?
It turns out that alignment is very expensive. Getting a team aligned is very difficult and takes an immense amount of work. The larger the team, the longer this takes. Of course, AI helps this indirectly because your feature team will be much smaller. Way easier to align a team of three than a team of thirty. But the alignment still isn't free. The reason why you have specialties like design and architecture is that those perspectives are vital for producing a high quality output. Thus, if you "vibe code" a feature that your designer hates, you probably aren't done. Similarly, if your architect doesn't like the way the feature is implemented, you may not want to push it into production.
And this is the bottleneck problem. The process we used to use to drive features into production assumed that engineering resources were scarce. They were designed to protect the engineering team from writing "throwaway" code. They were designed to drive understanding and certainty BEFORE YOU WROTE CODE. Which made sense when you had to write the code by hand. But today? Today you only write code by hand if this is your hobby. If you actually have to run a business, you have AI write the code because it's so much faster. Is it better? No, not really. But it's so much faster that we will accept the lower quality. For this reason, all those processes that we spent time and effort developing need to be re-evaluated. Some of them like CI/CD still work. But some of them, like writing detailed PRDs are probably no longer needed.
This is not a determination that I can make for you. Each organization needs to evaluate where they are and what their needs are. What I can tell you is that if your process is largely unchanged after you implement AI, you're probably doing it wrong.