Software Growth

Feature creep / Scope Creep

Feature creep is the slow growth of a product's scope as extra features pile up, until it is complicated, late and harder to sell.

Feature creep happens when a product keeps expanding past its original purpose, one reasonable request at a time. No single feature looks like a mistake. The damage shows up in aggregate: a confusing interface, a slower roadmap, a bigger codebase to maintain, and a harder story to tell. For a small team it is dangerous because you cannot afford to build, support and document everything.

Why it happens

Wikipedia’s overview lists three common causes: wanting to make the product more appealing to increase sales, design by committee, and the pressure to add features without removing old ones. In a SaaS the typical triggers are:

  • A prospect says “I would buy if you had X,” and you build it for one deal.
  • A loud customer asks for a niche option and it ships to everyone.
  • You copy a competitor’s feature list to fill a comparison table.
  • The team prefers building to the harder work of marketing and selling.

What it costs

  • Complexity for users. More menus and settings make onboarding longer and the first minutes harder.
  • Delay. Wikipedia gives Windows Vista and Netscape 6 as famous examples of products delayed by sprawling scope.
  • Maintenance. Each feature needs tests, support, docs and future migration, which is a form of technical debt.
  • Muddy positioning. A product that does ten things is harder to position than one that does one thing very well.

A fair counterpoint

Unfortunately, it’s never the same 20%. Everybody uses a different set of features.

Joel Spolsky / Strategy Letter IV: Bloatware and the 80/20 Myth (March 23, 2001)

Joel Spolsky argued in “Bloatware and the 80/20 Myth” that people complaining about bloat often miss that everyone uses a different 20% of the features. A stripped-down “lite” version tends to omit the one feature somebody needs. So the answer is not “fewer features” in the abstract. It is to add features deliberately, for a defined customer, with evidence.

How to avoid it

  1. Write down who the product is for and what it does. Test every request against that sentence.
  2. Count requests, not volume. One feature requested by five paying customers with the same problem beats twenty from free users.
  3. Ask for the problem, not the solution. “I need X” often hides a simpler need you can solve another way.
  4. Measure after launch. Check feature adoption. If nobody uses it after 90 days, remove it.
  5. Prune on purpose. Deprecating unused features is as valuable as shipping new ones.

Example: your invoicing tool gets a request for multi-currency. Three of 200 customers asked. Adoption of your last two similar features was under 5%. You answer “not now” and check again next quarter, keeping roughly two engineering weeks for onboarding fixes that affect every new signup.

Jason Cohen’s SLC idea (simple, lovable, complete) in “Your Customers Hate MVPs. Make a SLC Instead” is a useful guard: keep the scope small, but make what remains work completely.

For bootstrapped teams

Your constraint is a strength. A narrow product for a defined buyer is easier to market and to support, and each feature you decline leaves time for the work that grows revenue.

Sources

Back to the SaaS glossary