Ship Faster Is the Wrong Question

Someone in the room said it again.

We were halfway through a monthly initiative review. The Productboard roadmap was tidy. Every initiative was mapped on the timeline, each one pinned to its strategic goal. Velocity was up. Bugs were down. Then a senior leader leaned forward and said, calmly, almost as a courtesy: "We need to move faster."

Everyone nodded. I nodded. Then I caught myself and didn't quite know why I was nodding.

Faster at what.

The features on the roadmap had shipped on time. Some of them had hit their target adoption numbers. Some had not. We did not look at that part too closely, because the meeting was about whether the initiatives were tracking, not about whether we had picked the right ones.

Speed Has a Dashboard

If you ask a senior product team how fast they ship, they can answer within minutes. Cycle time, deployment frequency, story points per sprint, lead time from commit to production. The numbers are polished, the dashboards are linked, and whichever PM tool the team is using has a delivery view that loads in under a second.

Now ask the same team which of their last five major features mattered to the customer.

Wait through the silence. Then watch the answers come in: a half-confident reference to NPS, a story about one specific account, an admission that the data lives in three different places and nobody has tied it together.

The data on this is uncomfortable. Pendo's analysis of 615 SaaS products found that 80% of features are rarely or never used. The median feature adoption rate is 6.4%. Even in a serious team, on a serious product, the bets that paid off are sitting in a small minority of what was shipped.

This is not a failure of seriousness. The team is serious. The structural problem is that delivery is a thing your tools can show you, and product discovery is a thing you have to assemble by hand. Putting effort into what is visible is what every system, human and otherwise, does by default. So we push on speed, because speed is the part the dashboard is willing to talk about.

Beneath the Velocity Chart

Underneath the velocity chart, the work looks different.

A small group of people is making bets every month. They are deciding which initiative the team will spend the next four to six weeks on. They are choosing one feature over four others. They are quietly killing things, sometimes too late.

Those bets are not made the same way the team writes its tickets. Tickets do not have a field called "I think this will matter and here is why." The bet lives in a strategy memo, a Productboard insight cluster, a conversation with sales, a half-remembered customer call. By the time it reaches the product backlog, it has been compressed into a feature description with acceptance criteria, and the original bet, the actual reason this feature exists, has been left behind.

So the team ships the feature. They ship it on time. They ship it to spec. The dashboard lights up green. And nobody goes back to ask whether the bet was right, because nobody can find the bet anymore.

Yes, This Is the PM's Job

I can hear the obvious objection. Connecting bets to outcomes is the PM's job. Track customer signal, name the trade-off, kill what isn't working. A senior PM who can't do that hasn't earned senior. I agree.

But the job description and the working conditions do not match. A PM can want to track every bet and still not have a place to write the bet down that survives the next reorg. They can want to kill features and still sit in an org where killing one requires four conversations and a deck. They can know the right answer and ship the wrong one because the next sprint planning is on Monday.

This is not absolution. PMs who do this well exist. They are the ones whose teams can answer the question this Friday. The point is that the gap between "this is the PM's job" and "the PM can actually do this job in current conditions" is wider than most senior practitioners admit. Closing it is the work.

The Question Nobody Asks Out Loud

Which of your last five features actually mattered?

I keep coming back to this question because it is the one that quietly does not get asked.

When a team cannot answer it, two things happen. The first is that the product backlog grows in a way that nobody can defend. Features stay because removing them would mean admitting the bet was wrong, and by the time anyone gets around to that admission, the person who made the bet has moved on or the org chart has been redrawn.

The cost is not just clutter. Pendo's number for a SaaS company with $50M in revenue is roughly $8.4M a year spent on features customers rarely or never touch. Some fraction of that is unavoidable. The fraction that comes from teams who never asked which features mattered is the part this post is about. The deeper cost is that the team gradually loses the muscle for asking the question at all.

The second thing is more subtle. Initiative reviews drift toward whatever is easy to claim. Throughput becomes the proxy for progress, because throughput is the only number everyone in the room agrees on. The conversation about whether the right things are getting built quietly disappears, replaced by a conversation about whether they are getting built efficiently. Those are not the same conversation. Under monthly pressure, the easier one is the one that runs.

Bet Quality Over Cycle Time

The reframe is not "ship slower." It is "measure the right thing."

McKinsey's research on what they call the product operating model found that organizations with mature outcome-tracking show 38% higher customer engagement and 37% higher brand awareness than their peers. The strongest correlation was not with their tooling. It was with their ways of working, specifically whether they measured customer outcomes rather than feature output. That matches what most senior PMs already suspect.

I have spent the last few months at Outcomet shipping at the highest pace of my career. A hundred stories and a thousand commits in under twenty days. None of that is in tension with what I am arguing. Speed is fine. Speed without learning is the problem.

The metric that matters is bet quality. How many of the things you shipped last month changed something a customer actually cared about. Not "would say in a survey," not "clicked once." Changed. As in, you can name what they did differently.

A team that takes bet quality seriously starts doing three things that look strange from the outside.

• They name the bet before they ship, in a place that does not get rewritten.
• They go back and check, on a cadence, whether each bet paid off.
• They kill features when the bet is wrong, and they say so out loud.

The third one is the hardest. "We killed three features this month because the data said we were wrong" is something most heads of product still cannot say in a board meeting without flinching. Until that sentence is normal, the speed reflex stays in place, because admitting bet failure is harder than admitting velocity drop.

A Kinder Kind of Speed

I think the next interesting thing happening in product work is not faster delivery. It is the slow rebuild of the muscle to ask the cheap question.

Which of your last five features actually mattered.

The question is free. It takes thirty seconds to ask. The reason teams do not ask it is not that the question is hard. It is that the answer is uncomfortable, the product feedback data is scattered, and the next sprint planning is on Monday.

Most product teams do not have a speed problem. They have a wrong-bets problem dressed up as a speed problem. And the difference matters, because shipping faster does not fix the wrong feature. It just turns it into faster waste.

The teams that figure this out are not going to look like the high-velocity teams of 2018. They are going to be the ones who can tell you, this Friday, what they got right last month and what they got wrong. With receipts.

That is a kinder kind of speed.