Feature creep is a product acquiring features faster than it acquires clarity about what it is for.
Nobody decides to do it. Every individual addition is defensible, usually with a real customer behind it, and the damage is only visible in aggregate. That is what makes it a structural problem rather than a discipline problem, and it is also why a page about willpower is useless here.
What is feature creep?
The accumulation of capability past the point where it makes the product better to use.
The important half of that sentence is the second half. Adding a feature is not creep. Adding a feature that makes every other feature slightly harder to find is.
A product has a fixed budget of attention from the person opening it, and each addition spends some of it, whether or not anybody uses the new thing.
The cost is paid in places that do not look like features. A longer settings page. Another decision at onboarding. One more thing to describe on a pricing page.
A support answer that starts with it depends on whether you have turned on. None of those appear in the ticket that added the feature and all of them are permanent.
The demo board shows the same idea in use, open with no account.
How is that different from scope creep?
Scope creep happens inside one piece of work. Feature creep happens across a product's life.
Scope creep is a project growing while it is being built, and it has a clean edge, which is that the project eventually ships and the growth stops. You can see it happening and you can point at it in a standup.
Feature creep has no edge. It is made of decisions that were each correct on the day, spread over years, made by people who mostly no longer work on the thing.
Nobody is present for the moment it happens, because there is no moment. That is why almost every honest account of it is written in the past tense.
The two are also fixed differently. Scope creep is fixed by saying not in this one. Feature creep is only fixed by removal, and removal is the thing organisations find hardest, because every feature has at least one person who will write in.
Does a feedback board cause feature creep?
Yes, if you build the top of the list every time, and it is dishonest to sell you one without saying so.
A feedback board is a machine for producing requests, and requests are additive by construction. A request to take something away is a rare shape, and the reason is structural rather than cultural.
People ask for what is missing, because absence is what you notice. Nobody notices the features they never open, so nothing generates the request to remove them.
So a board sorted by votes is a queue of additions with a number of people behind each one, and if the process is take the top item and build it, then the process is an engine for exactly this.
The board did not cause the bad decision. It made the bad decision feel like a mandate, which is worse, because a mandate does not get argued with.
The way out is not to ignore the board. It is to stop treating rank as an instruction. A request with forty voters tells you that forty people hit something.
It does not tell you that building it is the best available use of the next three weeks, and no vote count can tell you that, because the number was never a measurement of demand in the first place.
What does a board actually give you against it?
Three things, and the third is the one that matters.
Duplicates collapse into one row. Six people describing the same difficulty in six different vocabularies read as six requests in an inbox and as one request on a board. That changes what you are looking at, because a long list of near identical items is the single best fuel for building six overlapping features instead of one good one.
Size becomes visible. A request with three voters and a request with forty stop looking identical, which is the fundamental thing an inbox cannot do. Most creep is built for the three, because the three wrote in most recently.
A refusal has somewhere to live. This is the real one. On a board with a declined column, saying no is a published act with a reason attached rather than a message that disappears into one person's inbox. That matters because the same request arrives again in four months, from somebody else, and without a record you argue it from scratch and lose, having forgotten the reason you were right the first time. The six refusals are written out in full, because the sentence being hard to write is most of why it does not get written.
How do you know it has already happened?
Four signals, and none of them is a feature count.
Your own onboarding is the first. If explaining the product to a new customer requires naming a thing they will not need for six months, that thing is in the way of the thing they came for.
The settings page is the second, and it is the least deniable. Every switch on it is a decision you could not make on the customer's behalf, and a page of them is a page of decisions you postponed by handing them over.
The third is the shape of your support volume. When the common questions stop being how to do a thing and start being why the product behaves differently for one person, the answer is usually that some combination of options is now producing a product nobody designed.
The fourth is when a request arrives for something you already built, and the person asking has used your product for a year. That is the product telling you the feature is unfindable rather than a failure of their attention, which is functionally the same as not having it and costs more.
What does this look like on our own board?
Our own public board has nine visibility switches on it.
Votes, views, comments and progress can each be shown or hidden. Voting, commenting and suggesting can each be allowed or refused. Archived and declined items can each be shown or hidden. Nine, on one page, and every one of them exists because somebody wanted it a particular way.
We are not going to pretend that is a design triumph. It is a small monument to exactly what this page is about, and the honest defence is only that the defaults are chosen so that most people never open the panel.
That is the defence every product with a long settings page makes, which is worth knowing when you read it somewhere else.
What we would say for the board itself is narrower. It shows you the size of a request before you build it, it collapses the duplicates that make one problem look like six, and it gives a refusal a public place to sit.
The roadmap and the declined column are the same page, at nine dollars a month, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.
