Do you really need that feature?

Have you ever caught yourself, or your team, thinking: people like X, we should add X as a feature? Maybe a customer suggested it. Maybe marketing spotted a competitor doing it. More features feel like more value, surely that’s a safe bet?

Every feature you ship is a permanent tax on your product: more surface area to navigate, more code to maintain, more decisions for users to make before they get to the thing they came for. More consequences for your product as a system. And usually, most of it never gets used.

Pendo’s 2019 analysis of usage across more than 600 SaaS products found that just 12% of features drive 80% of daily usage. Pendo, 2019 Feature Adoption Report. Source Pendo, 2019 Feature Adoption Report. Source The Standish Group found something similar back in 2002: roughly two-thirds of features in the average product go unused. Widely cited as “64% of features are rarely or never used.” Worth knowing the number traces back to a small internal study, not a broad industry survey, though the general pattern still holds up across later research. Source Widely cited as “64% of features are rarely or never used.” Worth knowing the number traces back to a small internal study, not a broad industry survey, though the general pattern still holds up across later research. Source

Most of what feature teams build is potentially dead weight. So the real question isn’t “could this be a feature?” It’s “do we need it?”

01The Swiss Army Knife

Take the Swiss Army Knife. It’s a great product with a lot of tools packed into a small space, and it earns that density because of the context it’s built for: survival and camping, where carrying a full toolbox isn’t an option. Tiny scissors beat no scissors. But your hairdresser isn’t reaching for the Swiss Army Knife’s scissors to cut your hair.

The Swiss Army Knife does a lot of things, but nothing as well as the dedicated version of that thing does it. That’s the deal you make in exchange for portability, and it’s a good deal when you’re out in the wilderness.

Most products aren’t being used in the wilderness. Your users usually have other tools within reach, so bundling doesn’t earn the same goodwill it earns a multitool in a backpack. Context decides whether a broad feature set is a strength or a liability, and most teams never stop to ask which one they’re in.

02The power of removal

Add enough features and you get feature bloat: a slow entropy where the product’s original shape disappears under everything that’s been layered on top. Strap ten car-repair tools onto the Swiss Army Knife and it stops being a pocket multitool. It becomes a heavy, confusing object that does everything a little worse than it did the one thing it used to do well.

I used to think of this mostly as a discipline problem: nobody says no and bloat creeps in. But there’s research suggesting it goes deeper than that. Gabrielle Adams and colleagues at the University of Virginia ran a series of studies, published in Nature in 2021 and later expanded by co-author Leidy Klotz into the book Subtract, and found that when people are asked to improve something, they reach for addition almost every time, even when removing something would clearly work better. Adams, Converse, Hales & Klotz, “People systematically overlook subtractive changes,” Nature 592 (2021). Source Adams, Converse, Hales & Klotz, “People systematically overlook subtractive changes,” Nature 592 (2021). Source

In one study, people improving an overloaded New York itinerary barely ever removed anything from it. Most only started cutting items once the researchers explicitly reminded them that “improve” could mean taking things away, not just piling more on.

Have you ever been in a meeting where the purpose was to build something? The goal was to ship something. Every addition feels like obvious progress in the room, while removal has to be proposed on purpose, defended, and often re-justified.

Addition is just easier.

03Removing is designing too

As designers, we’re wired to create: a new feature to delight customers, a new flow to win new ones. But think about the last time you removed something from a live product to make it better. Not in a design review, in production, after people were already relying on it. For most of us, that’s a really short list.

Once a feature ships, it’s hard to kill. The business feels like it already invested time and money into it, and now removing it costs more time and money on top of that. There’s almost always a small group of people who love it, however little it’s used, and they tend to be loud precisely because they’re the ones still there.

Internally it’s an awkward conversation too: someone championed this feature once, it might still be tied to their performance review, and telling them their project is getting cut isn’t a meeting anyone volunteers to run. The longer a feature survives, the harder and more expensive it gets to remove, which is a big part of why so few teams ever get around to it, and why bloat tends to build up rather than reset.

Cutting a feature you don’t need is good design. Cutting it without warning, without a migration path, without an explanation, ends up costing you almost as much goodwill as never cutting it at all.

Cutting bloat is design work, and it deserves the same celebration as shipping new stuff.

04How to make subtraction routine

So what’s your product’s central proposition? What problem are you solving, for whom, in what context? Steve Blank’s format still works well here: we help (X) do (Y) by doing (Z).

Take a banking app. Say you’ve learned your customers are constantly on the move and need to pay quickly while commuting. The central proposition might be simple: we help our customers save time by making payments fast. QR-code payments and Apple Pay support that directly. A photo-sharing feature or an in-app gift shop might delight someone, somewhere, but neither one defends itself against that proposition.

Test every idea against that statement, and be honest about the answer. Does this support what we’re trying to do, or are we just excited about it? Is it a logical extension of the core, or could we simply skip it? If you can’t answer that in a sentence, you probably already have your answer. The proposition itself deserves scrutiny too, probably even more so. Products evolve and contexts shift, and a proposition that was right three years ago can go stale fast. The proposition itself deserves scrutiny too, probably even more so. Products evolve and contexts shift, and a proposition that was right three years ago can go stale fast.

I have collected a few habits to make this line of thinking part of your regular routine in product development:

None of this makes it painless to kill something people rely on. There is an emotional aspect that you can’t ignore. There are always people who worked on the feature before. There is an emotional aspect that you can’t ignore. There are always people who worked on the feature before. But here is my challenge to you. Think of removal as a normal, expected part of doing product design.

What would you remove from your product to make it better?

05Further reading

• Adams, Converse, Hales & Klotz, “People systematically overlook subtractive changes,” Nature 592 (2021). The study behind the “we default to adding” argument.
• Leidy Klotz, Subtract: The Untapped Science of Less (2021). The book-length version, with more examples across design, writing, and policy.
• Pendo, 2019 Feature Adoption Report. The 12%/80% usage-concentration data point.
• Nielsen Norman Group on feature creep and feature bloat. The usability angle on the same problem.
• Killed by Google. A running, slightly gleeful catalog of what happens when subtraction is done without care for trust.
• Basecamp’s Shape Up on shipping less and saying no.
• Marty Cagan, Inspired. On product management as mostly the discipline of deciding what not to build.
• Barry Schwartz, The Paradox of Choice. The psychological backdrop for why more options can make products, and people, worse off, not better.