Speed with no feedback loop is not velocity. It is waste, moving fast.
Every product team wants to ship fast. Sprint reviews measure story points, not whether the last feature moved a number. I have sat in that room at three companies, supply-chain platforms at Dell, a 20-person AI creative team at Pixis, the data platform under InMobi’s ad exchange, and asked the same question each time: fast toward what?
Nobody answers that question well, because the honest answer exposes the cost. Teams that ship without a feedback loop do not create value faster. They compound waste faster.
So that’s today’s post.
Today’s Post
Why velocity and progress are not the same thing, and what to build instead, in five sections.
- Why velocity is not progress, with a real number on the gap
- The feedback loop that turns shipping into learning
- Where the cost of skipping it actually lands
- The trap teams fall into when they try to fix speed with more speed
- What “good fast” looks like, built as a four-step loop
1. Velocity is not progress
Velocity measures throughput: story points closed, features shipped, deploys per week. It says nothing about whether any of that changed a customer’s behavior or moved a business metric.
A team can hit every sprint estimate and still build a product nobody wants. The board sees a productive team. The customer sees nothing that helps them.
I have watched teams that were fast and wrong at the same time. They were not lazy or incompetent. They were fast in the wrong direction, because nothing in the process forced them to check.
2. The feedback loop is the product
Speed without a feedback loop is just motion. The loop is what turns that motion into learning: define what success means, build the thing, instrument the behavior, review against the target, record the verdict.
A team optimized for shipping resists anything that slows the pipeline: user research, instrumentation, kill criteria. Those feel like drag on the belt.
A team optimized for learning protects those same things, because it already knows that shipping without a loop is guessing at scale.
I own the system of record under a DSP and an exchange that measure ad events from 200M+ devices a day at InMobi, and the month-end revenue close on that data went from 5 days to 12 hours. Dashboards were never the constraint there. What changed the number was the loop: a written target, a review that happens on a fixed date whether anyone asks for it or not.
3. Where the cost actually shows up
The cost of shipping without a loop rarely shows up in the sprint that caused it. It shows up later, in a place nobody traces back to the original decision.
Dead code from features nobody re-measured. The team shipped it, moved on, and never went back to check. It still sits in the codebase, maintained and deployed, for zero return.
Learning that never happened. Every sprint spent on the wrong feature is a sprint not spent finding the right one. The lost work is not the only cost. The lost learning is the bigger one.
A team that stops trusting its own launches. At Pixis, the counter-example I lean on: a two-week onboarding sprint for new AdRoom brands had one hard goal, get the brand self-serving live, on-brand ads inside the window. We instrumented activation, meaning a published ad, and ignored logins entirely. Four brands later, that sprint had produced $800K ARR in two months, and the full motion reached $0 to $10M ARR in five months with a 20-person team.
Had we counted logins instead, we would have declared victory in week one and learned nothing about the real wedge.
4. The speed trap
When a team ships fast and outcomes stay flat, the instinct is to ship faster. “We just need to iterate.”
But iteration without a feedback step is not iteration. It is repetition with the same assumptions. The team gets faster at executing and no better at choosing what to execute next.
This is why the more disciplined teams deliberately slow down one part of the process: they write the hypothesis before design locks, and they book the outcome review on the day they ship, not after. At InMobi and at Pixis both, the review that mattered ran on a calendar that already existed, a monthly close, a two-week sprint window, not one invented after the fact.
5. What “good fast” looks like
Fast is not the problem. Unmeasured fast is the problem. The teams that ship well and ship fast share four habits, and they map onto the loop in section 2.
Step 1, write the hypothesis first. Target user, target behavior, one metric, one horizon. Written down before the first commit, not discovered after launch.
Step 2, instrument during the build. If a feature cannot be measured, that is a decision to say out loud, not a gap to discover three sprints later. At Pixis, the Data Platform and Execution Engine I stood up first cut availability delay from 4 hours to under 15 minutes for 400+ enterprise customers, and none of that instrumentation demoed well. It is the reason the layer built on top of it was worth trusting.
Step 3, review on the date you wrote down. Not when the backlog has room. On the date. A close that runs every month gets reviewed twelve times a year whether anyone likes it or not. Put that same inevitability on a feature review.
Step 4, record the verdict. What you believed, what you tried, what happened. This is the asset a decision log gives a team that a Slack thread never does.
None of this is slow. It is disciplined, and the discipline at the front saves the time that would otherwise leak out the back.
Takeaways
Five panels, one per section. Pick the last feature your team shipped and run it through the loop.
Final Words
Shipping fast is a capability, not a strategy. Like any capability, it is only as valuable as the judgment that points it somewhere.
Take the last feature your team shipped. Write the hypothesis it should have had before it shipped. Book the review, on a real date, this week.
Reply and tell me what you find.
Cheers, Hoshank