Register for the Upcoming Workshops and Talks in Munich and Zurich: More below
Across many engineering organizations, the same pattern repeats: development cycles for complex physical and cyber-physical products remain stubbornly long, even as tools improve and teams gain experience. At the same time, global competitors demonstrate that radically shorter cycles are possible.
This gap is not explained by effort or competence alone. It is structural.
Product Velocity addresses this structural challenge. It provides a way to reason about how organizations can develop physical products with a cadence and learning speed closer to software development—without compromising safety, quality, or regulatory compliance.
In spring 2026, I will present Product Velocity in several live formats. These events are the most effective entry point if you want to understand the approach in a concrete, applied way.
What is Product Velocity?
Product Velocity is a system-level perspective on product development speed.
Rather than optimizing individual practices or phases in isolation, it focuses on how value flows across business decisions, system architecture, engineering, verification, and delivery. In complex products, delays typically emerge from misalignment between these domains, not from a single bottleneck.
Product Velocity provides:
- a shared language for reasoning about speed and learning
- a small set of principles to guide trade-offs
- a framework for identifying where feedback cycles break down
The objective is not speed for its own sake, but faster learning and better decisions earlier, when change is still affordable.
Why does it matter?
Many organizations lose development speed long before implementation begins.
Integration is batched late, validation is treated as a downstream phase, and architecture becomes difficult to evolve. Teams compensate with additional coordination and rework, but the underlying structure remains unchanged.
The result is familiar:
- Long feedback cycles
- Late discovery of constraints
- Increasing development risk
- Rising organizational friction
Product Velocity matters because it shifts attention from local efficiency to overall system behavior. It helps teams understand why speed is lost and what to change first, rather than applying generic best practices.
Learning how it is applied in practice
To ground these ideas, Product Velocity is supported by a growing set of case studies drawn from real products and organizations. Each case study focuses on a specific decision, subsystem, or constraint rather than telling a complete product story.
These examples illustrate, for instance:
- how architectural decisions influence flow
- how continuous integration changes learning dynamics
- how early validation can collapse feedback cycles
On the Product Velocity Website, these case studies serve primarily as background and evidence. The most effective way to engage with the material, however, is through live discussion and hands-on exploration.
Spring 2026: Meet me at these events
If you are working on accelerating hardware or cyber-physical product development, I invite you to meet me at one of the following events this spring.
- March 31, 2026 – Conquering Complexity (Zurich)
Workshop on Product Velocity (Free event) - April 27–29, 2026 – REConf 2026 (Munich)
Talk and Workshop on Product Velocity
Get 10% off with promo code: REC26_SPRE_2523 - May 7–8, 2026 – MESCONF (Munic)
Barcamp Session on Product Velocity
Product Velocity Book by Michael Jastram
Product Velocity is not a methodology or framework: It is a way of seeing product development differently. And I am writing a book on this important topic with MIT Press, to be published lster this year.
If development speed, learning cycles, and system-level trade-offs are central to your work, I invite you to join one of the upcoming events and explore these ideas in a live setting.
I’ll keep you posted on Product Velocity on the Formal Mind Blog. Alternatively, register at the Product Velocity Blog for weekly updates. More material will follow, always with a focus on applicability and clarity rather than volume.
