Why do some companies develop complex products in a few years, while others barely gain speed despite Agile, MBSE, DevOps and modern toolchains? In this webinar recording, Martin Eigner, Joachim Pfeffer and Michael Jastram discuss what actually accelerates modern product development. The recording is in German.
The recording is in German. This article summarizes the main points in English.
The starting point was simple. Many companies have invested in Agile, MBSE, DevOps, PLM, ALM, simulation and modern toolchains. The people are competent. The tools are available. The methods are known. And yet many organizations still need years to bring complex products to market.
The contrast is becoming hard to ignore. BYD talks about developing cars in 18 months. Volkswagen has worked to reduce development time from 48 months to 40 months. The difference is too large to explain with “better tools” or “more agile teams.” The mechanism is deeper.
Martin Eigner on systems, tools and organizational silos
Prof. Dr.-Ing. Martin Eigner
EIGNER Engineering Consult
Martin Eigner opened with the systems engineering and PLM view. He argued that the classical V-model still has value, but only when it is expanded for modern interdisciplinary development.
Mechanical, electrical and software development do not move at the same speed. They use different methods, different tools and different cultures. PLM, ALM and ERP systems have grown into separate worlds. This creates handovers, duplicated data and slow change processes.
Martin also pointed to a deeper cause. Engineering education is still organized around disciplines. Mechanical engineers, electrical engineers and software engineers learn different mental models. Complex products force these worlds together. Organizations then discover that their methods and tools still pull them apart.
AI can help, especially in change management, impact analysis, FMEA, quality processes and simulation. But AI does not replace engineering thinking. It needs data, context and architecture. Putting a chatbot on top of an old monolithic toolchain does not create a faster development organization.
Joachim Pfeffer on agile hardware and flow
Joachim Pfeffer
peppair GmbH
Joachim Pfeffer challenged a common framing. The question is not whether to use the V-model or Scrum. They address different problems.
The V-model is a consistency model. It helps manage product complexity. Agile methods address organizational complexity. Complex hardware and systems development needs both.
Joachim focused on where time gets lost. People are busy, but products wait. Work waits for managers, experts, test benches, reviews and approvals. High utilization creates queues. Large batches create late learning. Stage-gate processes push too much work through the system at once.
The practical answer is Lean flow. Reduce work in progress. Use smaller increments. Integrate earlier. Test earlier. Automate where automation removes waiting. Saab’s Gripen development was discussed as an example of incremental aircraft development with regular flight-capable increments.
The uncomfortable part is execution. Joachim described cases where management teams found measures to reduce time-to-market by 30 percent, then implemented none of them. The bottleneck is not always knowledge. Many organizations already know what to do. They do not make it important enough.
Michael Jastram on Product Velocity
Dr. Michael Jastram
Formal Mind GmbH
Michael Jastram framed the topic through Product Velocity.
The core idea is to look beyond a single team, method or tool. DevOps works well for software, but it does not transfer one-to-one to regulated cyber-physical products. These products need engineering, delivery, business and system stewardship to work together.
The Velocity Loop was presented as a map for diagnosing bottlenecks across these areas. It shows where handovers break, where queues form and where feedback arrives too late.
Michael then summarized four Product Velocity principles.
Value Thinking means that engineering work must connect to customer and stakeholder value. Reports, documents and reviews that nobody uses are waste.
Architect for Flow means that product architecture and organization must fit together. Conway’s Law becomes a practical design constraint. If the architecture fights the organization, work in progress grows and decisions slow down.
Shift Left means more than doing early analysis. It means moving learning, validation and integration into shorter cycles.
Platform Leverage makes speed repeatable. BYD’s speed cannot be explained by one practice. It depends on mechanical, electrical and software platforms that make variation cheaper and faster.
The case studies made this concrete. Wagner reduced approval time for some systems from months to weeks or days by creating a secure test environment with TÜV access. ZF reduced validation time from 12 months to 2 months through simulation, MBSE and AI. SHW used design compiler technology to respond faster and more precisely to customer requests.
What the discussion added
The discussion moved quickly from methods to leadership.
AI came up first. The panel agreed that current AI systems are useful because they process large amounts of information. They do not replace engineering judgment. They become powerful when they work with clean data, sound architectures and well-defined processes.
The discussion then moved to Shift Left and front-loading. Front-loading means gaining knowledge earlier. Shift Left goes further. It brings verification, integration and learning into smaller increments. The aim is to face the “moment of truth” every few weeks, rather than every few years.
For the German Mittelstand, the panel discussed configure-to-order and engineer-to-order realities. German companies are strong at customer-specific adaptation. This strength becomes a speed problem when platforms, variants, PLM, ERP and engineering processes do not fit together.
The discussion ended with leadership. Acceleration needs direction from the top and initiative from the teams. People need time, authority and space to change the system they work in. Without that, transformation becomes a slide deck.
Continuing the conversation
This webinar confirmed a pattern we see in many companies. Speed does not come from introducing one more method. It comes from changing how decisions, architecture, tools, feedback and responsibility work together.
Formal Mind works with companies that want to diagnose and improve Product Velocity in real development organizations. That can start with a focused workshop, a bottleneck diagnosis or a 30-day intervention.
If you want to continue the conversation, reach out to the panel as a group or contact us individually.
Contact
- Michael Jastram for Product Velocity, bottleneck diagnosis and 30-day interventions.
- Martin Eigner for PLM, MBSE, systems engineering, the extended V-model and virtual product development.
- Joachim Pfeffer for agile hardware development, Lean development, Scrum, Kanban and organizational change.
