Traditional product companies face an uncomfortable reality. Competitors emerge seemingly from nowhere with products that are more innovative, faster to market, and often dramatically cheaper. The instinctive response is to look for efficiency gains: faster tools, leaner processes, more automation at the workstation level. Yet organizations that pursue this path often discover that their overall development velocity remains stubbornly unchanged, or even declines.
This is not a failure of execution. It is a failure of paradigm.
The Comfortable Illusion
Product development organizations tend to hold a set of beliefs that, while internally consistent, are fundamentally dysfunctional. Chief among these is the conviction that improving efficiency in individual activities will automatically translate into faster end-to-end delivery. If our engineers can design faster, our testers can validate faster, and our manufacturing can prototype faster, surely the overall system must accelerate.
The problem is that this reasoning ignores how complex product development actually works. Development is not a sequence of independent activities performed in isolation. It is a network of interdependent work streams, decisions, and feedback loops. Optimizing one part of this network without considering its connections to other parts often creates the opposite of the intended effect.
Consider a common scenario: an engineering team invests heavily in better CAD tools, reducing the time required to produce detailed designs by 30 percent. This looks like a clear win. But the downstream integration team now receives more design packages faster than it can absorb. Queues build up. Handoff delays increase. Integration cycles are disrupted. The local efficiency gain has generated a global slowdown.
This pattern repeats across organizations. More efficient requirements capture creates bottlenecks in architecture. Faster prototyping overwhelms validation capacity. Accelerated coding produces integration backlogs. The improvement at each station is real, but the system-level outcome is worse.
Local Optimization as an Anti-Pattern
The Velocity Loop—a conceptual model for understanding how value flows through complex product development—identifies local optimization as one of the most damaging anti-patterns an organization can fall into:
Local Optimization: Optimizing parts of the organization, process, or toolchain at the expense of end-to-end flow and outcomes.
This anti-pattern does not arise from individual mistakes. It is a structural consequence of how most organizations are designed and measured. Departments are judged on their own performance metrics. Teams are rewarded for their own output. Individual contributors are evaluated on their own productivity. Each of these incentives pulls toward local optimization and away from global flow.
The result is predictable. Teams become excellent at their own tasks while the overall system grinds slower. Capacity utilization rises while throughput stagnates. Everyone is busy, but value delivery lags behind.
I believe that the dominant paradigm for managing product development is fundamentally wrong. Not just a little wrong, but wrong to its very core.
Donald Reinertsen, author of The Principles of Product Development Flow
The orthodox belief that efficiency improvements lead to velocity is one such wrong belief. It is well-defended by intuition and reinforced by visible activity. It is also demonstrably false in most product development contexts.
The Capacity Utilization Trap
One of the most counterintuitive dynamics in product development is the relationship between capacity utilization and cycle time. Conventional management thinking treats high utilization as a sign of efficiency: if our people are busy 95 percent of the time, we must be running a tight ship.
The reality is more complex. In systems with variability—and product development is nothing if not variable—high utilization creates queues. Queues create delays. Delays increase cycle time. The math is unforgiving: as utilization approaches 100 percent, queue times do not increase linearly but exponentially.
Few developers realize that queues are the single most important cause of poor product development performance. Design-in-process inventory accumulates invisibly because, unlike physical inventory on a factory floor, it has no visible presence and no obvious carrying cost. Yet it dominates cycle time and drowns out any local efficiency improvements.
Increasing capacity utilization (an efficiency proxy) often has the negative effect of increasing cycle time. Optimizing for busy teams means accepting slower value delivery.
The Tools Trap
When product development stalls, leadership often reaches for the same solution: better tools. New ALM systems, upgraded CAD platforms, modern requirements management software, integrated PLM suites. The logic is familiar: if our tools are faster, our development will be faster.
This is another comfortable illusion.
Better tools can amplify existing capabilities, but they cannot fix structural problems. Adopting the language, roles, or tools of modern development practices without the necessary cultural, structural, or incentive changes is what might be called shallow adoption. It creates the appearance of transformation without the substance.
A tool that accelerates design reviews does not help if designs sit in queues for weeks before being reviewed. A requirements platform with advanced traceability adds no value if requirements are not aligned with business priorities. A CI/CD pipeline running faster tests is irrelevant if integration batches are accumulated monthly.
Tool investments must be paired with flow investments. Speed at the workstation level only translates to speed at the system level when handoffs are reduced, queues are managed, and feedback loops are shortened. Without this pairing, tool upgrades become expensive distractions.
What Actually Creates Velocity
Product Velocity is not an optimization. It is a paradigm shift. It changes how products are conceived, developed, and evolved, rather than accelerating existing processes.
The shift requires attention to several dimensions that efficiency improvements typically ignore:
Value flow over local efficiency. The question is not how fast any single activity completes, but how quickly value moves from concept to customer. This requires making delays visible, limiting work in progress, and actively managing the transitions between teams and practices.
Learning speed over process speed. Product development generates uncertainty. Resolving that uncertainty requires learning. The organizations that develop fastest are not those with the fastest processes, but those that learn fastest. Fast feedback loops, rapid validation, and continuous integration are not efficiency measures, they are learning mechanisms.
System-level coherence over departmental excellence. High-performing teams that do not coordinate effectively produce mediocre system outcomes. Architecture, integration, and cross-functional alignment are not overhead: they are the substrate that enables flow.
Deliberate alignment over continuous synchronization. Different layers of commitment evolve at different speeds. Forcing them into lockstep creates tension and delay. Effective product development uses cadence (deliberate, recurring alignment points) to coordinate work across practices without forcing tight coupling.
Language for the Conversation
When someone suggests that “we just need better tools” to achieve faster development, the following responses can help redirect the conversation toward systemic thinking:
“Where are the queues?” Before discussing tool investments, understand where work accumulates waiting for the next step. Queue time typically dominates processing time by an order of magnitude. Better tools that feed larger queues faster do not improve outcomes.
“What is the cost of delay?” Efficiency metrics measure activity. Cost of delay measures impact. Understanding the economic consequence of delayed delivery helps prioritize flow improvements over local efficiency improvements.
“What happens at the boundaries?” Tools accelerate work within teams. Velocity is constrained by what happens between teams. Handoffs, approvals, integration points, and feedback loops are where development slows. Tools rarely address these.
“Is this a tooling problem or a structural problem?” A tool can improve the speed of a particular task. It cannot change organizational incentives, reporting structures, or cultural norms. If the problem is structural, a tool is a distraction.
“Are we measuring the right thing?” Metrics shape behavior. If teams are measured on utilization, they will optimize for busy. If teams are measured on throughput, they will optimize for flow. The choice of metrics determines whether tool investments translate into velocity improvements.
The Path Forward
The competitive pressure on product development organizations is real. Companies like BYD develop new vehicle models in 18 months while traditional automakers require 40. SpaceX iterates rocket engines through multiple generations in the time competitors take to finalize a single design. These differences are not explained by better tools or incremental efficiency gains.
The path forward requires honest examination of where value and feedback are delayed in the current development flow, especially across organizational, tooling, and disciplinary boundaries. It requires treating Product Velocity as a strategic leadership topic, not as a tooling, process, or methodology initiative. And it requires abandoning the comfortable illusion that efficiency improvements will close the gap.
Small efficiency gains here and there are not enough to catch up. The paradigm itself must change.
English
German