Individual engineers using AI write code faster. That result shows up in benchmarks and studies. Practitioners and internal pilots confirm this. But when Google’s DORA program measured the same phenomenon at the level of the organization in 2024, it found that a 25 percent increase in AI adoption came with an estimated 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability.
So… Does AI speed things up or not? Yes and no. We often observe local productivity gains and overall productivity loss. Oops.
The situation is already doomed when a mandate arrives from the C-suite, usually some version of “move faster with AI.” A team picks the activity that feels slowest, accelerates it, and reports the improvement. Nobody checks whether the product reached a customer any earlier.
Four questions prevent that outcome. They fit into ten minutes and they work in a meeting, before the budget is committed.
1. What product outcome are we trying to change?
Faster requirements writing is an activity. So is automated test case generation, and so is AI-assisted design review. Activities are things your organization does to itself.
Outcomes are different. Earlier validation of a risky assumption. A shorter time from stakeholder need to capability in the field. Fewer changes discovered after design freeze. Each one is something a stakeholder experiences, and each one can be measured without asking anyone how productive they felt.
If the answer to this question names a tool, a department, or a task, you do not have an answer yet. You have a purchase order looking for a justification.
2. Where is elapsed time actually being lost?
Take one recent flow item, a feature or a change request, and reconstruct its calendar time from the moment it entered the stream to the moment it was delivered. Then split that span into two buckets: time when someone was working on it, and time when it was waiting.
The waiting bucket is almost always the larger one. Work waits for a review slot, for a test bench, for a cross-domain decision, for the next integration window, for a supplier response. Donald Reinertsen argued that queues are the single most important cause of poor product development performance, and the reason they persist is that design in progress has no physical form. Nobody trips over it in the hallway.
Do not substitute perception for measurement here. In a 2025 randomized study by METR, experienced open source developers working in their own repositories took 19 percent longer on tasks where AI tools were allowed, while believing afterwards that they had been about 20 percent faster.
If the activity you plan to accelerate holds 5 percent of the elapsed time, then perfect execution buys you 5 percent.
3. What happens if this activity becomes 10x faster?
Now explore hypothetical success before you start. What would happen if you hit your improvement goal?
For instance, requirements generation at 10x means ten times more requirements arriving at the same review board, staffed by the same people, meeting on the same Thursday. In a webinar I hosted with Jama Software CEO Mark Osofsky, he described the software version of this: developers generate a large volume of code, that code pushes into testing, and testing cannot absorb it. Throughput across the system falls while every individual developer’s output rises.
This is the key insight: Productivity is local. Velocity is systemic. If nothing downstream changes when an activity gets ten times faster, you have bought productivity and left velocity untouched.
The useful version of this question is a commitment: name what you will change downstream, at the same time, with the same budget. If the answer is nothing, the acceleration is a pilot, not an improvement.
4. What becomes the next constraint?
Acceleration does not remove bottlenecks. It moves them.
That is the ordinary behavior of a constrained system, familiar from the Theory of Constraints. The stage that limits throughput sets the pace for everything else. Relieve it and a different stage becomes dominant. Improvement is iterative by nature, and the constraint shifting is a sign that the first intervention worked.
The failure mode is not that the constraint moves, but that nobody knows where it went. Queues simply form somewhere new. If you do not anticipate that and take it into account beforehand, the outcome of your initiative will likely disappoint.
So ask the team to name a candidate before starting, and instrument that stage in advance. If nobody can name one, the team does not yet have a working model of its own value stream, and any speed gained upstream will be absorbed by a queue they cannot see.
The version you take into the meeting
Volkswagen worked to bring a new model to market in 40 months. BYD claims 18. That gap will not close by writing requirements faster, and it will not close by generating more code. It closes when elapsed time between a learning and a delivered change gets shorter, which is a property of the system rather than of any stage inside it.
Product Velocity is how quickly you learn what matters and turn it into valuable product change. Before accelerating an activity, ask whether it shortens that loop.
Four questions. An initiative that survives all four is worth funding. One that fails any of them will produce a beautiful dashboard and no faster products.
English
German