Everyone is facing the same challenge right now: ship faster. Stop overthinking and start delivering. And with AI, it is definitely possible. A working prototype that used to take a couple of sprints can now be produced in a couple of days, sometimes even a couple of hours.

So it is fair to ask: if AI can move faster than our processes, are product management rituals and governance gates still necessary?

The short answer is yes, but perhaps not for the reasons many of us were taught.

Historically, product management practices were justified as mechanisms for planning, alignment, and risk reduction. In practice, many became associated with approvals, documentation, handoffs, and stage gates that slowed delivery. As AI accelerates execution, those activities naturally come under scrutiny. If teams can generate working software, prototypes, campaigns, and workflows in a fraction of the time, why maintain the same layers of governance?

The answer lies in understanding what AI actually changed.

Building got dramatically faster. It did not get free. If anything, at scale it can become more expensive because organizations are now paying for both people and the AI systems augmenting them. What changed is not the cost of building. It is the speed of building.

Speed alone does not repeal the oldest trade-off in product development: cheap, fast, good. Pick two.

AI effectively hands us fast. What it does not do is eliminate the bill that comes with that speed. The trade-off still arrives somewhere, usually as cost, quality, or both. The risk did not disappear when prototypes became easy to generate. It simply relocated to the places most organizations rarely govern well: deciding what is worth building and determining whether what was shipped actually delivered value.

This is where product management becomes more important, not less.

For years, many organizations associated Product Managers with roadmaps, requirements, ceremonies, and process. Those activities may evolve, and some may disappear entirely. But underneath all of them sits a more fundamental responsibility: governing trade-offs. Someone still needs to determine whether a problem is worth solving, whether a solution is aligned to an outcome, whether quality is acceptable, and whether the promised value was actually realized. AI accelerates execution. It does not eliminate those decisions.

That is why I increasingly think Product Managers need to own three gates instead of one.

1. The first is Definition Ready. Before anything gets built, one question needs a real answer: what change are we trying to create, for whom, and how will we know it happened? This is where vibe-building earns its place and where it also becomes dangerous (*). Prompting your way to a rough prototype is an incredible mechanism for sharpening a definition. Put something tangible in front of users and the real problem surfaces quickly. The mistake is assuming that because something can be demonstrated, it deserves to exist. A prototype that feels compelling is not evidence that a problem is worth solving. The speed era's most common failure mode is confusing the existence of a solution with validation of the need. Definition Ready exists to ensure the demo informs the thinking rather than replacing it.

2. The second is Build Ready. This is the gate most organizations already have, and it is the one AI legitimately makes faster. Lean into that. Once the problem is understood, the outcome is defined, and the necessary constraints are clear, teams should move aggressively. Build quickly. Experiment aggressively. Use AI wherever it creates leverage. The purpose of rigor at the surrounding gates is not to slow delivery. It is to create the conditions where delivery can move quickly without creating unnecessary risk.

3. The third is Delivery Ready, and in many ways it has become the most important of all. When you can ship ten things in the time it once took to ship one, you can also invest ten times as much effort into production without ever stopping to ask whether any of it mattered. Features can be launched, dashboards can be built, and products can go live while generating little or no value. A feature that is unadopted, unmeasured, and disconnected from outcomes has not truly been delivered. It has simply been released.

If you noticed, Delivery Ready asks the question that speed cultures often avoid: did the change we predicted at the beginning actually occur?

I have seen this play out firsthand. A product that everyone assumed was nearly finished entered a Delivery Ready review, and someone asked a simple question: what does done look like?

There was no answer. Not disagreement about the answer. Not competing opinions. An actual absence of one.

The moment we pressed on the gate, it became clear that no two people in the room shared the same understanding of the go-to-market plan, the success criteria, or the expected outcome. The initiative was ultimately shelved. No revenue was realized, no promise was delivered, and months of effort produced little more than learning.

My role in that conversation was not to defend the gate. It was to make it safe for the organization to acknowledge reality. The gate did not kill the product. The product was never going to land. The gate simply revealed that truth before additional time, money, and effort were invested pretending otherwise.

This is why I struggle when I hear Product Management described as a function that AI will make obsolete. If the role is defined primarily as writing requirements, then perhaps parts of it will. If the role is defined as governing trade-offs, aligning outcomes, validating value, and creating organizational clarity, then the opposite may be true.

The faster organizations can build, the more important those responsibilities become.

Vibe-building without Definition Ready creates graveyards of prototypes that looked impressive and solved nothing. Vibe-building without Delivery Ready creates organizations that mistake motion for progress and output for impact. Neither failure is caused by speed itself. They are caused by removing the wrong controls.

The teams struggling today are not necessarily the slow ones, although they often receive the blame because slowness is visible. The more dangerous failure mode comes from teams moving exceptionally fast without maintaining the disciplines that ensure speed translates into value. We have become very good at measuring throughput. We are much less consistent at measuring whether that throughput mattered.

Across a single project, these gates can feel like overhead. Across dozens of products, hundreds of experiments, and thousands of decisions, they become the mechanism that separates organizations that are merely shipping from those that are compounding.

Speed is not the thing to be skeptical of. Speed is the gift, and the mistake is assuming that because building became easier, governance became optional. In reality, the moment building stopped being the hard part, governing what gets built, why it gets built, and whether it delivered value became the competitive advantage. And that responsibility remains one of the most important things Product Management exists to provide.

* Vibe-building does not deprecates the rules of the build. Code sturdiness, security, and compliance (to name a few) are still real, and speed is precisely when they get quietly skipped.