Warum ich Product Velocity schreibe

In eigener Sache: Ich habe gerade einen Buchvertrag mit MIT Press unterzeichnet: Product Velocity – Build Physical Products at Software Speed. Dieses Buch ist mein Beitrag zu einem Thema, das in den nächsten Jahren über die Wettbewerbsfähigkeit vieler Unternehmen entscheiden wird: Wie können wir (cyber-) physische Produkte mit der gleichen Geschwindigkeit entwickeln, die wir bei Software inzwischen erreicht haben?

Ich positioniere Product Velocity als das Playbook zu Industrial DevOps. Es richtet sich primär an Praktiker, die ich nicht mehr überzeugen muss, wie wichtig der Weg ist (dazu gibt es andere Bücher). Es geht um die konkrete Umsetzung, um Werkzeuge, Praktiken und Muster, die Teams helfen, schneller bessere Produkte zu entwickeln. Erste Einblicke werde ich in meiner Keynote auf der Modern RE am 18. September in Leipzig geben.

Mehr als nur ein Buch

Das Manuskript soll im März 2026 fertig werden, auf den Markt kommt es Ende des Jahres. Ich sehe das Thema aber als so wichtig an, dass ich jetzt schon aktiv eine Gemeinschaft von Interessierten aufbaue. Wenn du von Anfang an dabei sein möchtest, kannst du zwei Dinge tun:

1. Werde Teil der Community und melde dich auf productvelocity.org an.
2. Erzähle es weiter: leite diesen Artikel oder den Link an Kollegen und Freunde weiter.

Ich spreche konkret vier Gruppen an:

Ingenieure & Praktiker

Lernen und Teilen ihre Erfahrung

Lehrende & Studenten

Lehren Innovation und Best Practice

Innovatoren

Sichern den Vorsprung

Werkzeughersteller

Beschleunigen mit ihren Werkzeugen

Warum dieses Buch gebraucht wird

Es gibt eine Fülle an Literatur zu agiler Softwareentwicklung. Es gibt auch viele Bücher zu Systems Engineering und zu Embedded Development. Doch es gibt kaum etwas zu Industrial DevOps, Extreme Hardware oder wie man es auch sonst nennen mag: Methoden, die die Geschwindigkeit und Lernfähigkeit der Softwarewelt auf die Hardware übertragen.

Der Bedarf besteht: Klassische Produktentwicklungsprozesse sind zu langsam, zu träge, zu starr. Wer heute noch vier bis fünf Jahre für die Entwicklung eines Autos oder komplexen Geräts einplant, wird abgehängt. Firmen wie Tesla, BYD oder SpaceX haben gezeigt, dass es anders geht. Sie kombinieren Hardware und Software in Entwicklungsprozessen, die kurze Zyklen, schnelle Iterationen und laufendes Lernen ermöglichen.

Warum traditionelle Hardware-Entwicklung an ihre Grenzen stößt

Die klassischen Modelle funktionierten zwar noch, bremsen aber Organisationen aus. Viele Entscheider wissen zwar, dass heute alles Softwaregetrieben ist, aber nicht, wie sie es umsetzen sollen. Dadurch entstehen lange Wartezeiten, hoher Koordinationsaufwand, Qualitätseinbußen und im schlimmsten Fall Paralyses.

Innovationstreiber lösen sich davon. Sie schaffen physische Plattformen, die einen Großteil der Funktionalität in die Software verlagern und damit Updates, Erweiterungen und Innovation drastisch beschleunigen.

Déjà vu: Software war dort schon einmal

In den frühen 2000ern stand die Software-Entwicklung selbst vor enormen Problemen: fragile Abhängigkeiten (wer kennt noch DLL-Hell?), fehleranfällige Deployments, unzuverlässige Releases. Innerhalb von 15 Jahren hat sich das radikal verändert. Heute sorgen agile Methoden, CI/CD-Pipelines, Containerisierung und verteilte Versionskontrolle dafür, dass Software-Teams täglich oder sogar stündlich neue Releases ausrollen können.

Hardware ist genauso – nur ganz anders

Natürlich lassen sich diese Praktiken nicht eins zu eins übertragen. Änderungen dauern länger, oft ist Compliance ein Thema, Fertigung braucht Vorlaufzeiten, und vieles mehr. Trotzdem lohnt es sich zu untersuchen, an welchen Stellen wir uns von Software inspirieren lassen können. Die folgende Liste ist uns aus dem Systems Engineering und MBSE allzu bekannt. Praktiken aus der Software helfen, sie zum Leben zu erwecken:

• Systemdenken und Architektur als Fundament.
• Modelle (MBSE, CAD, Simulation) als lebendige Repräsentation des Produkts.
• Automatisierung überall dort, wo sie möglich ist: Von Unit-Tests bis Hardware-in-the-Loop.
• Prototypen und MVPs, die Risiken früh sichtbar machen.
• Feedbackschleifen mit realen Daten, bis hin zum Digital Twin.
• Iterationstempo als entscheidende Größe.

Es wird bereits praktiziert

Die Idee agiler Hardware ist keine bloße Theorie. Seit über einem Jahrzehnt gibt es Ansätze wie Concurrent Engineering, Extreme Manufacturing oder Industrial DevOps. Joe Justice hat mit WikiSpeed gezeigt, dass sich Scrum-Teams und modulare Architekturen auch im Fahrzeugbau anwenden lassen. SpaceX geht noch weiter und entwickelt seine Raptor-Triebwerke in zwei-Tages-Zyklen!

Fazit: Jetzt Teil der Bewegung werden

Wir müssen bei der Hardware-Entwicklung umdenken, die alten Regeln gelten nicht mehr. Wer an traditionellen Prozessen festhält, wird nicht nur langsamer, sondern riskiert seine Wettbewerbsfähigkeit. Mit Product Velocity möchte ich zeigen, wie Unternehmen Geschwindigkeit, Qualität und Innovation gleichzeitig steigern können.

Wenn du mehr erfahren willst, melde dich auf productvelocity.org an. Dort wächst die Community, und dort werde ich während der nächsten Monate weitere Einblicke teilen. Hier bei SE-Trends werde ich ab jetzt nur noch bei Neuigkeiten kurz auf Updates zum Buch verweisen.