Fundamentals - Product Management Resources

Years ago, running network operations at a large telecom, I watched a team beat its weekly target for three straight quarters while getting quietly worse at the actual job. The number we tracked was completed change tickets per week. Leadership wanted it climbing, so it climbed. What I only saw later was how. One messy change that used to be a single ticket became four smaller ones. The easy tickets got closed first and reported loudly. The risky, tangled work slid to the bottom of the queue where it stopped hurting the dashboard. The line went up and to the right. The network got no safer, and in a couple of places it got worse. Nobody on that team was lazy or dishonest. They were responding, rationally, to the thing they were being graded on. That is the pattern behind almost every metric that goes bad, and product teams have their own version of it sitting in plain sight on the sprint board. It is called velocity. The number was never meant to leave the room Velocity started as a forecasting aid. A team estimates its backlog in story points, tracks how many points it tends to finish in a sprint, and uses that average to guess how much of the next few months is realistic. That is the whole job. Mike Cohn, who did as much as anyone to popularize the practice, is blunt about its limits: velocity "bounces around in about a plus or minus 20% range" and is "simply too variable to be useful in the short term," which is why he prefers planning a single sprint by listing actual tasks rather than trusting a velocity number (Mountain Goat Software). He also calls himself "quite likely the world's biggest fan of using velocity to plan for the longer term." Both things are true at once. It is a decent long-range compass and a terrible short-range grade. The trouble starts the moment that internal compass gets lifted out of the team and pinned to a performance review or an executive slide. A forecasting tool becomes a target. And there is a well-worn law about what happens next. When a measure becomes a target Marilyn Strathern's 1997 phrasing of what is now called Goodhart's law is the cleanest statement of the problem: "When a measure becomes a target, it ceases to be a good measure" (Goodhart's law). The economist Charles Goodhart had made the narrower point about monetary policy in the 1970s; Strathern generalized it into a rule about any human system you try to steer by a single number. Point at a metric hard enough and people will move the metric, which is not the same as moving the thing the metric was standing in for. Velocity is unusually easy to move. Scrum.org's own material walks through thirteen distinct ways a team can inflate its velocity without doing one bit more real work (Scrum.org, Gaming Velocity). Re-estimate the same kind of card a little higher this quarter than last. Split one story into three and let the parts sum to more than the whole. Start counting bug fixes and technical-debt cleanup in points. Quietly adjust the definition of done so more items cross the line. None of these ship a single additional feature. Every one of them makes the chart climb. Story point inflation is the most common of the set, and it is almost invisible while it happens. A card that scored a 3 last spring scores a 5 by autumn, capacity is flat, and velocity rises by two-thirds on paper. Everyone can feel the team working just as hard as before, so the higher number reads as progress rather than drift. This is exactly what my telecom team did with change tickets, only with a unit of measure so squishy that no audit would ever catch it. Story points are not a currency. They were never meant to be compared across teams or across quarters, and the instant they carry a reward, they stop describing size and start describing whatever the team needs them to describe. Ask what actually reached a customer The way out is not a cleverer version of velocity. It is to measure things that are expensive to fake because they touch reality. When Google's DevOps Research and Assessment program set out to define software delivery performance, it landed on metrics anchored to production, not to the estimate: change lead time, deployment frequency, and failed-deployment recovery time on the throughput side, plus change fail rate and deployment rework rate on the stability side (DORA). You cannot inflate deployment frequency by re-estimating a card. Either the change reached users or it did not. The other thing DORA's research keeps finding is that speed and stability are not a tradeoff. "DORA's research has repeatedly demonstrated that speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams," which means the teams shipping fastest are usually also the ones breaking things least. Velocity, by contrast, is silent on whether anything worked. A team can post a record sprint and ship a quarter's worth of rework, which is the opposite of fast; I have argued before that shipping the same feature twice is not shipping faster, and no story-point total will surface that. DORA's 2025 report adds a timely warning here: as teams lean harder on AI coding assistants, individual output rises while delivery instability rises with it (RedMonk on DORA 2025). More code produced is not more value delivered, and a velocity chart will happily celebrate the wrong one. Flow tells you more than output too. How long work actually sits before it is finished is a harder number to game than how many points got claimed, which is why the age of the oldest ticket on your board is often a more honest health signal than any velocity trend. What I would put on the dashboard instead The lesson from the change-ticket years was not "stop measuring." It was "stop rewarding the proxy." Once we grew wary of the closed-ticket count and started asking whether incidents went down and whether risky changes actually landed, the gaming lost its point, because there was nothing left to win by faking it. For a product team, that translates into three habits. Keep velocity where it belongs, inside the team, as a planning input for forecasting the next few months, and never let it appear on a leadership slide as a grade. Judge the sprint by what changed for a customer or a business outcome, not by how many points crossed the board. And watch the numbers that resist manipulation, the ones tied to production and to flow, because a metric only stays honest as long as no one has a reason to lie to it. Velocity going up feels like winning. Ask the harder question before you celebrate it: did anything actually reach a customer faster, or did the team just learn, as every rational team eventually does, to make the line climb?