Feature bloat is not a product problem. It is a decision-making problem. Every company that has shipped a great simple product has also shipped a bloated one five years later, because adding is visible and subtracting is invisible.

This site is about noticing the difference and acting on it.

01. What feature bloat is

Feature bloat is what happens when “more” becomes the strategy

Feature bloat is the state a product reaches when it has accumulated so many features that the complexity imposes costs on users and the business that outweigh the value of those features. It is a destination, not a process. The process is feature creep: the gradual, individually defensible addition of things that felt important at the time.

Three terms are often confused. Feature creep is the verb. Feature bloat is the noun. Scope creep is the project-management cousin: the tendency for project requirements to expand beyond their original definition, usually without corresponding increases in resource, time, or value. They share a cause but operate at different levels. Scope creep happens during a project. Feature creep happens during a product life cycle. Feature bloat is what you are left with when neither is managed.

02. Why it happens

Humans default to adding. The research is unambiguous.

Leidy Klotz is a professor of engineering and architecture at the University of Virginia. His research, detailed in Subtract: The Untapped Science of Less (Flatiron Books, 2021), runs a series of elegant experiments that show the same result: when people are asked to improve a system, whether a LEGO structure, a golf course, or a university curriculum, they almost always add something. Removing is the less-travelled path. Klotz argues this is not laziness or incompetence; it is a cognitive default baked in by evolution and reinforced by most institutional reward structures.

In product organisations, the cognitive default toward adding is amplified by structural incentives. Engineers get promoted for shipping, not for deleting. Product managers who champion a feature have a story to tell; product managers who kill a feature are firefighters, not heroes. Roadmaps have a “to build” column and no “to sunset” column. Every organisational signal points toward accumulation.

The result is what Marty Cagan calls the “feature factory”: an organisation that measures itself by the number of features shipped rather than the outcomes those features produce. See the ten anti-patterns for the full taxonomy, and Klotz's book for the research.

03. The data

Most features go unused. Three figures that should end arguments.

The Standish Group figure is from 2002 and is still routinely cited because no subsequent study has contradicted it. Pendo's 2019 Feature Adoption Report surveyed 180 million users across 35,000 applications; the finding that only 12% of features are used “often” was consistent across enterprise and SMB segments. These numbers are not anomalies. They are the baseline state of most software products.

The implication is that the average product team is spending roughly 80% of its maintenance budget servicing features that serve a minority of its users. That is not a prioritisation problem. It is a structural one. See how to measure it in your own product.

04. Case studies

Six products that drowned in their own features

You can read fifteen definitions of feature bloat and still not recognise it in your own product. Reading what happened to Evernote and Microsoft Word is diagnostic.

Read all six case studies in depth →

05. What to do about it

Three entry points into the playbook

06. Who this site is for

Each role faces feature bloat differently

07. The honest counterpoint

We are not anti-feature. We are anti-unexamined-feature.

Platforms need completeness. Enterprise contracts have legitimate requirements. Network-effect products are judged differently. A site that only says “features bad” is a slogan, not a position. We have written the counterpoint with the same seriousness as the argument.

Related in this portfolio