Shipping more is not the same as creating more value.
Past a certain point, it can be the opposite—each additional feature adds a small amount of potential upside and a compounding amount of guaranteed cost, and most organizations never do the math to notice which side of that trade they are actually on.
What Actually Happens to the Features You Ship
Start with what happens to a feature after it ships. Pendo's 2019 Feature Adoption Report—based on aggregated usage data from 615 customer subscriptions active for at least a year—found that 80% of features in the average software product are rarely or never used. That is not a claim about any one bad product. It is a pattern across hundreds of real, shipped products with real usage data attached to them.
Exhibit 1
How often shipped features actually get used, on average
Aggregated usage data across 615 customer subscriptions active for at least a year.
Source: Pendo, "The 2019 Feature Adoption Report."
A feature nobody uses does not sit quietly. It keeps charging rent.
Every one of those unused features still had to be scoped, built, tested, documented, and shipped. And it doesn't stop there. Once it exists, it still has to be maintained—kept compatible with everything shipped after it, patched when it breaks, considered every time someone touches the surrounding code.
That rent has a name: technical debt. Sonar's research, based on analysis of over 200 real-world projects totaling roughly 11 million lines of code, puts the ongoing cost at around $306,000 per year for every million lines of code—compounding to roughly $1.5 million, or 27,500 developer hours, over five years. Deloitte's 2026 Global Technology Leadership Study puts the aggregate effect at the organizational level: technical debt now accounts for 21% to 40% of total IT spending. Put those two together and the picture is blunt—a meaningful share of what looks like "building the product" is actually the product's own accumulated weight, paying for decisions—including features—that were made and shipped but never earned their keep.
21–40%
of total IT spending now goes to servicing technical debt — much of it from features that were built but never earned their keep.
Source: Deloitte, 2026 Global Technology Leadership Study.
Exhibit 2
More features shipped
More surface area to maintain
Technical debt accumulates
Less capacity for new value
Slower overall value creation
Why an ever-longer feature list can leave less capacity for the work that actually moves the business.
Why This Trap Is Easy to Fall Into
None of this happens because teams are careless. It happens because the metrics most delivery organizations track make it invisible.
Velocity and story-point throughput measure how much a team shipped. They say nothing about whether any of it mattered. A team can hit every sprint target, ship consistently, and still be pouring capacity into work that adds cost without adding value—because the measurement stops at "delivered," and delivered is not the same question as "worth delivering."
This is the exact failure mode Marty Cagan draws a line around: feature teams are handed output targets—ship this, ship that—while empowered product teams are held to outcome targets, the actual business results those features are supposed to produce. John Cutler's term for the organization that optimizes for the first and never checks the second is the feature factory: consistently shipping, and consistently disconnected from whether any of it worked.
What to Optimize Instead
The fix is not "ship less" as a blanket policy—shipping less for its own sake is just as blind as shipping more for its own sake. The fix is asking a harder question before capacity is committed, not after: what does this feature need to do, for whom, to be worth the cost of building and carrying it indefinitely? That question has to be answered before the work starts, because Pendo's data suggests it is very often not being answered at all—four out of five shipped features, on average, never find out.
In practice, that means treating "what we build" with the same rigor delivery teams already apply to "how we build it." A feature that will sit at low usage isn't neutral—it's a liability with a delivery-capacity price tag attached, competing every year for the same maintenance budget as the 20% of the product that customers actually rely on.
The Real Measure
Output is easy to count and easy to celebrate: a burndown chart, a release note, a roadmap slide with more rows checked off than last quarter. Value is harder to see and slower to show up, which is exactly why it gets deprioritized in favor of the metric that's already on the dashboard.
But the two are not proxies for each other. An organization can be shipping more than it ever has and still be creating less value than it did a year ago—not because anyone stopped working hard, but because "more" and "worth it" were never the same question, and only one of them was being measured.
