The 10 anti-patterns that create feature bloat
Anti-patterns are named not to be dismissive but to be useful. A pattern is a recurring structure. An anti-pattern is a recurring structure that produces a predictable bad outcome. The ten structures below recur in almost every product organisation. They are not mistakes made by bad teams; they are traps that well-meaning, intelligent teams fall into because the incentives and the information available at decision time make the wrong choice look like the right one.
The value of naming them is that once you can see the pattern, you can intervene before the outcome is inevitable. Most of these anti-patterns have a structural fix: a process change, a framework change, or a conversation that interrupts the pattern before it compounds. The fixes are noted in each section and developed in depth on the linked pages.
None of these is a gotcha. The organisations that fell into the Evernote pattern, the Zoom pattern, the Notion pattern were not careless. They were making locally rational decisions in an environment that rewarded adding and punished removing. That environment is what we are diagnosing here.
01. Scope creep
Scope creep
The pattern
A project starts with a clear, bounded definition. Then a stakeholder asks for one more thing. Then another. By the time you ship, you have built three projects packaged as one, none of them done properly. PMI research from 2025 found that 52% of projects fail to meet their objectives, with scope creep as a leading contributing factor, and 62% of organisations experience budget overruns.
Where it shows up
It shows up in the kickoff meeting when someone says "while we're at it." It shows up in the sprint review when the acceptance criteria have expanded since the ticket was written. It shows up in the retrospective when everyone agrees the scope was unclear.
Why it survives
It survives because no one wants to be the person who says no. Scope expansion feels like being helpful. The project manager who refuses a request from a senior stakeholder feels obstructive. The PM who accepts it feels collaborative. The organisation's reward structure punishes the naysayer and rewards the yes-person, and the scope expands.
The fix
Fixed-time variable-scope is the structural fix. You commit to a deadline and let the scope be what can be done in that time. Ryan Singer's Shape Up methodology at Basecamp is the most developed version of this approach. See the decision framework for how to implement it.
02. The feature factory
The feature factory
The pattern
The feature factory is Marty Cagan's term for organisations that measure themselves by how many features they ship rather than by the outcomes those features produce. In a feature factory, the roadmap is a backlog of requests. Product managers are order-takers, not problem-solvers. The quarterly review asks "how many things did we ship?" not "what changed for customers?"
Where it shows up
You are in a feature factory if your OKRs include "ship X features this quarter." If your product manager's job is described as "working with engineering to build what sales and marketing request." If there is no budget for user research. If the team cannot articulate what user problem the last three features solved.
Why it survives
It survives because it looks like productivity. Features shipped is a visible metric. Customer outcomes are measured later, attributed ambiguously. A feature-factory team can look very busy and very productive for years before the bill arrives in the form of a bloated product nobody wants to use.
The fix
Outcome-based OKRs replace output-based ones. Instead of "ship the bulk export feature," the OKR is "reduce customer support tickets about data portability by 40%." The feature may or may not be the answer. Cagan's book Inspired (SVPG, 2017) is the canonical resource.
03. Kitchen sink UX
Kitchen sink UX
The pattern
Every possible control is visible on every screen at all times. The toolbar has 40 icons. The sidebar has 12 sections. The modal has 6 tabs. The settings page has 80 options, ungrouped. The user opens the app and sees everything the product can do, simultaneously, without having asked for any of it.
Where it shows up
It shows up in the "power user" framing. "Our advanced users need access to everything." It shows up when every team has added its own controls and no one has audited the total. It shows up when the UX designer asks to simplify and is overruled by the product manager who needs to show stakeholders that the feature is visible.
Why it survives
It survives because progressive simplicity is harder to design than progressive disclosure, and progressive disclosure is harder to design than just putting everything on the screen. It also survives because each individual control has a champion: someone who wanted it, someone who built it, someone who uses it. Simplifying the screen means removing someone's work.
The fix
Progressive disclosure: show the minimum controls needed to start, reveal advanced options when the user has demonstrated the need. Apple's Shortcuts app and Notion's slash-command interface are reasonable examples of progressive disclosure done well. The principle is to design for the first-time user and make the experienced user findable without cluttering the first-time experience.
04. Competitor parity paranoia
Competitor parity paranoia
The pattern
"Competitor X just shipped feature Y. We need it too." This is one of the most common feature requests in B2B SaaS. A sales rep loses a deal. The loss report says the prospect chose the competitor because of feature Y. Feature Y goes on the roadmap. Six months later, your product has feature Y, the competitor has shipped features A through Z, and you have just confirmed that your strategy is to be a slower version of them.
Where it shows up
It shows up in the loss analysis. "We lost because we don't have X." It shows up in the feature request from sales: "the competition has X, we need X." It shows up in the roadmap when three consecutive quarters are driven by competitive reaction rather than user research.
Why it survives
It survives because it is defensible. Nobody got fired for matching the competition. The competitive-response feature has a ready-made business case: we lost a deal without it. The strategic-clarity feature requires an argument about what you are, which is a harder sell.
The fix
Strategic clarity on what you are not. Jason Fried and DHH in Rework argue that copying a competitor is a confession that you have no idea what makes you different. The fix is not to ignore competitors; it is to decide which competitive moves are consistent with your strategy and which are distractions, and to hold the line on the latter.
05. Roadmap as a list of requests
Roadmap as a list of requests
The pattern
The roadmap is a repository of things people have asked for. The sales team adds their requests. The customer success team adds the support tickets. The engineering team adds the infrastructure items they never get to. The CEO adds the ideas from the weekend. The result is a document that tracks inputs, not strategy. It tells you what people wanted; it says nothing about what the product should become.
Where it shows up
The roadmap has more than 50 items. Items have been on the roadmap for more than two quarters. Nobody can explain why items are ordered the way they are. The roadmap reads as a feature list, not as a narrative about where the product is going.
Why it survives
It survives because a roadmap of requests feels responsive and inclusive. It survives because anyone who questions a roadmap item is effectively dismissing someone's request, which feels disrespectful. It survives because a problem-framed roadmap requires more thinking, more user research, and more difficult conversations about what is not going to happen.
The fix
Problem-framed roadmaps. Each item on the roadmap is a problem to be solved, not a solution to be built. The evidence for the problem is cited. The metric that success would move is named. The solution is left open until the problem is understood. This shifts the conversation from 'will you build my feature' to 'is this problem important enough to prioritise.'
06. No sunsetting discipline
No sunsetting discipline
The pattern
Features are added but never removed. The product grows in one direction only. Features that once served a clear purpose are now used by fewer than 2% of users, but no one has the authority, the data, or the political will to remove them. The maintenance tax of dead features compounds every quarter. Engineers spend time maintaining code that serves almost no one.
Where it shows up
You have features with zero usage in the last 90 days. Your support documentation has pages for features that are technically live but nobody uses. Your onboarding flow mentions features that your current user base has never touched. You have engineers who "own" features they have never actually observed being used.
Why it survives
It survives because removing a feature requires certainty about its usage, conviction about its value, communication to any remaining users, and willingness to absorb complaints. Adding a feature requires none of those things. The asymmetry is structural: removal is high-friction, addition is low-friction.
The fix
Quarterly feature audit. A regular review of feature usage data that produces a list of candidates for deprecation. A clear sunset policy: what usage threshold triggers deprecation review, how long the deprecation notice period is, what the communication template is. See the tactical playbook for the full process.
07. Configuration overload
Configuration overload
The pattern
Every decision that was too hard to make during design becomes a toggle in the settings. Notification preferences have 30 options. The dashboard has 20 configurable widgets. The email template editor has 60 customisation fields. The export dialog has a matrix of 40 options. The product has outsourced its design decisions to the user.
Where it shows up
Your settings page is the longest page in your product. Support tickets frequently say 'I can't find where to turn off X.' Power users have elaborate configuration rituals they share in community forums. New users abandon during onboarding because the configuration step feels like a job.
Why it survives
Configuration survives as a proxy for flexibility. 'We give you the power to customise your experience.' It survives because it defers hard design decisions: rather than deciding what the right default is, you let the user decide, which feels generous. It survives because the PM who builds the configuration option looks like they are serving the user, not abdicating the design decision.
The fix
Strong defaults. The principle is from Basecamp's Getting Real: make one decision, make it well, make it the default, and let users override only the things they genuinely need to override. Basecamp's own product has famously few settings. The cognitive cost of choosing is a real cost. You are not being helpful by forcing the user to configure; you are transferring work.
08. Feature flags forever
Feature flags forever
The pattern
A feature flag is created for an A/B test or a gradual rollout. The test ends. The rollout completes. The flag stays. Another flag is created. Then another. The codebase now has 200 feature flags, each representing a branch in the code. Some have not been evaluated in two years. Nobody is sure whether it is safe to remove them. The flags have become permanent architectural decisions dressed as temporary ones.
Where it shows up
Your feature-flag dashboard has more than 50 active flags. Engineers new to the codebase spend days understanding which code paths are actually live. Your CI pipeline has tests that only apply to one flag combination. Your QA team maintains a matrix of flag combinations that is too large to test completely.
Why it survives
It survives because the cost of removing a flag is visible (requires a code change, a deploy, a test) while the cost of leaving it is invisible (accumulated cognitive load, slower CI, harder onboarding). It survives because nobody owns the flags collectively; each flag was created by a different team and removing someone else's flag feels presumptuous.
The fix
A flag-sunset policy. Every flag has a creation date and a sunset date. Flags are reviewed in the sprint before their sunset date. Flags not renewed are automatically removed from the codebase on their sunset date. LaunchDarkly and Unleash both support flag lifecycle management. The engineering investment in a flag-sunset process pays for itself in faster onboarding and cleaner code.
09. The CEO pet feature
The CEO pet feature
The pattern
The founder or CEO uses the product in a specific, idiosyncratic way. A feature that serves exactly that use case appears on the roadmap. It is built. It is used by the CEO and approximately six others. The engineering team maintains it forever because nobody will tell the CEO it should be removed. If the CEO is technical, this pattern is even harder to escape because the feature may be accompanied by a pull request.
Where it shows up
Features appear on the roadmap after a company all-hands or a one-on-one with the founder. The business case is 'the CEO wants it.' The user research is 'the CEO uses the product like this.' The maintenance burden lands on the team that did not ask for it.
Why it survives
Political reality. In most organisations, pushing back on the CEO requires significant data and significant courage. The PM who says no to the CEO needs to have the numbers to back it up and the seniority to survive the conversation. Most PMs do not, so the feature gets built.
The fix
Data, not anecdote. The CEO's product usage is one data point. User research is many. The scripts on the team-conversations page give you literal wording for the CEO pet feature conversation, framed in outcome language rather than refusal language. See also the decision framework checklist: if the feature fails the 'what metric will this move?' question, that is the argument.
10. The enterprise exception that becomes the default
The enterprise exception that becomes the default
The pattern
A large customer needs a specific customisation to close a deal. The product team builds it, scoped to that customer. Two quarters later, the sales team wants it available to all customers. The feature is now in the standard product, serving a use case that most customers do not have, maintained by the whole team, creating cognitive load for every new user who encounters it. Multiply this by ten enterprise customers and you have a product that is essentially a custom integration hub dressed as a SaaS product.
Where it shows up
Your enterprise tier has features that are technically available in all tiers. Your product documentation has sections that only apply to a few large customers. Your engineering team allocates more than 20% of its time to maintaining features used by fewer than 5% of accounts. Your product has a reputation in the market for being 'great for enterprise, confusing for everyone else.'
Why it survives
Revenue justification. The enterprise customer paying $100k per year gets its customisation. That argument is hard to refuse on a per-deal basis. What is missing from the argument is the cumulative cost of ten such deals: the product complexity, the engineering debt, and the SMB customers who churn because the product feels like it was not built for them.
The fix
Tiered architecture and honest product edition discipline. Features that exist for enterprise use cases live in the enterprise tier. They do not leak into the standard product. Pricing is structured so that the enterprise customer is paying for the maintenance burden they are creating. The alternative is a product that is neither good for enterprise nor good for SMB, which is the worst outcome.
Related reading