A usable function nobody needs has no value
Aliases: useless features · feature bloat · zero value
What it is
Polish an unneeded feature as much as you like and the output is still zero: usability is a multiplier, not an addend—it amplifies a function's value but cannot create value from nothing. A failed usability test can be fixed; a nonexistent need cannot. The design and engineering spent on no-need features is waste hidden by the multiplier.
Why it happens
Feature value ≈ need strength × function quality × usability. When need strength is zero the whole product is zero, however large the other two terms. This explains two common wastes: features copied for competitor parity that users route around, and features the team believed "should be useful" while market data keeps falsifying it. Usability's measurement sensitivity even worsens the misjudgment—a fluid demo makes a valueless feature look successful in review.
Studying it
Identify valueless functions with an evidence chain: need evidence (who asked at kickoff, for which scenario) → usage evidence (arrival rate, frequency, retention contribution) → removal experiments (do core metrics move when it goes offline). When all three point to "no need," the feature enters retirement. Guard against misreading silent usage: low frequency is not no value—separate low-frequency-high-value (annual tax filing) from low-frequency-zero-value (parity filler).
Where it stops holding
"Useless" is only as good as the need measurement: emerging needs cannot be proven by data before usage exists, and platform functions may hold ecosystem-level rather than direct-use value. Some functions buy trust and completeness (full export formats) that usage rates alone would wrongly kill. And "no value" does not automatically mean "delete now"—retirement has its own costs and risks; sometimes the right answer after review is keep-but-freeze.
Applying it
- Require need evidence and success metrics at feature kickoff; "the competitor has it" and "it's technically feasible" are not approvals.
- Run a feature census each release: functions with sustained zero use and no retention contribution go on the retirement list, not the polish list.
- Classify before judging low-frequency features: critical-infrequent (must stay usable and memorable) versus peripheral-infrequent (removable) are different problems.