The talk from ReConf is now online. It presents Product Velocity as a model to analyze how products move from idea to operation. The focus is on flow across the full system.
The recording is in German. Auto-generated English subtitles are available.
Related Offer: Join the 2-day in-person Product Velocity training in Munich on June 30 – July 1, 2026. More Information & Registration >>
The Hardware-Software Mismatch
The talk explains Product Velocity as a model for increasing development speed in complex cyber-physical products. The starting point is simple: software organizations have learned to work with short feedback loops, continuous integration, automation, and DevOps. Physical products cannot copy this directly, because hardware and software move at different speeds. But the underlying principles can be transferred.
The talk uses examples from ZF, SpaceX, GE Appliances, and other innovators to show where Product Velocity appears in practice. These companies did not set out to “implement Product Velocity”. Rather, the pattern is visible after the fact: they reduce uncertainty faster, shorten feedback loops, expose blocked work earlier, and use architecture to make change cheaper.
Share the video and ask viewers to look for three things: where uncertainty is reduced too late, where feedback gets lost, and where architecture creates unnecessary coordination.
Transformation Needs Top-Down and Bottom-Up
This makes the recording useful beyond the people who attended ReConf. It can be used as an asynchronous introduction inside an organization. Send it to colleagues who need the basic argument before a deeper discussion starts. It gives enough context to explain why speed is not just a process issue, why MBSE alone does not solve the problem, and why local optimization often fails.
The main challenge is reaching the right stakeholders. Product Velocity needs both directions. Top-down, the organization needs a clear vision, economic framing, and the willingness to remove structural barriers. Bottom-up, teams need concrete, visible progress through small wins. One without the other is weak. A large vision without visible progress creates skepticism. Local improvements without executive support remain trapped inside departments.
Get MBSE Out Of the Silo!
This is especially relevant for MBSE and systems engineering initiatives. Many fail because they demand a large upfront investment before showing value. The better pattern is to define the direction from the top, then create measurable wins from the bottom. The talk shows this with examples where certification time, validation time, test feedback, operational feedback, or interface complexity became the lever for faster flow.
The slide with the large vision and the small bottom-up successes captures the core message. Product Velocity is not about choosing top-down or bottom-up. It is about connecting both. The vision gives direction. The small successes build trust. Together they create the conditions for larger change.
The recording is therefore not just a conference talk. It is a tool for internal alignment. Use it before a strategy workshop, before an MBSE discussion, or before a conversation about faster development cycles. Ask viewers to look for three things: where uncertainty is reduced too late, where feedback gets lost, and where architecture creates unnecessary coordination.
Product Velocity Training
If those questions trigger a useful discussion, the next step is to apply the model to your own context. The Munich training does exactly that. We work through Product Velocity in more depth, use the Velocity Loop as an operating map, and connect the four principles to concrete interventions.
The talk is the introduction. The training is the structured application.
English
German