Death by a Thousand Features

Originally published in 2024 and revised in 2026 with updated research.

Products rarely become confusing because somebody deliberately set out to make a confusing product. They become confusing one reasonable request at a time.

A customer asks for another permission. Sales needs one more configuration option to close a deal. A competitor launches a dashboard. Support proposes a shortcut for a recurring complaint. Every request has a plausible explanation, and building it feels responsive. Six months later, the product has more capabilities but a weaker identity. New users struggle to understand where to begin, existing users discover several ways to do the same thing, and the team is maintaining workflows it can no longer confidently explain.

I call this death by a thousand features. The danger is not one obviously bad idea. It is the accumulated cost of many defensible ideas that were evaluated individually rather than as additions to a whole product.

AI makes this failure mode more important. When implementation becomes cheap, the friction that previously forced teams to prioritise disappears. We can prototype almost anything. That should help us learn faster, but it can also make it dangerously easy to turn every suggestion into permanent product surface.

More Capability Can Produce Less Value

The assumption behind feature accumulation is that every useful capability adds value. It sounds mathematical: if the product already solves five problems, surely solving a sixth makes it better.

That ignores usability. A feature can add capability while making the overall product harder to understand, choose, configure, explain, and operate.

This trade-off appears clearly in the research on feature fatigue. In three studies, Debora Viana Thompson, Rebecca Hamilton, and Roland Rust found that people placed greater weight on capability before using a product, but greater weight on usability after using it. Participants were therefore attracted to products with more features even when the resulting complexity reduced their satisfaction during actual use. The researchers' model also suggested that optimising for initial choice could lead companies to include more features than was best for long-term customer value. The original study concerned consumer products, so it is not a universal measurement of software behaviour. The mechanism is nevertheless familiar: the feature list helps win the comparison, while the customer later pays the usability cost.

The related evidence on choice overload is more nuanced than the slogan “more choice is bad.” A meta-analysis of 99 observations involving 7,202 participants found that larger assortments were especially likely to create overload when the options were difficult to compare, the decision was complex, people were uncertain about their preferences, or they were trying to minimise effort. The researchers did not find that every additional option automatically harms every decision.

That distinction matters for software. Five clear report templates may help. Five overlapping permissions with unclear consequences may not. The problem is not simply feature count; it is the reasoning burden the product transfers to its users.

Every Feature Has a Carrying Cost

Teams often estimate the cost of getting a feature into production. That is only the entry price.

Once released, a feature becomes something the organisation may need to:

• Preserve through schema and API changes.
• Test against adjacent workflows and permissions.
• Explain in onboarding, sales material, and support documentation.
• Monitor and debug when its assumptions meet real customer data.
• Secure as dependencies and threat models change.
• Migrate or deprecate when the product changes direction.

This carrying cost continues even when usage is low. In fact, rarely used features can be unusually expensive because fewer people remember why they exist or notice when they break.

Pendo analysed anonymised usage data from its customer base and reported that 80% of features in the average product in its dataset were rarely or never used. This is vendor research from companies using Pendo, not a representative census of all software, and “rarely used” does not automatically mean useless. An account-deletion control, an emergency export, or a compliance workflow may be valuable precisely when it is needed infrequently. The result is still a useful prompt: shipping a capability is not evidence that it became valuable.

The right question is not “How often is this clicked?” It is “Does the value created justify the permanent cost and complexity?”

Discoverability Is Often the Real Problem

Feature requests do not always indicate a missing capability. Sometimes they indicate that an existing capability is invisible, difficult to understand, or located in the wrong part of the workflow.

Microsoft encountered this at an extreme scale while redesigning Office. The story is often repeated as “90% of requested features already existed,” but that is not what the available primary account says. Jensen Harris, who led the Office user-experience team, writes that telemetry showed 90% of users used less than 10% of the product's features. The Ribbon was an attempt to make existing functionality more visible and understandable across a product whose commands had become scattered among menus, toolbars, and task panes.

