AI Makes Delivery Faster. It Also Moves the Bottleneck.

The current discussion about AI productivity is far too focused on how much more work people can produce. Companies are reporting faster feature delivery, others are building tools to calculate employee-level returns on AI spending, and model developers are sometimes slowing their own work because of security concerns. At the same time, product leaders are discussing noisy dashboards, small improvements to team processes, regulation and the human cost of moving too fast.

To me, these are not separate conversations. They all point to the same change: AI may reduce the effort required to build something, but it does not reduce the effort required to decide whether that thing should exist.

In fact, it can make that decision more important.

When software becomes cheaper to produce, an organization can easily generate more features, experiments, reports, prototypes and internal tools than it can properly evaluate. The output looks impressive. Pull requests increase. Release notes get longer. Stakeholders see their requests delivered sooner. Yet customer value and commercial results may remain unchanged.

That is not a productivity gain. It is extra inventory.

I have seen the same pattern without AI. When a team gains development capacity, the first response is often to add more roadmap items. Few organizations invest the additional capacity in deeper discovery, better instrumentation or removing features that no longer earn their place. AI simply makes this behaviour easier and faster.

This is why I would be careful with employee-level AI ROI tools. They can be useful for understanding adoption or cost, but they also invite leaders to measure what is easiest to count. Time saved per task is not the same as value created. A product manager who produces twice as many specifications has not necessarily improved anything. A developer who ships twice as much code may have created more maintenance work. A marketer who generates more campaigns may only increase the number of weak messages customers ignore.

The unit of analysis should be the product system, not the individual task. Did we learn faster? Did we identify a bad assumption before making a large investment? Did customer behaviour change? Did support demand fall? Did margin improve? Did we stop work that evidence showed was unlikely to contribute?

That last question matters more than most teams admit. Faster production without a stronger stopping mechanism creates crowded products and overloaded teams. Every new capability adds testing, documentation, support, security and future decision-making. Even a feature that was cheap to generate can be expensive to own.

When I led a 19-person Product & Growth organization, I cared about revenue and margin growth, but also about whether the team could make sound decisions without waiting for permission. Those goals reinforced each other. Autonomy worked when teams understood the intended outcome, had access to evidence and could challenge work that did not support it. More output was never a substitute for that clarity.

If I were introducing AI tools into a product organization today, I would not begin by asking every role to prove how many hours it saved. I would look at the path from idea to evidence. Where do decisions wait? Where do assumptions go untested? Where does released work remain unevaluated? Where are teams maintaining things nobody is willing to remove?

AI can help at several points along that path, but increasing production at one stage may only move the queue elsewhere. Faster prototyping creates more concepts to test. Faster coding creates more releases to assess. Faster analysis creates more findings that still require judgment and prioritization.

The organizations that benefit most will not be those that produce the largest volume of AI-assisted work. They will be the ones that become more selective as production gets cheaper. The real advantage is not being able to build everything faster. It is being able to test more possibilities while committing to fewer of them.