Artikel
Schreiben über Product Velocity
Newsletter
2 Mal pro Monat. Neue Artikel, Webinare, Videos, Schulungen. Sie können sich jederzeit abmelden.
Nicht jedes Warten ist Zeitverschwendung
Architektur für den Fluss #5. Warten ist nicht immer Zeitverschwendung. Das eigentliche Problem besteht darin, nur die Kapazität zu messen und die Wartezeit außer Acht zu lassen.
Letzte Woche habe ich einen Artikel veröffentlicht, der auf einer Behauptung beruhte (Hier auf Deutsch lesen). Die Kapazität ist im Budget berücksichtigt, die Wartezeit hingegen nicht. Deshalb birgt die Wartezeit ein enormes Potenzial zur Beschleunigung der Entwicklung: Sie ist weitgehend unsichtbar, stellt aber eine große Quelle von Ineffizienz dar.
Innerhalb einer Stunde hat ein Leser die Behauptung auseinandergenommen. Er hatte Recht, und die Behauptung bleibt trotzdem bestehen – allerdings nicht in der Form, wie ich sie formuliert habe. Welche Hälfte nicht zutraf, ist der Teil, den es sich zu notieren lohnt.
(mehr …)Velocity Loop 2.1: Vom Engpass zum Rückgrat
Erläuterung der Geschwindigkeitsschleife #5. Diese Überarbeitung der Schleife verdeutlicht die visuelle Semantik und verringert Missverständnisse.
Ein Diagramm spricht durch seine Linien, nicht durch seine Bildunterschrift. Wo ein Verbindungselement endet und was man durchlaufen muss, um es zu überqueren, sind Aussagen, die der Leser aufnimmt, noch bevor er ein Wort liest. Ich habe den „Velocity Loop“ gezeichnet, um den Wertfluss und das „Design-in-Progress“ (DIP) im Rahmen einer komplexen Produktentwicklung darzustellen. Nach einem Jahr voller Rückmeldungen war die scharfsinnigste Bemerkung, die mir gemacht wurde, dass das Bild einen Engpass zeigte. Hier ist, was die Leute erkannt haben, was ich geändert habe und welche Frage ich nun an Sie weitergebe.
Aktualisierung: Ich habe viel Feedback zu der Überarbeitung erhalten. Vielen Dank an alle, die dazu beigetragen haben. Auf Grundlage des Feedbacks habe ich eine weitere Überarbeitung vorgenommen, die dem Original deutlich näher kommt. Daher ist der folgende Text nun veraltet. Ich lasse ihn hier stehen, um die Entwicklung der Produktgeschwindigkeit zu dokumentieren.
(mehr …)Wie „Product Velocity“ Mercedes retten kann
Warum Unternehmen träge bleiben #5. Mercedes wird nicht dadurch gerettet, dass man von den Mitarbeitern verlangt, mehr Stunden zu arbeiten. Klare Ziele und ehrliche Kennzahlen hingegen schon.
Anfang Juli 2026, Sindelfingen. Rund 20.000 Mercedes-Mitarbeiter stehen vor dem Werkstor und skandieren “Ola raus”. Auslöser ist eine E-Mail, die vom gesamten Vorstand unterzeichnet und an alle Mitarbeiter in Deutschland verschickt wurde. Der Kernsatz lautet übersetzt: “Wir sollten in allen Bereichen mehr arbeiten – für dasselbe Geld.” Für den Großteil der Belegschaft bedeutet das eine Verlängerung der Wochenarbeitszeit von 35 auf 40 Stunden. Fünf Stunden mehr bei gleichem Lohn.
Mercedes bezeichnet dies als ’Produktivitätsoffensive“. Und genau darin liegt das Paradoxon, über das man einmal genauer nachdenken sollte: Ein Unternehmen, das sich in einer echten Krise befindet und von fähigen Leuten geführt wird, reagiert auf einen Einbruch der Produktion mit einer Erhöhung des Einsatzes. Das Problem bei Mercedes war nie die Anzahl der Arbeitsstunden. Es geht darum, was in diesen Stunden geschieht. Fünf zusätzliche Stunden ändern daran nichts, und die Belegschaft vor dem Werkstor weiß das.
(mehr …)Eine Methode verbreitet sich schneller als Geschichte als als Anleitung
„Kessler Seven“ ist ein Science-Fiction-Roman, der davon handelt, wie durch die Reparatur defekter Übergänge und Tore zehntausend Leben gerettet werden.
Zwei der einflussreichsten Betriebswirtschaftsbücher der letzten vierzig Jahre sind Romane. Keine Fallstudien, keine Rahmenkonzepte mit einem ausklappbaren Poster am Ende. Romane mit Figuren, einer Handlung und einem Bösewicht, der sich als Mensch entpuppt. Eliyahu Goldratt vermittelte 1984 einer ganzen Generation von Fabrikleitern die Theorie der Engpässe, indem er eine Geschichte über einen Werksleiter schrieb, der neunzig Tage Zeit hatte, um seine Fabrik zu retten. Gene Kim tat 2013 dasselbe für die IT-Branche, und Das Phoenix-Projekt wurde zu dem Buch, das jedes DevOps-Team dem neuen Mitarbeiter heimlich in die Hand drückt.
Die Fachbücher zu denselben Themen verkauften sich nur zu einem Bruchteil so oft. Das ist der Punkt, über den man einmal nachdenken sollte. Die gründliche, umfassende und korrekte Auseinandersetzung mit einem Thema unterliegt immer wieder der Version mit einem Protagonisten und einer Deadline.
(mehr …)(KI) Automatisierung ohne Beschleunigung
Grundsätze der Produktgeschwindigkeit #3. Automatisierung, insbesondere durch KI, kann den Prozess verlangsamen. Denken Sie an das Little’sche Gesetz.
Ein Software-Team setzt einen KI-Programmierassistenten ein, und seine Leistung verdoppelt sich. Die Pull-Requests häufen sich. Die Anzahl der Commits pro Entwickler steigt. Das Entwickler-Dashboard leuchtet in einem erfreulichen Grünton. Sechs Monate später haben genauso viele Funktionen die Kunden erreicht wie im Jahr zuvor. Die Arbeit ging schneller von der Hand. Das Produkt jedoch nicht.
Hier geht es nicht um überbewertete KI. Der Assistent hat genau das gehalten, was er versprochen hat. Es geht darum, wo Geschwindigkeit in ein System einfließt und wo sie es wieder verlässt – und warum dies selten derselbe Ort ist. KI wird sehr viele träge Organisationen in genau der einen Sache schneller machen, die nie ihr Problem war.
(mehr …)In Deutschland gibt es keine Wohnungsknappheit. Es gibt ein Problem mit dem Zustrom.
Architektur und Fluss #4. Das Anti-Muster, das ein ganzes Land lahmlegt: Eine Fallstudie zur deutschen Wohnungskrise.
Deutschland ist eine der reichsten Nationen der Welt, die besonders stolz auf ihre Ingenieurskunst ist. Es baut Maschinen, die der Rest der Welt nachahmt. Es verfügt über Kapital, Rohstoffe, qualifizierte Arbeitskräfte und eine Bevölkerung, die sich aufrichtig mehr Wohnraum wünscht. Und doch verfehlt das Land Jahr für Jahr seine eigenen Bauziele um Hunderttausende von Wohneinheiten, die Mieten steigen, und die Politiker reihen sich ein, um immer wieder dasselbe Mittel anzukündigen: mehr Geld, schnellere Genehmigungen, weniger Vorschriften — siehe beispielsweise die Maßnahmenpaket im Wohnungswesen.
Und hier kommt der unangenehme Teil. Der Großteil dieser Debatte zielt auf den falschen Teil des Systems ab.
(mehr …)Conways Gesetz ist nur die halbe Wahrheit: Lernen Sie den „Conway-Drift“ kennen
Grundsätze der Product Velocity #3. Ein „Conway-Drift“ tritt auf, wenn die Produktarchitektur und die Organisationsarchitektur nicht aufeinander abgestimmt sind.
Die meisten Führungskräfte im Ingenieurwesen haben schon einmal von Conways Gesetz gehört. Weitaus weniger kennen hingegen Conway-Drift, und genau in dieser Lücke verlieren viele Unternehmen still und leise an Dynamik.
Conways Gesetz ist eine jener Beobachtungen, die fast zu einfach klingen, um nützlich zu sein – bis man miterlebt, wie es das Schicksal eines mehrjährigen Produktprogramms bestimmt. „Conway Drift“ ist die Fortsetzung in Zeitlupe: Was passiert, wenn… danach Man hat die Struktur richtig hinbekommen, wenn niemand mitbekommt, wie die Ausrichtung nachlässt. Das Erste ist eine Momentaufnahme. Das Zweite ist eine Entwicklung.
Dieser Artikel behandelt vier Themen: Was Conways Gesetz eigentlich besagt, warum der „Conway-Drift“ die gefährlichere Fehlerquelle ist, wie man ihn im eigenen Unternehmen diagnostizieren kann und was zu tun ist, wenn man ihn entdeckt hat.
(mehr …)Ein Pilotplatz für eine 30-tägige „Product Velocity“-Maßnahme
Im Sommer 2026 stelle ich einen Pilotplatz zu einem reduzierten Preis für eine 30-tägige „Product Velocity“-Maßnahme zur Verfügung.
Viele Unternehmen setzen auf Agile, MBSE, DevOps, ASPICE, PLM und ALM und entwickeln dennoch zu langsam. Ich glaube nicht, dass das fehlende Puzzlestück eine weitere Methode ist.
Das fehlende Puzzlestück ist in der Regel Klarheit darüber, wo das Produkt Zeit verliert. Das klingt einfacher, als es ist.
Die meisten Unternehmen betrachten die Produktentwicklung unter dem Gesichtspunkt von Funktionen, Werkzeugen, Prozessen oder Verbesserungsinitiativen. Product Velocity betrachtet hingegen den Fluss des Produkts selbst: Entscheidungen, Abhängigkeiten, Rückkopplungsschleifen, Architekturentscheidungen, Anforderungen, Tests, Beiträge von Lieferanten, Überprüfungen und Nacharbeiten.
Deshalb eröffne ich ein Pilotplatz zu ermäßigtem Preis für eine 30-tägige „Product Velocity“-Maßnahme.
Das Ziel: Die größte aktuelle Engstelle in einem Bereich der Produktentwicklung zu ermitteln, eine gezielte Maßnahme durchzuführen und deren Wirkung nach 30 Tagen zu messen.
(mehr …)Es liegt nicht an den Ingenieuren
Warum Unternehmen langsam bleiben #4. Deutschland und Europa verlieren nicht, weil ihre Ingenieure schlecht sind: Ihre Entwicklungssysteme lernen zu langsam.
Porsche war die profitabelste Automarke der Welt, die Kathedrale der deutschen Ingenieurskunst. Im Jahr 2025 verbuchte Porsche rund 3,9 Milliarden Euro an Sonderaufwendungen, um eine Elektrostrategie rückgängig zu machen, zu der sich das Unternehmen nur wenige Jahre zuvor mit großem Vertrauen bekannt hatte. Der Betriebsgewinn im Automobilbereich brach um 98 Prozent. Die Aktie verlor ein Drittel ihres Wertes. Das Unternehmen wurde aus dem DAX, dem Index der deutschen Industriechampions, herausgeworfen.
Sieben Jahre zuvor, im Jahr 2018, hatte Porsche mehr als 6 Milliarden Euro für die Umstellung auf Elektrofahrzeuge bereitgestellt. Dann hat das Unternehmen den Kurs geändert. Wenn man das zusammenzählt, kommt man auf eine Rundreise von fast 10 Milliarden Euro, die ungefähr dort endete, wo sie begann.
(mehr …)Vier Prinzipien, zwei Geschwindigkeiten
Expertenmeinungen #1: Das Interview mit Yuchao Luo zeigt, dass China bereits Product Velocity anwendet, während Deutschland noch zögert.
18 Monate. So lange braucht BYD vom Konzept bis zur Markteinführung eines neuen Autos. Volkswagen gab 2025 bekannt, dass es seinen eigenen Zyklus auf 40 Monate verkürzt hat. Diese Ankündigung wurde als Meilenstein bezeichnet. Der Abstand hat sich nicht verringert, er ist nur sichtbarer geworden, und zwar in den Dimensionen, die am wichtigsten sind. Aber hier geht es nicht um Deutschland gegen China, sondern um traditionelle Systemtechnik gegen Product Velocity.
Das Product Velocity Framework beschreibt vier Grundsätze die schnelllebige Produktorganisationen von langsamen unterscheiden: Value Thinking, Architect for Flow, Shift Left und Accelerate. Yuchao Luo, der sowohl in einem Volkswagen-Joint-Venture als auch bei NIO gearbeitet hat, konkretisierte diese Grundsätze kürzlich in einem Interview. Er ist nicht gekommen, um China Speed zu feiern. Er ist gekommen, um es zu erklären. Die Erklärung ist unangenehm für alle, die den Rückstand auf billige Arbeitskräfte und staatliche Subventionen zurückführen und es dabei belassen wollen.
Kommendes Webinar am Mittwoch (27. Mai), 17:00 Uhr MEZ: Wie man eine 30-tägige Produktgeschwindigkeits-Intervention durchführt >>
(mehr …)
English
German