Why I write Product Velocity

On our own behalf: I have just signed a book deal with MIT Press signed: Product Velocity - Build Physical Products at Software Speed. This book is my contribution to a topic that will determine the competitiveness of many companies in the coming years: How can we develop (cyber) physical products at the same speed that we have now achieved with software?

I position Product Velocity than the playbook on Industrial DevOps. It is primarily aimed at practitioners, who I no longer need to convince of the importance of the path (there are other books for that). It is about concrete implementation, tools, practices and patterns that help teams to develop better products faster. I will provide some initial insights in my Keynote at the Modern RE on September 18 in Leipzig.

More than just a book

The manuscript is due to be finished in March 2026 and will be on the market at the end of the year. However, I consider the topic to be so important that I am already actively building a community of interested people. If you want to be involved right from the start, you can do two things:

1. Become part of the community and register on productvelocity.org to.
2. Spread the word: forward this article or the link to colleagues and friends.

I am specifically addressing four groups:

Why this book is needed

There is a wealth of literature on agile software development. There are also many books on systems engineering and embedded development. But there is hardly anything on Industrial DevOps, Extreme Hardware or whatever else you want to call it: methods that transfer the speed and learning ability of the software world to hardware.

The need exists: traditional product development processes are too slow, too sluggish and too rigid. Anyone who plans four to five years for the development of a car or complex device today will be left behind. Companies such as Tesla, BYD and SpaceX have shown that things can be done differently. They combine hardware and software in development processes that enable short cycles, fast iterations and continuous learning.

Why traditional hardware development is reaching its limits

Although the classic models still work, they are holding organizations back. Although many decision-makers know that everything is software-driven today, they don't know how to implement it. This results in long waiting times, high coordination costs, quality losses and, in the worst case, paralysis.

Innovation drivers are moving away from this. They are creating physical platforms that shift a large part of the functionality into the software and thus drastically accelerate updates, enhancements and innovation.

Déjà vu: Software has been there before

In the early 2000s, software development itself faced enormous problems: fragile dependencies (who remembers DLL-Hell?), error-prone deployments, unreliable releases. This has changed radically over the last 15 years. Today, agile methods, CI/CD pipelines, containerization and distributed version control ensure that software teams can roll out new releases on a daily or even hourly basis.

Hardware is the same - only completely different

Of course, these practices cannot be transferred one-to-one. Changes take longer, compliance is often an issue, production needs lead times and much more. Nevertheless, it is worth examining where we can draw inspiration from software. The following list is all too familiar to us from systems engineering and MBSE. Practices from software help to bring them to life:

• Systems thinking and architecture as a foundation.
• Models (MBSE, CAD, simulation) as a living representation of the product.
• Automation wherever it is possible: from unit tests to hardware-in-the-loop.
• Prototypes and MVPs that make risks visible at an early stage.
• Feedback loops with real data, right through to the Digital Twin.
• Iteration speed as a decisive factor.

It is already being practiced

The idea of agile hardware is not just a theory. Approaches such as concurrent engineering, extreme manufacturing and industrial DevOps have been around for over a decade. Joe Justice has shown with WikiSpeed that Scrum teams and modular architectures can also be used in vehicle construction. SpaceX goes even further and develops its Raptor engines in two-day cycles!

Conclusion: Become part of the movement now

We need to rethink hardware development, the old rules no longer apply. If you stick to traditional processes, you not only slow down, you risk losing your competitiveness. With Product Velocity, I want to show how companies can increase speed, quality and innovation at the same time.

If you want to find out more, get in touch at productvelocity.org on. The community is growing there, and I will be sharing more insights there over the next few months. Here at SE-Trends, I will now only briefly refer to updates on the book when there is news.