That does not mean every product needs a new navigation system. It means a request for functionality should trigger diagnosis before implementation:

• Does the capability already exist?
• Can the customer find it at the moment they need it?
• Do they understand its name and consequence?
• Does it require configuration before it creates value?
• Is the underlying workflow itself unnecessarily complicated?

The solution may be a clearer default, better wording, a shortcut in the relevant workflow, or the removal of an earlier decision. Building a second route to the same outcome can make the immediate complaint disappear while making the product less coherent.

Customer Requests Are Evidence, Not Specifications

Customers are usually excellent witnesses to their own frustration. They are not responsible for designing the smallest coherent solution across the entire product.

When somebody asks for a custom report builder, the important fact may be that they cannot answer a recurring management question. When they ask for another status, the real problem may be that the existing workflow does not distinguish ownership from progress. When they request an export, they may be trying to complete work in another system rather than asking for CSV as an end in itself.

Treat the proposed feature as one hypothesis about the underlying job. Ask what happened immediately before the request, how the customer handles it today, how frequently it occurs, what the workaround costs, and what would improve if the problem disappeared. Repeated behaviour and real consequences are stronger evidence than enthusiasm for a mock-up.

This does not mean ignoring customers or assuming the product team knows better. It means respecting the difference between knowledge of the problem and responsibility for the whole solution. Several customers may describe the same underlying constraint through completely different requested features. Building all of them would fragment the product; understanding the shared constraint may reveal one smaller intervention.

Audit the Product, Not Just the Backlog

Roadmaps naturally look forward. Feature discipline also requires looking backward.

I periodically review the existing product and ask:

• Which capabilities contribute to activation, retention, revenue, risk reduction, or a contractual obligation?
• Which are heavily used by a small but valuable group, and which are merely present?
• Which features create disproportionate support tickets or regression risk?
• Where do several options solve nearly the same problem?
• What would we refuse to build if it did not already exist?

Usage is one input, not the verdict. A feature used by 2% of customers might protect half the revenue. A feature used by 60% might only be used because the product forces everyone through it. Quantitative telemetry tells us what happened; customer conversations and business context help explain why.

Deletion also needs evidence and care. Before removing a feature, identify the customers and workflows that depend on it, provide a migration path when the consequence is meaningful, and measure what happens after the change. Simplification is product work, not spring cleaning.

Define the Result Before Building

The easiest time to be honest about a feature is before it exists.

For any meaningful addition, I want a short statement covering:

• The customer behaviour or outcome we expect to change.
• The evidence that the problem is frequent or expensive enough to address.
• The smallest intervention capable of testing the assumption.
• The measurement window and success threshold.
• What we will remove, revise, or stop if the result does not appear.

This turns a feature from an object the team has promised into a hypothesis the team can evaluate. It also makes prototypes safer. An AI agent can produce a convincing experiment in hours, but visible software is not the same as validated value. A prototype should earn evidence before it earns production data, permissions, monitoring, support, and indefinite compatibility.

Rollouts should preserve that ability to learn. Start with the smallest relevant customer group, observe the intended outcome and unintended effects, and expand only when the evidence supports it. A staged release is not merely a risk-control mechanism; it is an opportunity to discover that the feature should remain narrow—or should not survive at all.

Make Subtraction Part of Product Strategy

Teams celebrate launches because additions are visible. Removing a redundant setting, combining two workflows, or deciding not to build something rarely creates the same internal excitement. Yet these decisions protect the qualities customers feel every day: clarity, speed, confidence, and a product they can explain to somebody else.

The goal is not minimalism as an aesthetic. A capable professional tool may legitimately contain hundreds of functions. The goal is coherence: each capability should serve a recognisable customer outcome, fit the product's model, and justify the burden it creates for everyone who must understand or maintain it.

The hardest product decision is usually not how to build another feature. It is determining whether the problem deserves a feature, whether an existing path can be simplified, and whether something else should disappear first.

We can build more than ever. That makes restraint more valuable than ever too.