The Velocity Loop: A DevOps-inspired model for physical products
Most organizations have realized that their product development is slower than it should be. Fewer can name it, where the slowdown really occurs. The Velocity Loop provides you with exactly this diagnosis in a single view. I developed the Velocity Loop for my Book Product Velocity developed.
In the following, I will describe how the Velocity Loop helps in practice and what components it consists of.
The Velocity Loop helps you to recognize:
- Where Intent comes to a standstill
- Where decisions come together
- Where feedback is lost
- Where learning never finds its way back into the system
From the perspective of classic systems engineering, this is not just an implementation problem. It is a System problem. Traditional process models often rely on linear phases, early completeness and the illusion of eliminating uncertainty through specification. This occasionally works for simple products, but for complex, cyber-physical products However, it often leads to late learning, expensive rework and an organization that slows itself down.
Product velocity is therefore an operational requirement for organizations that build complex systems. The real challenge is not, whether speed is possible, but how you can achieve it systematically and repeatably. The Velocity Loop addresses precisely this by transferring the core logic of DevOps to physical products. In concrete terms, this means that continuous feedback and integration are adapted so that hardware, software and operations are allowed to evolve at different speeds without the overall system performance collapsing.
At its core, the Velocity Loop four practicesBusiness, System Stewardship, Engineering and Delivery. Together they form a closed system that translates intent into results and results back into learning. When reading, you can already use the loop as a mirror, not abstractly, but along your real handovers, committees and waiting times.
Business: From specification to direction
In traditional product development, business is often positioned as a source of detailed specifications. It is assumed that clarity at the beginning leads to less risk later on. In practice, the opposite often happens. You freeze assumptions before they are validated and move learning to the most expensive point of the lifecycle. This is exactly where classic systems engineering in its strictly phase-oriented form collides with the reality of complex markets and technologies.
In the Velocity Loop, the role of business changes fundamentally. Instead of prescribing solutions, business defines Direction. This includes value hypotheses, priorities, constraints and measurable success criteria that guide decisions in the organization. The goal is not completeness, but relevance. A Minimal Viable Product (MVP) is not „viable“ because it has many features, but because it is actual value generated and produces usable feedback.
The remaining challenge is not whether it can be done, but how to get there in a systematic and repeatable way.
Michael Jastram, Product Velocity
Business sets this direction and at the same time accepts that alignment is continuous and not a one-off event. Feedback from delivery flows back into the business loop. This allows priorities to evolve based on evidence rather than assumptions. From a classic perspective, this is a shift from „requirements as a contract“ to „requirements as a hypothesis space“ without losing the demand for traceability.
System stewardship: translating data into decisions
System stewardship is the least understood and most critical practice in the Loop. It is often confused with documentation, governance or process accountability. In reality, it is a Decision-making and structural function. Your task is to develop the system architecture as a living asset. maintain and further develop, so that flow becomes possible over all other practices.
If you are familiar with classic systems engineering, then you will be familiar with architecture work. The difference lies in the focus: system stewardship is not primarily artifact production, but the active management of decisions, interfaces and dependencies over time. It transforms raw input from business and delivery into structured information that engineering can work with. It makes architecture trade-offs explicit, manages interfaces and preserves knowledge as a single source of truth. The goal is not more documents, but better decisions at the right time.
System Stewardship provides this coordination and serves as the stable anchor that aligns business intent, engineering work, and delivery.
Michael Jastram, Product Velocity
This role becomes particularly important when hardware and software collide. Hardware changes are slow and expensive after deployment. Software evolves quickly and with low marginal costs. System stewardship owns these asymmetries. You make commitments visible and comprehensible so that different change dynamics do not become organizational friction. Classically, you would say: you keep the system integrity stable without sacrificing the learning rate.
Engineering: Design for flow, not for local efficiency
Engineering is the place where ideas become reality. In many organizations, however, engineering is still optimized for local efficiency instead of end-to-end flow. Teams optimize workloads, handovers multiply and feedback comes late. This is a typical symptom of classic, functionally structured organizations: Mechanics, electronics, software and testing each work „optimally“, but the system as a whole is slow.
In the Velocity Loop, engineering is guided by structured input from system stewardship. Ideally in the form of clear Black box definitions, that specify behavior and interfaces, while implementation decisions remain with the teams. This creates space for parallel work without losing coherence. This gives you a modern interpretation of architecture and interface management that does not rely on rigid phases.
The same principle applies to software, mechanics and electronics: optimize for flow. Limit work in progress. Reduce dependencies. Verify early. In software, this logic is established through automated tests and continuous integration. In hardware, the tools are different, but the goal is identical. Early simulation, virtual testing and model-based approaches shift learning to where it is still cheap. From a systems engineering perspective, this is the consistent operationalization of shift left in a world in which prototypes, prototype construction and qualification are real cost blocks.
Packaging also follows the same logic. Stable interfaces and downstream readiness are technical enablers for continuous integration in environments where physical and digital elements have to evolve together. If you don't design this consciously, integration becomes an event and not a routine. And that's where speed disappears.
Delivery: Where assumptions meet reality
Delivery is often reduced to production and deployment. In the Velocity Loop, the scope is larger. Development, operation and monitoring are integral components of the development system. Traditional systems engineering often treats operation as a downstream topic or hands it over to other organizational units. The loop forces you to understand operation as part of the development reality, because this is where the truth about your system is created.
For hardware, delivery includes the physical realization under the constraints of tooling, supply chains and manufacturing processes. For software, it often means configuration and updates. Both coexist in cyber-physical products. If you treat them separately, the result is uncoordinated cycles and missed learning opportunities. You then get fast software releases that are crushed by a sluggish hardware change strategy. Or you get stable hardware that is slowed down by an overly conservative update practice.
Operations is the place where value is ultimately created or destroyed. Decisions from development must anticipate what happens after deployment. Bug fixes, performance optimizations and feature upgrades are the norm. Delivery therefore includes the systematic collection of operational data as a design goal. Not as an afterthought, but as part of the system architecture.
Monitoring closes the loop. Usage data, test results and field data become feedback that informs both business priorities and architectural evolution. In advanced cases, this feedback changes entire business models, such as when companies move from product sales to profit responsibility. From a classic perspective, this is the step from „acceptance“ to „continuous verification in the field“.
Why the loop counts
The Velocity Loop helps to identify where flow breaks down and where learning is delayed. It makes it clear that speed is not primarily an execution problem. It is a system design problem. And so it lies right at the heart of what systems engineering is actually supposed to do, albeit with the addition of consistent feedback from delivery and operation.
By making the interactions between business, system stewardship, engineering and delivery explicit, the loop makes coordination a first-class task. You can manage the inherent tension between hardware stability and software adaptivity without slowing down one to protect the other. It is precisely this decoupling through clear interfaces, consistent feedback paths and conscious architecture management that makes the difference between „we're just slow“ and „our system is built so that it can't be fast“.
The Velocity Loop does for physical products what DevOps did for software. It replaces linear thinking with closed-loop learning. Not to move faster at any cost, but to move with purpose, clarity, and sustained impact.
Michael Jastram, Product Velocity
You should now be able to identify in your own system where your velocity loop breaks. Not abstractly, but in concrete handovers, waiting times, committee loops and lost feedback channels. This is exactly where the value of the model lies. It doesn't just tell you to be faster. It shows you where your system structurally prevents speed, and therefore where changes actually have an effect.
