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.
Where the loop started
I built the first Velocity Loop about a year ago. The goal was a DevOps loop for cyberphysical products: the same continuous, closed cycle that reshaped software development, redrawn for systems where hardware and software evolve at different speeds. Four practices, with Business, Engineering, and Delivery around the outside and System Stewardship coordinating from the center.
One rule mattered above the rest. Keep the loop closed. Output from each practice becomes input to the next, value keeps moving, and nothing leaks out as waste. On that measure the first version worked. The loop was closed, and it read as a loop.
What readers saw that I had not
I used the loop to capture case studies, mapping how real companies build. That worked. Each case lit up a different part of the loop, and the diagram held.
Then I asked people what the loop itself was telling them. The same answer came back more than once. System Stewardship looks like a bottleneck. In the first drawing, every hand-off between practices ran through a stewardship segment in the center, even though that segment was unlabeled. Read as a systems diagram, that says nothing moves without clearing the middle first. Every hand-off implies a checkpoint.
The prose said the opposite. System Stewardship exists to enable flow, and the book names the failure mode for when coordination hardens into control. It calls this anti-pattern Governance Overreach. But the figure implied the gate, and the figure is what people carry out of the room.
A second problem sat underneath the first. The unlabeled connectors had no consistent meaning. Sometimes a line stood for a direct hand-off, sometimes for a transformation, and nothing in the drawing told the two apart.
The idea behind the redraw
The new loop makes two changes. Practices now connect directly. Engineering hands to Delivery across a direct link, and System Stewardship steps off the critical path to sit beside the flow, supporting the hand-off and closing the loop without standing in the middle of it.
The connectors now carry a fixed meaning, because there are two kinds of flow and the old drawing treated them as one. A direct hand-off moves a finished DIP. Engineering designs, Delivery builds, nothing changes in between. A transformed flow has to pass through the center, because it is being converted on the way. Raw field data is not yet a business decision until stewardship evaluates it against the architecture and the value model. The redraw shows which is which: a direct line between practices when the artifact just moves, and a path through a stewardship activity when something genuinely has to change form.
Two case studies, then your call
I have applied the new loop to two cases so far. The SpaceX Raptor case is a tight loop between Engineering and Delivery: design a change, build the engine, fire it on the test stand, feed the result into the next design, roughly every two days. That hand-off is direct, and stewardship stays beside it, holding the architecture stable so each change stays local. The Ameru case is the opposite shape. Operational data from deployed bins reaches Business only after stewardship turns it into a measured economic deviation. One loop closes directly, the other closes through the center, and for the first time the drawing tells them apart.
Both are live on the site, and I have changed only these two on purpose. If the new loop reads truer to the people who use it, I redraw the rest. So tell me: when Engineering hands work to Delivery in your organization, does coordination sit in the middle as a gate you clear, or beside the flow as the thing that keeps it coherent? Reply with the version you would keep.
What this means for the book
The Velocity Loop is the spine of a book manuscript now under review with MIT Press. The first round of reviewer feedback came back positive. I revise in August, and this change goes in with it, which is the real reason the timing matters. A diagram in a printed book is hard to take back. Better to catch the bottleneck I drew by accident now, while the ink is still wet.
English
German