Waste 2: Extra Features
Building things nobody needs—the most expensive waste of all.
1The Overproduction Trap
In manufacturing, overproduction means making more than customers ordered. In software, it means building features nobody uses.
Studies consistently show that 60-80% of features are rarely or never used. Think about that. Most of what software teams build creates no value.
This is the most expensive waste because it has compound costs:
- Development cost: Time to build the feature
- Maintenance cost: Every feature adds complexity forever
- Opportunity cost: What else could you have built?
- User cost: More features mean harder products to use
A feature that's never used isn't free—it costs you every day in cognitive load, testing burden, documentation, and potential bugs.
The Carrying Cost
Every feature has a carrying cost. It needs testing. It might break. It complicates the codebase. It confuses users. Unused features are negative value—they cost more than nothing.
2Why Extra Features Get Built
Teams build unnecessary features for many reasons:
"While we're at it": Adding scope because it seems efficient to bundle. It's not—it delays the valuable work and adds waste.
Imagined requirements: Building for users you haven't talked to. Assumptions compound into waste.
Gold plating: Engineers adding technical sophistication that doesn't serve users. Abstractions nobody will reuse. Performance optimization for features nobody uses.
FOMO features: "Competitor X has this feature!" Maybe their users don't use it either.
Political features: Features built because someone important requested them, not because users need them.
Over-engineering: Building for scale you'll never reach. Designing for flexibility you'll never use. "But what if we need to support a million users?" You probably won't.
The opposite of extra features isn't feature-poverty. It's focus. Build exactly what's needed, nothing more, and build it well.
A team spent two months building CSV/Excel/PDF export for a reporting feature. Analytics showed 3 users ever used export. The feature remains in the codebase, adding test burden and maintenance cost forever.
A team needed to support one payment provider. They built exactly that—no abstraction for multiple providers. Later, when they actually needed a second provider, they refactored. Total cost was less than upfront abstraction would have been.
3Preventing Extra Features
Validate before building: Talk to users. Run experiments. Use prototypes. The cheapest feature is the one you don't build.
YAGNI (You Ain't Gonna Need It): Don't build for imaginary future requirements. Build what you need now. Refactor later if requirements change—and often they don't.
Minimum Viable Everything: What's the smallest thing that would test this hypothesis? Build that. Learn. Iterate.
Data-driven deprecation: Measure feature usage. Kill features that aren't used. The courage to remove is as important as the discipline to not add.
Say no more than yes: The default for new features should be "no." Features need to justify themselves. Saying no to a good idea is often right because you should be working on a great idea instead.
Feature budgets: For every new feature, remove an old one. This forces prioritization and prevents bloat.
The best teams aren't proud of what they built—they're proud of what they chose not to build.
Every feature you don't build is infinite savings: no development, no testing, no maintenance, no documentation, no bugs, no confusion—forever.
- 60-80% of software features are rarely or never used
- Extra features have compound costs that never stop
- Build for validated needs, not imagined requirements
- YAGNI: Don't build for future needs that may never come
- The best teams are proud of what they didn't build
- •Bundling extra scope because you're 'already in the code'
- •Building abstractions before you have multiple use cases
- •Assuming users want features because competitors have them
- •Over-engineering for scale you'll never reach