All users bear the marginal cost of added features

What it is

Feature creep is the process of adding capabilities that each appear reasonable but collectively keep increasing options, terms, states, paths, and maintenance relationships. A new feature's benefit may concentrate in a few tasks or users, while its marginal cost is borne by everyone: harder scanning, more choices, broader help and testing, and greater chance of conflict with existing rules. A feature does not exist in a product for free.

Why it happens

Each added capability typically brings an entry, name, state, error handling, permission, feedback, documentation, compatibility, and combinations with existing functions. Even a hidden entry may surface through search, menus, or error state; teams must maintain its interactions too. Complexity is not merely additive but grows through combinations and exceptions. Over time, people find it harder to form an overall model, and edge capability may obscure core value.

Studying it

Create a benefit–cost account for a candidate feature: target population, task frequency, problem addressed, alternatives, added entries and states, disruption to existing flows, and support and maintenance load. Use prototypes and task data to see whether it improves its target task while non-target users' search, misactivation, or understanding worsens. After release, track adoption, retention, error, support, and effect on primary-path metrics.

Where it stops holding

Simplicity does not mean rejecting necessary capability. Features essential for accessibility, compliance, safety, or business value to a smaller group cannot be removed merely because fewer people use them. Conversely, a user request does not automatically require an independent toggle; the same root problem may be better addressed through an improved existing flow, default, rule, or integration. The issue is net value, not feature count itself.

Applying it

• Require every addition to state problem, target population, frequency, alternatives, and whole-product cost—not only the voice of demand.
• Prefer integrating into existing concepts and flows rather than creating parallel entries, terms, or states for similar capability; if integration fails, consider declining or delaying it.
• Review low-adoption, high-complexity, and duplicate capability regularly; merge, retire, or restructure it, treating cleanup as continuing product work.

Related

• Same group: B2.15.2 Simplicity is not deleting functions but clarifying structure · B2.15.3 Feature tradeoffs need explicit criteria rather than a vote
• Nearby: B2.08.3 Visibility directly conflicts with simplicity and requires frequency-based tradeoffs · B2.13 Progressive disclosure
• Search terms: feature creep · complexity cost · feature prioritization