AI, Product, and Delivery
We never tracked “delivery speed” until the CEO asked for one number. Two sprints later, we were “faster” and member complaints doubled.
This was a regional health insurer rolling out a new mobile app and prior auth workflows. Small product team, lots of vendor code, and a weekly exec review that wanted clean green arrows.
So we put velocity and tickets-closed on the slide. Within a month, stories got smaller, estimates got softer, and anything risky got pushed to “next sprint.”
The weird part is nobody was being dishonest. They were just responding to the scoreboard.
The hidden tradeoff was that speed became a target, not a signal. Rework moved off the plan and into production, where it costs real money: call center time, nurse reviews, outage bridges.
In January, that gets sharper because budget gates and audit prep collide, and a single red metric suddenly has a name attached to it.
The only thing that calmed the room was pairing every speed metric with a quality or risk metric, then reading the trend, not the threshold. Cycle time next to post-release incident hours told the truth when velocity wouldn’t.
It makes me wonder whether we ask for metrics to see reality or to feel in control.