When a Product Needs Fewer Features

There is a moment in the life of most software products when they start getting worse by getting bigger. Nobody decides this. It happens one reasonable request at a time. A customer needs an export in a particular format. A sales conversation depends on a specific integration. An internal team wants a setting to handle an edge case. Each addition is small, justified and welcome to someone. Collectively, they turn a clear product into a cluttered one.

Our view is simple, if not always popular: a great many products would be better with fewer features, and the discipline to remove, decline or consolidate them is one of the most undervalued skills in product work.

Why features accumulate

Features accumulate for structural reasons, not because product teams lack taste.

Adding is visible. A new feature can be announced, demonstrated, attributed to a team and counted as progress. Removing is invisible, or worse, visible only as a complaint from the few people who used what was removed. Roadmaps reward the first and punish the second.

Requests arrive as solutions. Customers rarely say "I have this problem." They say "please add this button." The request is specific and actionable, and it is easier to build what was asked than to understand the problem well enough to know whether the product already solves it in another way.

The cost is deferred. A feature's cost of construction is visible at the moment of decision. Its cost of ownership, which is larger, arrives slowly and is spread across everyone else.

What a feature really costs

The cost of a feature is not the effort to build it. That is the down payment.

Every feature adds something users must notice, understand or learn to ignore. It adds states the system can be in, and the number of combinations grows faster than the number of features. It adds cases to test on every release, documentation to keep current, questions for support to answer, and constraints on what can be changed next. It adds weight to every future design decision, because every new idea must now fit around everything already there.

Most of these costs are borne by people who did not ask for the feature. The customer who needed the special export pays for it once. Every other user pays a little, forever, in a slightly busier interface and a slightly slower product.

The customer who asked for the feature pays for it once. Everyone else pays a little, indefinitely.

Cognitive load is a real constraint

Users have finite attention. Every visible option competes for it. When a screen offers twelve actions, users must scan all twelve to find the two they need, and they must make that small effort every time. Experienced users learn to filter; new users are overwhelmed. Either way, the product asks more of people than it needs to.

This is why discoverability tends to decline as products grow. The features added to help specific users make the core features harder for everyone to find. Menus lengthen, settings pages multiply, and important capabilities end up buried because there is no longer an obvious place for them. Product teams then add onboarding tours and tooltips to explain an interface that has become hard to understand, which is treating the symptom.

Configuration is often a deferred decision

A particular form of accumulation deserves its own mention: the setting. When a team cannot agree on how something should behave, or when two customers want different behaviour, the easy answer is to make it configurable.

Sometimes that is right. Genuine differences between customers do exist, and some of them warrant options. But settings are frequently a way of avoiding a product decision. Instead of working out which behaviour is better, the team ships both and asks the user to choose, usually during setup, before they have enough context to choose well. Each setting also doubles the number of ways the product can behave, which multiplies testing and support.

A useful test: if the team cannot articulate who would choose each option and why, the setting is probably a decision that has not yet been made.

Simplicity is an engineering discipline

It is common to talk about simplicity as a design virtue. It is equally an engineering one.

A product with fewer features has fewer code paths, fewer interactions between components, and fewer states to reason about. It is faster to test, easier to secure and quicker to change. Because users experience the whole system rather than individual screens, those engineering benefits reach them directly, as speed and reliability. Bugs are rarer and easier to find. New engineers can understand it sooner. Performance is easier to maintain because there is less to maintain it across.

This is why simplicity has to be defended actively. Complexity arrives on its own; simplicity requires someone to say no, repeatedly, and to explain why. In our experience that person is most effective when they can speak to both sides of the cost: what the feature does to the user's experience and what it does to the system underneath.

Focus on the workflow, not the feature list

Much of the pressure to add features comes from thinking about products as lists of capabilities. Comparison tables, requests for proposals and sales conversations all encourage it. A product with more checkmarks looks stronger.

Users, though, do not experience feature lists. They experience workflows: the sequence of steps they take to accomplish something they care about. A product with fewer features that makes the core workflow fast, clear and reliable is usually more valuable than one with many features and a mediocre core.

We try to design around a small number of workflows done properly. AlphaSync, for example, is built around one sequence (design a strategy, backtest it, paper trade it, then go live), and that constraint is deliberate. A strategy only reaches live capital after passing through the earlier steps. The workflow is the discipline, and it is also what keeps the product coherent as capabilities are added within it.

Questions worth asking before adding

The easiest feature to manage is the one that was never built. That does not mean refusing requests; it means examining them properly. A handful of questions do most of the work.

What problem is this request trying to solve, and can the product already solve it some other way? Surprisingly often the answer is yes, and the real fix is making the existing path easier to find.

How many users have this problem, and how often? A need that is frequent for many people deserves a place in the core. A need that is occasional for a few may be better served by an export, an integration or a documented workaround.

Where would it live? If there is no natural place for a feature in the existing structure, that is information. Either the feature does not belong, or the structure needs rethinking before anything is added to it.

What will it cost to keep? Not to build, but to test on every release, to support, to document and to design around. If nobody can estimate that, the decision is being made on half the information.

And would we be comfortable removing it later? If the honest answer is that removal would be very hard, the bar for adding it should be correspondingly higher.

How to remove things

Removing features is harder than not adding them, because someone depends on almost everything. A few practices make it tractable.

Measure actual use, not assumed use. Features that nobody uses are easy to remove. Features that a small number of people use heavily need a different conversation.

Understand the underlying need. Often the people relying on a feature want the outcome it provides, not the feature itself, and that outcome can be delivered in a simpler way or through something the product already does.

Deprecate visibly and gradually. Announce the change, explain why, provide an alternative, and give people time. Removal handled carefully tends to generate far less resentment than removal handled abruptly.

Consolidate before deleting. Three similar features can often become one better one. That is removal that users experience as improvement.

The counterargument deserves a hearing

None of this means complexity is always a failure. Some products serve genuinely complex work: professional tools for engineers, analysts, designers or traders, where users need depth and are willing to learn it. Stripping those products down would make them useless to the people who rely on them.

The answer in those cases is not removal but layering. Keep the common path simple and prominent. Put advanced capability behind clear, discoverable entry points, where experts can find it and newcomers are not confronted by it. Let the product reveal its depth as the user's needs grow. Complexity that is organised is very different from complexity that has simply accumulated.

Maturity looks like restraint

Early products need to add features to become useful at all. That phase is real and necessary. But products that stay in it indefinitely tend to lose the clarity that made them valuable in the first place.

A mature product is not one with the most features. It is one whose team understands its core workflows well enough to protect them, knows the cost of what it adds, and is willing to take things away. That kind of restraint rarely appears in launch announcements. Users notice it anyway, usually as a product that simply feels easier to use than its competitors, without being able to say why.

The practical question for any product team is not "what should we add next?" but "what would make the core better?" Sometimes the answer is a new feature. More often than roadmaps suggest, it is fewer. That question sits at the centre of how we scope product engineering work as well as our own platforms.