There’s a kind of product team that looks healthy from every angle except the one that matters.
The sprints are full. Velocity is stable. Something ships every week. The roadmap is long and everyone works hard. Then someone looks at the numbers the business runs on, like conversion, retention, revenue per customer, cost to serve, and they’ve been flat for two quarters.
Nobody is slacking. The team has simply become very good at producing output, and nobody is checking whether that output changes anything for the business.
How teams end up here
Output is easy to measure. Tickets closed, story points, features shipped. These numbers update every day and go up when people work hard. Business outcomes move slowly and depend on many things, so they’re harder to attribute to any one piece of work.
Requests arrive as solutions. Stakeholders ask for features and rarely say what outcome they want. “Add a progress bar to the onboarding screen” gets built without anyone asking what problem it solves or how we’d know if it worked.
Shipping feels like success. A release is a visible moment. The quiet review four weeks later, where you’d find out nothing changed, rarely happens.
And being busy is safe. A team working flat out is hard to criticise. A team that stops to ask whether the work matters can look slow.
Signs it’s happening in your organisation
Ask the product lead which one or two business metrics the current roadmap is meant to move. If the answer takes a while, or lists eight metrics, that’s the first sign.
Others: features count as done once they’re deployed, and nobody measures the effect. Most of the roadmap came from internal requests rather than data or customer evidence. Post-launch reviews either don’t happen or are mostly about bugs. The team’s main success measures are velocity and delivery dates.
Pointing the work back at the business
Team metrics are useful for the team. They’re not what leadership should manage by. What matters is the effect on the business, and the process should make that effect visible.
Start every significant piece of work with a one-line hypothesis: we believe this change will move this metric for these customers, because of this evidence. Say a company believes that showing delivery tracking in its app will cut “where is my order” support contacts by a fifth, because those contacts are the single biggest category. Now there’s a number to check, and a reason that can be challenged before any work starts.
If nobody can write that line, the work probably isn’t ready.
Give every meaningful release a review date, set before launch. At the review there are three possible answers. It worked, so do more of it. It didn’t, so find out why. Or you can’t tell, which means the measurement or the design of the change wasn’t good enough, and that needs fixing before the next one.
Pick fewer metrics. A dashboard with forty indicators doesn’t help anyone decide what to do this week. One primary metric for the quarter and two or three supporting ones is enough, and everything on the roadmap should connect to at least one of them.
Celebrate results rather than releases. Share the reviews where something worked, and give the same airtime to the ones that didn’t, along with what was learned.
Make it normal to stop. Some work should be abandoned halfway because early data shows it won’t deliver. That only happens if stopping is treated as a good decision.
What leadership should ask for
Instead of asking what shipped this month, ask what changed for the business because of what shipped. Instead of velocity charts, ask for a short list of bets, the metric each one targets, and the result so far.
The team can keep its internal measures. Leadership’s job is to make sure the effort is aimed at the right target, and to check regularly whether it’s hitting it.
