Articles
Writing on Product Velocity
Updates
2 x per month. New articles, webinars, videos, trainings. Unsubscribe any time.
Why Most Case Studies Are Useless
Product Velocity Case Studies #1. Useful case studies explain mechanisms, trade-offs, and organizational structure.
Case studies play a strange role in product development. Everyone claims to value them, yet most case studies end up as polished success stories, stripped of the very details that would make them useful.
With Product Velocity, I want to treat case studies differently.
(more…)Architecture Decisions That Silently Destroy Velocity
Architecture and Flow #3. Architecture determines whether change flows smoothly or stalls in coordination.
Most organizations experience slowing delivery as a problem of execution. Teams are too slow, integration takes too long, releases slip. The instinctive response is to optimize process, tooling, or staffing. Yet in many cases, velocity was already lost long before design started. It was lost when architecture decisions fixed how change would propagate through the system.
Architecture does not make products fast or slow by itself. It determines the cost of change. Once boundaries, interfaces, and dependencies are in place, every future decision either flows smoothly or stalls in coordination. This post is anchored in Part III – Systems Architecture and distills a simple but uncomfortable thesis: architecture is an economic decision about delay. Get it wrong, and no amount of process optimization will recover velocity later.
(more…)What Value Stream Mapping Misses in Product Development
DevOps for Physical Products #1. Product development requires mapping information flow, not only material flow.
The book Learning to See by Mike Rother and John Shook is the canonical introduction to value stream mapping. Its scope is unapologetically grounded in production and logistics. Physical material moves. Inventory piles up. Lead time can be measured with a stopwatch and a clipboard.
That focus is a strength, not a limitation. The book teaches a way of seeing systems. Once you understand the logic, the leap from shop floor to product development is smaller than it looks. This post first reviews the book as written. Then it explains how its ideas apply directly to Product Velocity.
(more…)Why Faster Teams Still Deliver Slowly
Why Companies Stay Slow #2. Local efficiency improvements rarely solve systemic development bottlenecks.
Traditional product companies face an uncomfortable reality. Competitors emerge seemingly from nowhere with products that are more innovative, faster to market, and often dramatically cheaper. The instinctive response is to look for efficiency gains: faster tools, leaner processes, more automation at the workstation level. Yet organizations that pursue this path often discover that their overall development velocity remains stubbornly unchanged, or even declines.
This is not a failure of execution. It is a failure of paradigm.
(more…)The Velocity Loop Explained: DevOps for Physical Products
Velocity Loop Explained #1. The Velocity Loop adapts DevOps principles to cyber-physical product development.
Most organizations sense that their product development is slower than it should be. Fewer can point to where the slowdown actually happens. The Velocity Loop gives you that diagnostic in one view. It lets you see:
- Where intent stalls
- Where decisions pile up
- Where feedback gets lost,
- Where learning never makes it back into the system
High product velocity is an operational requirement for any organization building complex, cyber-physical products. The real challenge is not whether speed is possible, but how to achieve it in a systematic and repeatable way. The Velocity Loop addresses this challenge by transferring the core logic of DevOps to physical products, by adapting continuous feedback and integration to environments where hardware, software, and operations evolve at very different speeds.
At its core, the Velocity Loop connects four practices. Business, System Stewardship, Engineering, and Delivery. Together, they form a closed system that turns intent into results and results back into learning. As you read on, you can already use the loop as a mirror.
(more…)Product Velocity Is Now a Competitiveness Problem
Why Companies Stay Slow #1. China Speed. Organizations that cannot accelerate product development risk losing competitiveness entirely.
Speed has long been discussed as an efficiency topic. Shorter lead times. Fewer handovers. Better tools. These conversations miss the point. It is no longer optional to follow a new approach for Product Velocity.
Product Velocity is not about doing the same work faster. It is about whether organizations remain viable at all.
(more…)Product Velocity at 4 Events in Spring 2026
Register now for the Product Velocity half-day workshop on April 27, 2026 in Munich and save 10% with the discount code below.
Not just ReConf a talk and a workshop on Product Velocity have been accepted. Here are all my spring events:
March 31: Conquering Complexity, Zurich(past)- April 27–29: ReConf, Munich (Get 10% off with Promo code: REC26_SPRE_2523)
- May 7/8: Mesconf, Munich
- June 8/9: MBSE Summit, Traunkirchen
If you are working on accelerating hardware or cyber-physical product development, meet me there!
👉 Register now and get 10% off with Promo code: REC26_SPRE_2523
(more…)Using the 4 Principles to Structure the Book
High-velocity organizations share four recurring structural principles.
Update: I published this initially in November 2025, after having written roughly a third of draft content. At this point I decided to build the book around these 4 principles of Product Velocity.
Read this article for a more in-depth coverage.
(more…)Your Peers Already Solved the Problem You’re Stuck On
Knowledge Flow #1. The first Product Velocity Mastermind showed that the bottleneck is rarely missing knowledge. The bottleneck is getting it to flow.
We ran the first session of the Product Velocity Mastermind last week.
One member brought a real problem to the hot seat: how to get engineering teams to actually adopt a model-based approach when the toolchain is unfamiliar and the deadline is real.
What happened next wasn’t a framework from a consultant. It was 15 people who had each hit the same wall, from different angles, comparing notes in real time. Within 20 minutes, the person in the hot seat had three approaches they hadn’t considered, including one that had already failed at another company, and exactly why.
(more…)What Engineering Leaders Asked After My Product Velocity Keynote
Questions and discussions from a keynote on accelerating cyber-physical product development.
I conducted the keynote on Product Velocity at Modern RE in Leipzig. Preparing for the keynote also helped me to keep the big picture for the book in mind.
If you are interested in this keynote to present to your team in your company (or in any other setting), please reach out.
English
German