Why modern product development remains slow

Agile and MBSE are well-known and used in some form in many companies. In addition, there are new tools, measures to increase maturity, and so on. These measures also work, but the few percentage points of speed gain are homeopathic compared to some competitors who develop twice as fast and bring enormously innovative products to market in a very short time.

I was able to win over two experts for a joint webinar on June 18, 2026, namely Martin Eigner and Joachim Pfeffer (Webinar RegistrationThe discussion will combine three perspectives on modern product development: Product Velocity, Agile Systems Engineering, and the Extended V-Model. Underlying all three approaches is the same question: Why do some organizations achieve rapid learning and integration cycles, while others progress slowly despite high methodological maturity?

Speed does not arise from individual methods

One method typically improves only one part of the system. Those who ignore the rest of the system may merely shift the problem. This often causes the gain to dissipate. In the worst case, a new bottleneck arises that slows down the overall flow.

Many organizations have experienced exactly this: software development sprints go smoothly, while hardware procurement and system integration still take months. MBSE Models appear faster than ever before, but nobody reliably consumes them downstream. The method works, yet the overall system remains slow.

„The goal is not to optimize each part separately, but to optimize the whole system.“

Eliyahu M. Goldratt

Goldratt has formalized the problem for production. The same applies in product development: the throughput of the overall system is determined by the weakest link, not by the sum of individual performances.

Product development is a networked system today

Mechatronic systems are already complex. But cybertronic systems, meaning systems that communicate, distribute information, and autonomously adapt their behavior, are on a completely different level of complexity. Eigner et al. describe them as systems with a large number of strongly interconnected elements, dynamic system boundaries, and mutual dependencies between the elements.

With developments like these, local optimization no longer works at all. Anyone who makes a discipline more efficient without adapting the interfaces to the others creates friction at the transition points. The interfaces are the real problem, not the competence of the individual teams.

Existing approaches such as VDI/VDE 2206 or MBSE Frameworks are good. They describe how to systematically think through a complex system. What they don't automatically solve: the organizational questions surrounding decision-making ability, responsibility, and feedback loops. This is precisely where many companies lose momentum, which they can never regain with methods.

The Perspective of Product Velocity

Product Velocity describes how quickly an organization learns and integrates. Not how many features they produce. The Velocity Loop makes this difference visible: short cycles, early integration, fast feedback, resulting decisions, and start again. Anyone who slows down this loop, for example through late integration or long decision-making paths, loses speed structurally, not through inefficiency in individual teams.

Four Principles Drive Product Velocity: Value Thinking, Shift Left, Architect for Flow, and Accelerate.

The Perspective of the Extended V-Model (Martin Eigner)

The already mentioned VDI 2206 has established the V-model as a macrocycle for the development of mechatronic systems: design on the left, verification and validation on the right, and system integration in the middle. This is solid, but it is no longer sufficient for complex products.

The MVPE model (Image) extends exactly this left branch of V. It introduces three overlaid modeling levels: On the specification level, qualitative models are created with requirements, functions, and logical system structure, typically in SysML. Simulation models are added at the second level, for example in Matlab or Modelica. The third level follows with discipline-specific detailing in CAx tools. Throughout, the model differentiates four artifact types: Requirements (R), Functions (F), Logical Architecture (L), and Physical Parts (P).

The decisive step beyond that is the mecPro² framework, which is also described in the paper. It describes the system design on four levels of detail: context level, function level, principle solution level, and technical solution level. On the context level, the system is initially considered as Black Box described, requirements from natural language are transferred into a system model. The function level identifies solution-neutral system functions, including all material, energy, and signal flows. At the principle solution level, solution alternatives are systematically identified, evaluated, and selected. The technical solution level finally achieves maximum concretization.

In practice, the design thus follows a clear fine-tuning logic. Alternatives are systematically compared. And traceability from requirements to the physical solution is anchored in the process.

The Perspective of Agile Systems Engineering and Value Flow (Joachim Pfeffer)

Joachim Pfeffer has been working for over 20 years as a consultant, trainer, and coach at the intersection of agility and physical product development. In his books, he shows how Lean Development and agile approaches can be applied to control units, fuel cells, semiconductors, and machines. The focus is on product increments, agile system architectures, and the question of how value streams in product development can be made visible and optimized.

His central argument: Technology isn't the real hurdle, but organization. Who Value Stream Mapping When used in workshops, decision-makers regularly hear: „We can't work like this.“ Teams optimize themselves internally, but no one takes responsibility for the value flow across departments. That's exactly where speed breaks down.

Common patterns behind rapid product development

Behind all three perspectives lie the same mechanisms. Saab and BYD, two of the examples discussed in the webinar, make them tangible.

First: Short integration cycles. Those who integrate early and often find problems where they arise, not months later when the cost of fixing them has exploded.

Secondly: Decision-making close to the knowledge. Long escalation chains cost time. Organizations that develop quickly have anchored decision-making rights where the expert judgment lies.

Thirdly: Systems thinking instead of disciplinary thinking. Mechanics, software, electronics, and services are so intertwined in modern products that any purely disciplinary optimization produces friction at the boundaries. Methods such as the RFLP model or the mecPro² framework help to make these boundaries visible and bridge them in a model-based manner.

Fourthly: Platforms instead of individual solutions. Speed scales not through repetition, but through reuse. Those who make architectural decisions at the platform level reduce the effort for each subsequent variant.

Three perspectives in a joint discussion

Martin Eigner brings the methodological depth of the extended V-model: How can cybertronic systems be modeled to remain manageable in their complexity? Joachim Pfeffer brings the organizational perspective: Where does the value stream lose its energy, and what can be changed immediately without technological investment? And I will make the connection to Product Velocity What actually makes a feedback and integration cycle fast?

The webinar combines short presentations with a moderated discussion and questions from participants. Those who bring specific cases are most welcome.

To the registration

Conclusion

Methods alone do not accelerate product development. What matters is whether the learning cycles of the entire system become shorter. This requires systems thinking at the organizational level, traceability in the model, decision-making capability where the knowledge resides, and the courage to make value streams visible, even if it reveals uncomfortable truths. Those who don't address this will not catch up with homeopathic percentage points.