Measuring Product Team Velocity Is A Waste of Time
We’re rushing to the finish line without asking why or how it’ll improve product value or team health.
For years I was focused on how product teams increase velocity.
I was wrong.
Unlike the “Move Fast and Break Things” mantra of the early internet boom, velocity seemed to be the more mature way to measure team success. Speed is pointless if you’re not heading towards a goal and breaking things seemed infantile. In contrast, velocity as a measure made sense to me.
Velocity Is Better Than Speed But It’s Flawed
Velocity is speed plus vector: how fast something gets somewhere. In the context of product teams, velocity could be defined as the time it takes to get from idea to delivery.
If you’re looking to shift your team from being busy to focused work, the velocity vs. speed comparison is a great place to start. My 4-yr old is always busy. Running around like an overly caffeinated hummingbird, but he rarely gets anywhere. He’s all speed and no velocity.
Speed and velocity are only a small part of the picture.
I didn’t see the whole picture when I started looking into team performance. Assuming velocity was better than speed, my work looked at how teams could increase their velocity towards the outcomes they selected. Could increased decision speed and accuracy improve velocity? Would higher levels of trust make teams work faster towards their goals? Does aligning incentives influence velocity? Will increasingly more mature practices change the velocity of a team?
The simple answer to all these questions is yes. You can certainly increase the velocity of a team by improving decision-making, expanding trust, aligning incentives, and maturing team practices. But to what end?
Shipping More Doesn’t Increase Team or Product Health
The question that kept popping into my head was “so what?” Even if a product team increased velocity, how would that make the team happier or deliver more value to the customer or user? What if increased velocity increased near-term delivery output but had negative 2nd and 3rd order consequences?
Velocity does have value, but it comes at a high cost. As an amateur cyclist, this should've been obvious to me. In a race, speed towards your goal is critical. But pacing yourself is even more important. When you increase velocity you must be willing to pay the price. The lactate burning in your legs as you go faster reminds you that for every action, there’s an equal and often painful reaction. Going into the red is difficult to bounce back from.
Burning out a team for the sake of achieving more doesn’t make sense.
Measuring velocity is a trap. It encourages teams to measure the outputs of their work. The number of lines coded, or the number of items knocked off a burndown chart is meaningless. Held up against the experience of the customer, it becomes really difficult to justify why doing more matters.
Flipping The Switch
Shifting the mindset from increased delivery to meaningful customer value is a necessary step to avoiding team burnout. While increasing velocity is generally well-intentioned it’s unsustainable and problematic. Metrics need to be outcome-based, not output-based.
The switch to more meaningful calibration requires two steps: agreeing to measure the right thing and then doing the right thing.
Measuring the right thing means flipping from arbitrary or vanity metrics to customer value metrics like the number of sales leads from existing customers (directly infers satisfaction) or the number of positive reviews. My personal view is to avoid scores like NPS. Scores like this are not accurate predictors of future success. They are rearview mirrors.
I’m not advocating ignoring trailing indicators. Just don’t measure your team’s performance with metrics they can’t control or don’t relate to their work. Rather look forward and ask, “what would a healthy customer be doing with this product to solve their problems and what could we use to measure that outcome?”
Choosing the Right Measures Avoids Friction and Burnout
How you choose to measure the team’s work has consequences on how they behave. Metrics are incentives. If you measure the levels of activity, then you’re incentivizing activity. Measure quality, then that’s what the team focuses on. In this way, our measures contribute to burnout.
Velocity-related metrics will encourage cutting corners or skipping important steps. Agreeing to metrics that focus on quality outcomes is healthier both in the near-term and long-term. How you agree to work has a downstream effect on the product creation process.
Knowing why you’re selecting a metric makes it motivating for the team. “When we see ABC metric change, we have evidence we’re solving for a real customer problem.” Think like a scientist. Connect work to the evidence that drives healthy outcomes. Keep asking, “so what?’
Inquiry-based roadmaps can also help identify the right metrics. Rather than base metrics on what you see in the rearview mirror, base your roadmap on questions that once answered, will pull you forward.
Why Do This?
Doing the right thing is harder but possible. Ask your team if they are willing to publically put their names on the work that’s about to be shipped. If a dev or designer says no, then they have reservations about the quality or integrity of the work. Team health has never been more important. Respect for a healthy outcome signals respect for the team.
Agreement on multi-dimensional metrics can be harder, but it’s worth it. It increases the level of trust within the team and across the broader organization. Trust naturally improves a team’s ability to make better decisions. More accurate decisions result in less rework and lower anxiety. Less stress means less friction. Everyone is happier. The team, the customer, and the business.
