In practice
An invoicing app adds tags. Then custom fields, then approval flows, then a report builder. Each came from a real request. A year later the first-time user can't find the Send button.
Feature creep isn't the same as scope creep. Scope creep is a project growing past what was agreed, with the deadline and cost left alone. Feature creep is a product collecting features over its life. Many sources use the two words interchangeably, and both come from small yeses nobody added up.
It is also different from the second-system effect, Fred Brooks's name for a team's second product ballooning with every idea held back from the first. Wikipedia calls the two closely related.
How to keep it in check
- Write one sentence on who the product is for and what it does for them.
- For each request, record the request in the customer's words, how many accounts, and the job they are trying to do.
- Name what's out of scope for each piece of work. A written no is harder to add back quietly.
- Make room by trade: a new feature in means a weak one reviewed for removal.
- Each quarter, look at usage and retire what few people touch, after warning them.
Common mistakes
- Building what the loudest user asked for instead of the problem they described.
- Saying yes because it is cheap to build. The cost of owning it is the bill that grows.
- Never removing anything, so the product only ever gets bigger.
Why it matters for product builders
Every feature has to be built, tested, documented, supported and explained. The cost lands after the yes, and it is hard to take a feature back once people use it.
Some drivers are common: pressure to reach new customers, no clear product direction, a decision-maker's request, or one loud user. Without a written reason for the product to exist, every request looks reasonable.
What counts as creep depends on the user. A feature one person calls bloat is another person's daily tool, so the test is who you are building for.
What changes in AI-first products
An agent can build the extra feature in an afternoon, which makes yes feel free. That is how a team becomes faster at building the wrong thing.
What an agent can't do is know the feature doesn't fit. If the reason the product exists and the things it won't do are written where the agent reads them, such as an out-of-scope list in the spec, the agent can stop at the line. A person still draws it.
See how Annsa does it: Direct your agents →