The build took three days. The feature shipped three weeks later.
I watched this happen on a billing integration years ago, back when I was running IT operations for a Saskatchewan telecom. The engineer finished the actual work in about three days of real effort. Then the change sat. It waited two days for a code review because the one person who understood that subsystem was heads-down on something else. It waited another four days in a QA queue behind a stack of higher-priority tickets. It waited on a staging environment that a different team had booked for a load test. It waited on a release window because we batched deployments to Thursdays. By the time customers could actually use it, nineteen calendar days had passed, and roughly three of them involved anyone touching the work.
That ratio is not unusual. It is the norm. And most product managers never see it, because we track the wrong thing.
We measure how fast people work. We should measure how long work waits.
When a feature is late, the reflex is to look at the people doing the work. Are the engineers fast enough? Is the estimate wrong? Did scope creep in? Those are real questions, but they aim at the small slice of the timeline where work is actually moving.
There is a metric that aims at the rest of it, and it is one of the most clarifying numbers a delivery-focused PM can learn. It is called flow efficiency, and the formula is almost insultingly simple:
Flow efficiency = active work time ÷ total elapsed time
If a feature takes twenty working days from “started” to “shipped,” and someone was actively advancing it on four of those days, your flow efficiency is 20 percent. The other 80 percent was queue time. Waiting.
Here is the part that surprises most teams the first time they measure it. According to benchmarks compiled from engineering delivery data, most software teams run at 15 to 40 percent flow efficiency. High-performing teams reach 40 to 60 percent. Genuinely world-class delivery sits around 60 to 70 percent. Nobody hits 100, and nobody should try. But a typical team spends 60 to 85 percent of a feature’s lifespan with the work sitting idle, blocked, or waiting in a queue.
Read that again if you manage a roadmap. The dominant cost in your delivery timeline is usually not the work. It is the waiting between the work.
Why waiting is invisible
Wait time hides because no one owns it. When an engineer is coding, there is a name attached to the task and a person you can ask for a status. When a pull request sits unreviewed for two days, it belongs to nobody. It is not on anyone’s plate, which is exactly why it stays where it is.
The common sources are boringly consistent across every team I have worked with or advised through my fractional operations work. Code review queues are usually the single largest one. Then approval gates, cross-team dependencies, testing backlogs, staging environment contention, and release-window batching. None of these show up in a story-point estimate. All of them show up in the calendar.
This is why the estimate can be accurate and the delivery can still be late. The estimate measured the work. The calendar measured the work plus the waiting, and the waiting was four times larger. If you have ever defended a slipped date to a stakeholder while privately knowing the engineers did nothing wrong, this is the gap you were standing in. It is the same trap that turns every estimate into a deadline: the number you gave described active effort, and the world measured wall-clock time.
The counterintuitive fix: start less
The instinct when delivery feels slow is to push more work into the system. More features in flight, more tickets assigned, more parallel streams so nothing sits still. This makes the problem worse, and there is a law that explains why.
Little’s Law, borrowed from queuing theory, states that average cycle time equals work-in-progress divided by throughput. In plain terms: the more things you have in progress at once, the longer each individual thing takes to finish, even if your team’s capacity never changes.
The worked example is worth internalizing. A team with 24 stories in progress that completes 8 per week has an average cycle time of three weeks. Want to cut that to two weeks without adding a single person? You do not hire. You reduce work-in-progress from 24 stories to 16. Fewer things started means each thing finishes faster, because it spends less time waiting behind everything else you started.
This is the entire logic behind work-in-progress limits, the deceptively simple Kanban practice of capping how many items can be active at once. When the cap is hit, nobody starts anything new. Instead, the team swarms to finish what is already open. Teams that have applied WIP limits have reported cycle-time reductions of 20 to 30 percent with no change in headcount. The gain does not come from working harder. It comes from letting fewer things wait.
I have made this argument in operational reviews more times than I can count, and it always lands the same way: as a threat. Cutting WIP feels like doing less, and doing less feels like falling behind. It is the opposite. A queue with fewer items in it moves faster. The work you did not start yet was not helping you anyway. It was just aging in a line.
Small batches beat big releases
The other lever is batch size, and the industry’s best delivery data is unambiguous about it. The 2024 DORA State of DevOps report found that the roughly 19 percent of teams classified as elite performers ship small, contained changes to production continuously, often many times a day. Deployment frequency, in the DORA framing, is really a proxy for batch size. Elite teams are not superhuman. They just move work in small pieces so nothing waits for a big Thursday release train.
For a product manager, this is a roadmap decision disguised as an engineering one. Every time you insist a feature ship as one complete, polished release rather than a sequence of smaller shippable slices, you are choosing a bigger batch. Bigger batches wait longer, integrate harder, and fail bigger. Smaller slices flow. This is the same instinct behind shipping the minimum viable version that tests your riskiest assumption rather than the whole thing at once, applied to delivery rather than discovery.
What to actually do with this
You do not need a flow-metrics dashboard to start. You need to measure one thing on one feature.
Take a recently shipped feature. Find the date work started and the date it reached customers. That is your total elapsed time. Now ask the engineers who touched it, honestly, how many days involved active work on it. That ratio is your flow efficiency for that feature. Do it for three or four recent items and you will have a number, and the number will almost certainly be lower than anyone guessed.
Then look at where the waiting happened. If it clustered in code review, the fix is a review service-level agreement or a WIP limit, not a faster engineer. If it clustered in QA, the constraint is downstream and pushing more work in makes it worse. If it clustered in release batching, you have a process choice to revisit, not a capacity problem. The point of the number is that it tells you which lever to pull, and it is almost never the lever labeled “make the people go faster.”
The uncomfortable truth for those of us who came up managing delivery is that most of the time we spent chasing productivity was aimed at the 20 percent of the timeline where work was moving. The 80 percent where it waited went unmanaged because it was nobody’s job. Making it your job is one of the highest-leverage things a PM can do for a delivery team, and it costs nothing but attention.
The feature that took three days to build and three weeks to ship was not a story about slow engineers. It was a story about a fast piece of work standing in four different lines. Once you learn to see the lines, you cannot unsee them, and you stop trying to fix delivery by pointing at the one place where something was actually happening.