Pendo’s analysis of usage data across 615 software products found that 80% of features are rarely or never used after launch. The company estimated that public cloud software companies collectively spent $29.5 billion in R&D on features customers ignored.
That number sounds like a discovery problem: teams building the wrong things. Some of it is. But a meaningful share of that waste comes from a different place entirely. It comes from teams that realized mid-build that a feature was wrong and shipped it anyway.
The Three Sprints Problem
Product managers hear a version of this argument constantly: “We’ve already spent three sprints on this. We can’t just throw that away.”
The logic feels airtight. Engineering invested weeks. Designers created mocks. QA wrote test cases. Stakeholders were briefed. Stopping now means all of that work produces nothing.
Except it already produced nothing of lasting value. The work generated learning, not outcomes. And the cost of shipping something that doesn’t solve a real problem is almost always higher than the cost of stopping. You pay for support tickets from confused users. You pay for onboarding complexity. You pay for the maintenance burden that sits on every future sprint. You pay for the opportunity cost of what that team could have built instead.
Barry Boehm’s research on software rework shows that 30 to 50% of development effort goes to avoidable rework, much of it caused by requirements that were misunderstood from the start. The sunk cost fallacy ensures that even when teams discover the misunderstanding early, they press forward.
What This Looks Like in Practice
In IT operations, this pattern repeats at every scale. A project starts with strong conviction. Three months in, the team lead quietly admits the requirements don’t match reality. Six months in, the whole team knows. Nine months in, the feature ships to an indifferent user base. Twelve months in, someone files the ticket to deprecate it.
The people building these features are smart and experienced. They have the data. What they lack is organizational permission to stop.
In a fractional COO engagement through Ops Harmony, I worked with a product team that had spent four months building an internal reporting dashboard nobody had asked for. The original sponsor had left the company. The new VP didn’t need the tool. But the project had momentum: a Jira epic with 47 subtasks and no one willing to be the person who killed it. They shipped it. Eleven active users in month one, four in month two, zero within a quarter.
The total cost wasn’t the four months of engineering time. It was four months of build, three months of maintenance, the migration work when they eventually shut it down, and the lost credibility with an engineering team that had known for weeks it was pointless.
One Question That Changes the Conversation
The clearest framework for this problem is the simplest. Ask: “If we hadn’t already started this, would we choose to start it today with everything we now know?”
If the answer is no, that tells you something important. It doesn’t automatically mean you should stop. There are legitimate cases where switching costs are high or where the feature unlocks future work that has real value. But if the answer is no and the only argument for continuing is “we’ve already invested too much to stop,” you’re watching the sunk cost fallacy play out in real time.
This connects to a broader truth about why product decisions have a shelf life. The assumptions that justified a feature in planning may no longer hold by the time the team is three sprints deep. Markets shift. Competitors launch. Customer feedback contradicts early hypotheses. A decision that was right in January can be wrong by April, and the best response is to treat that as new information rather than an inconvenience.
The Standish Group’s research found that 64% of features in enterprise applications are rarely or never used. Jim Johnson, the Group’s chairman, presented that finding at the XP 2002 conference, and the numbers have gotten worse since. The question isn’t why so many features fail. The question is how many of those features showed clear signs of failure during development and shipped anyway because nobody was willing to pull the plug.
What Pulling the Plug Actually Requires
Killing a feature mid-build is a political act. It requires a product manager to do several uncomfortable things at once: admit that the original decision was wrong (or that circumstances changed), absorb the frustration of a team that invested real effort, and present the cancellation to stakeholders who approved the original scope.
Three practices make it possible.
Pre-committed exit criteria. Before development starts, define what would make you stop. “If beta testers can’t complete the core workflow in under three minutes, we shelve this.” “If the API integration takes more than one sprint, we reassess scope.” Writing these down before there’s emotional investment makes them easier to enforce when the data arrives.
Small batches with explicit checkpoints. Instead of committing to a full feature upfront, build in review gates at natural breakpoints. A spike, then a checkpoint. A working prototype, then a checkpoint. Each checkpoint is a legitimate moment to ask whether the feature still deserves the next increment of investment. This is the same principle behind avoiding the 90% done trap, applied earlier in the lifecycle.
Reframing cancellation as a decision, not a failure. The team that stops building the wrong thing freed up capacity for the right thing. That’s a better outcome than shipping something that creates ongoing maintenance cost and user confusion. Document what changed, what the team discovered, and what the organization should do differently when a similar idea surfaces later.
The Real Execution Discipline
Product management writing tends to focus on what to build and how to ship it. Less attention goes to the discipline of stopping. But knowing when to stop is an execution skill. It happens in the middle of sprints, in standup meetings, in the moments when a product manager notices the energy draining from a feature and decides whether to push through or pull back.
The best product managers treat every in-progress feature as a hypothesis that could be disproven by new information. They don’t treat a Jira epic as a commitment. They treat it as a plan, and plans change when reality does.
Shipping something the team knows won’t work isn’t perseverance. It’s the most expensive kind of waste in product development.