Articles
Writing on Product Velocity
Updates
2 x per month. New articles, webinars, videos, trainings. Unsubscribe any time.
Not All Waiting Is Waste
Architecture for Flow #5. Waiting is not always waste. The real problem is to measure only capacity and to leave waiting time invisible.
Last week I posted an article built on one claim (Read it here in German). Capacity sits in a budget and waiting time sits nowhere. That is why waiting time has huge potential in speeding up development: it is largely invisible, but a large source of ineffectiveness.
Within the hour, a reader took it apart. He was right, and the claim survives anyway, but not in the shape I articulated it. Which half failed is the part worth writing down.
(more…)Velocity Loop 2.1: From Bottleneck to Backbone
Velocity loop explained #5. This revision of the loop clarifies visual semantics and reduces misunderstandings.
A diagram argues in its lines, not its caption. Where a connector lands, and what you have to pass through to get across it, are claims, and a reader absorbs them before reading a word. I drew the Velocity Loop to show flow of value and design-in-progress (DIP) through complex product development. A year of feedback later, the sharpest thing people told me was that the picture showed a bottleneck. Here is what they caught, what I changed, and the question I am handing back to you.
Update: I got a lot of feedback on the revision. Thank you to all who contributed. Based on the feedback, I made another revision that is much closer to the original. Therefore, the following is outdated. I leave it here to document the Product Velocity Journey.
(more…)How Product Velocity Can Save Mercedes
Why companies stay slow #5. Requiring employees to work more hours will not save Mercedes. Clear objectives and honest metrics will.
Early July 2026, Sindelfingen. Around 20,000 Mercedes employees stand in front of the plant gate chanting “Ola raus.” The trigger is an email, signed by the entire board, sent to every employee in Germany. Its key sentence, translated: “We should work more in all areas for the same money.” For most of the workforce that means moving from 35 to 40 hours per week. Five more hours, same pay.
Mercedes calls this a productivity offensive. And that is the paradox worth staring at: a company in genuine crisis, run by capable people, responds to a collapse in output by increasing input. Mercedes’ problem was never the number of hours. It is what happens during those hours. Adding five more of them changes nothing about that, and the workforce at the gate knows it.
(more…)A Method Travels Faster as a Story Than as a Manual
Kessler Seven is a Scifi novels that tells the story of saving ten thousand lives by fixing broken handoffs and gates.
Two of the most influential operations books of the last forty years are novels. Not case studies, not frameworks with a fold-out poster in the back. Novels, with characters and a plot and a villain who turns out to be human. Eliyahu Goldratt taught a generation of factory managers the Theory of Constraints in 1984 by writing a story about a plant manager with ninety days to save his factory. Gene Kim did the same for IT in 2013, and The Phoenix Project became the book every DevOps team quietly hands to the new hire.
The manuals on the same subjects sold a fraction as many copies. That is the part worth sitting with. The rigorous, complete, correct treatment of an idea loses, again and again, to the version with a protagonist and a deadline.
(more…)(AI) Automation Without Acceleration
Product Velocity Principles #3. Automation, especially with AI, can slow things down. Consider Little’s Law.
A software team adopts an AI coding assistant and its output doubles. Pull requests pile up. Commits per developer climb. The engineering dashboard turns a satisfying shade of green. Six months later, the same number of features have reached customers as the year before. The work got faster. The product did not.
This is not a story about overhyped AI. The assistant did exactly what it promised. It is a story about where speed enters a system and where speed leaves it, and why those are rarely the same place. AI is about to make a great many slow organizations faster at the one thing that was never their problem.
(more…)Germany Doesn’t Have a Housing Shortage. It Has a Flow Problem.
Architecture and Flow #4. The anti-pattern that is freezing an entire country: A Case Study on the German housing crisis.
Germany is one of the richest, most engineering-proud nations on earth. It builds machines the rest of the world copies. It has capital, materials, skilled labor, and a population that genuinely wants more housing built. And yet, year after year, the country misses its own construction targets by hundreds of thousands of units, rents climb, and politicians line up to announce the same remedy: more money, faster permits, fewer regulations — see, for instance, the federal government’s housing measures package.
Here is the uncomfortable part. Most of that debate is aimed at the wrong place in the system.
(more…)Conway’s Law Is Only Half the Story: Meet Conway Drift
Product Velocity Principles #3. Conway drift happens when there is misalignment between product architecture and organization architecture.
Most engineering leaders have heard of Conway’s Law. Far fewer have heard of Conway Drift, and that gap is precisely where a lot of organizations quietly lose their velocity.
Conway’s Law is one of those observations that sounds almost too simple to be useful, right up until you watch it govern the fate of a multi-year product program. Conway Drift is its slow-motion sequel: what happens after you’ve gotten the structure right, when nobody is watching the alignment erode. The first is a snapshot. The second is a trajectory.
This article walks through four things: what Conway’s Law actually claims, why Conway Drift is the more dangerous failure mode, how to diagnose it in your own organization, and what to do once you’ve found it.
(more…)One Pilot Slot for a 30-Day Product Velocity Intervention
In summer 2026, I make one reduced fee pilot slot for a 30-Day Product Velocity intervention available.
Many companies have Agile, MBSE, DevOps, ASPICE, PLM, ALM and still develop too slowly. I don’t think the missing piece is another method.
The missing piece is usually clarity about where the product loses time. This sounds easier than it is.
Most organizations look at product development through functions, tools, processes, or improvement initiatives. Product Velocity looks at the flow of the product itself: decisions, dependencies, feedback loops, architecture choices, requirements, tests, supplier input, reviews, and rework.
This is why I am opening one reduced-fee pilot slot for a 30-day Product Velocity intervention.
The goal: Identify the strongest current flow constraint in one product development area, run one targeted intervention, and measure its effect after 30 days.
(more…)It’s Not the Engineers
Why Companies Stay Slow #4. Germany and Europe are not losing because their engineers are bad: Their development systems learn too slowly.
Porsche was the most profitable car brand in the world, the cathedral of German engineering. In 2025, Porsche booked roughly €3.9 billion in special charges to unwind an electric strategy it had committed to, with great confidence, only a few years earlier. Automotive operating profit collapsed by 98 percent. The stock lost a third of its value. The company was ejected from the DAX, the index of Germany’s industrial champions.
Seven years earlier, in 2018, Porsche had committed over €6 billion to go electric. Then it reversed course. Add it up and you get something close to a €10 billion round trip that ended roughly where it started.
(more…)Four Principles, Two Speeds
Expert Opinions #1: The interview with Yuchao Luo shows that China is already applying Product Velocity, while Germany is hesitating.
18 months. That is how long BYD takes from concept to market for a new car. Volkswagen announced in 2025 that it had compressed its own cycle to 40 months. The announcement was framed as a milestone. The gap has not narrowed: it has grown more visible, in the dimensions that matter most. But this is not about Germany vs. China, it’s about traditional systems engineering vs. Product Velocity.
The Product Velocity framework describes four principles that separate fast-moving product organizations from slow ones: Value Thinking, Architect for Flow, Shift Left, and Accelerate. Yuchao Luo, who worked inside both a Volkswagen joint venture and NIO, put those principles into concrete form in a recent interview. He did not come to celebrate China Speed. He came to explain it. The explanation is uncomfortable for anyone who wants to attribute the gap to cheap labor and state subsidies and leave it there.
Upcoming Webinar on Wednesday (May 27), 17:00 CET: How to Run a 30-Day Product Velocity Intervention >>
(more…)
English
German