The Hidden Cost of Power User Features Nobody Uses

Every application eventually becomes a museum of abandoned ambitions. Somewhere between 1.0 and whatever you’re running now, somebody got excited about power users and the product acquired seventeen new ways to do a thing that worked fine with one.

My British lilac cat, Pixel, runs the same operation with her toys. She demands variety, accumulates an impressive collection, and then ignores ninety percent of it in favour of a crumpled receipt she found under the sofa. Her editorial restraint is better than most software companies’.

The awkward thing about power-user features is that they rarely serve power users. They serve the idea of power users: imaginary people with unlimited time to memorise obscure shortcuts and read a preferences panel longer than a tourist-trap menu.

What a feature actually costs

Development cost goes up roughly in line with the number of features. Testing cost doesn’t, because features interact. Maintenance compounds. Documentation grows into something nobody reads. And every menu item is one more thing standing between a user and the item they were looking for.

The interaction maths is the part product teams consistently underestimate. Ten features means forty-five possible pairwise interactions to reason about. A hundred features means 4,950. A thousand means just under half a million. Nobody tests half a million anything, so what happens instead is that you test the paths you thought of and ship the rest on hope.

This is why updates increasingly feel like whack-a-mole. Fix one bug, wake another. The codebase has passed the point where any single person holds a working model of it, so engineers work on their component and pray the blast radius stays local.

Take the humble text editor. vi shipped in 1976 and still works, still ships, still has people who’d fight you over it. Meanwhile word processors have accumulated so much that opening a two-page document spins up more compute than the Apollo guidance computer had in total. Somewhere between “insert text” and “AI-powered tone analysis of your passive-aggressive email,” the plot went missing.

Actual power users want less

Here’s the part that gets the diagnosis wrong. Real power users usually prefer simpler tools. The developer writing code for eight hours a day doesn’t want an IDE anticipating their thoughts. They want something that responds instantly, stays out of the way, and doesn’t fall over during a client demo.

They’ve been burned. They remember the update that moved the most-used button somewhere else for no reason anyone could articulate. They value predictability over novelty because novelty has cost them time and predictability never has.

Pixel makes the same call daily. She has an elaborate cat tree with three platforms, two scratching posts and a dangling mouse. Preferred sleeping location: a cardboard box that arrived with a laptop stand in March.

The feature arms race runs on a bad assumption, which is that users want more options. What they want is fewer decisions. Software that behaves predictably, does the job, and doesn’t require a certification to operate.

The cognitive tax

Every feature charges rent even if you never use it. You know it exists. It occupies space in a menu. It shows up in search results when you were looking for something else. It adds a section to documentation you’ll never read but will one day need.

Barry Schwartz made this argument about consumer goods in The Paradox of Choice, and it transfers to software cleanly. Too many options and people slow down, choose worse, and feel less satisfied with whatever they picked, because the alternatives they didn’t take are still sitting there in their peripheral vision.

The overhead compounds across the stack. A knowledge worker moves through somewhere between nine and sixteen tools in a normal day. If each one carries a hundred capabilities and you’re aware of half of them, you’re maintaining rough mental models of several hundred things you will never do. That’s not free.

Working memory is small and fixed. Every slot spent recalling where Adobe hid the export settings this release is a slot unavailable for the work. Power-user features don’t add power. They levy a tax and call it a benefit.

How I know any of this

This is the point where an article like this usually produces a study. I don’t have one, so let me be exact about what I do have.

For three months I logged which features I actually touched in the six applications I live in, meaning clicked or triggered, not the ones I’d have listed if you’d asked me. Then I counted what each application offered. My email client has somewhere north of two hundred distinct commands. I use about fifteen, and two of those are keyboard shortcuts for archive.

That’s one person’s usage over one quarter. It isn’t research and I’m not going to dress it up as research. What it’s good for is calibration: the ratio was roughly one in ten everywhere I looked, which is bleaker than the one-in-five figure that gets quoted in product decks, and it made me a lot more sceptical of my own feature requests.

The marketing trap

Product managers are stuck in a genuine bind here, and it’s worth some sympathy before the criticism.

New features are easy to market. “Now with AI integration” writes itself. “We removed three things nobody used” reads as a product in decline even when it’s a product getting better. And feature lists drive purchasing, especially in enterprise, where the buyer isn’t the user. The IT director choosing a tool for two hundred people wants boxes ticked on a requirements document. Whether anyone ever opens those capabilities is a problem for a future quarter and probably a future director.

The incentive structure that produces is exactly backwards. Products compete on count rather than quality. The application that does ten things beautifully loses the procurement bake-off to the one that does a hundred adequately, and the user only discovers the difference eight months later, mid-workflow, when the feature they finally need turns out to be half-built.

Enterprise software suffers worst. Products get complex enough that companies hire administrators to configure them, at which point the tool meant to increase productivity has acquired its own support staff and a standing meeting. The tool has become a project.

Removal takes nerve that addition doesn’t

The most impressive product decisions are usually subtractions, and they’re rare because of how the risk is distributed.

Adding is safe. Nobody has ever been fired for giving users another option. Removing means standing up in a room and saying that a thing several colleagues built, which cost real money, should be deleted. That conversation has a loser in it, and everybody can see who.

But the products people actually love are defined as much by their refusals. The original iPhone couldn’t do things other smartphones could. No stylus, no physical keyboard, no removable battery, no copy and paste for the first year. Those constraints forced decisions that made it better rather than poorer, and every one of them was unpopular in the moment.

A framework that survives contact with a roadmap meeting

If you’re arguing for simplicity inside an organisation, four questions do most of the work.

Usage frequency matters, but not the way it gets used in decks. A feature five percent of users touch daily may be worth far more than one half your users touch once a quarter. Depth beats breadth as a signal of real utility.

Discoverability correlates with value. If a feature can’t be found without documentation, either it’s badly designed or it shouldn’t exist. Good features match a mental model somebody already has.

Interaction cost should be proportional to payoff. Seven clicks deep is fine for something that saves an afternoon. It’s absurd for something that saves a keystroke, and most seven-click features are the second kind.

Removal impact is the real test, and the one teams avoid running. If this disappeared tomorrow, who notices, who complains, who leaves? Those three numbers are almost always smaller than the room assumes, and the gap between the assumption and the number is where the bloat lives.

The advantage on the other side

Companies that hold the line get compounding returns that don’t show up in a feature comparison. Maintainable codebases. Lower support costs. Documentation somebody can finish. Teams that move quickly because they aren’t nursing decade-old code paths that three customers depend on and nobody understands.

Basecamp has run a substantial business on exactly this, refusing feature requests in public and shipping less than everyone they compete with. Their product is a fraction of the complexity of the enterprise project tools it sits next to, and people stay anyway.

The same restraint shows up in the learning curve. New users get productive immediately with simple software. Complex software requires training, which requires budget, which requires justification, which requires meetings, which eventually require project management software of their own.

What to do about it

If you’re stuck inside bloated software: ignore most of it. Learn the core, resist the urge to explore every menu, and treat the preferences panel like a legal document rather than recreational reading. Your output comes from doing the work, not from mastering the tool that holds it.

If you build the stuff: measure what people actually do, not what they report doing in surveys, because the gap between those two is enormous and always flattering. Institute a budget, so every addition has to argue against a removal. And test with people trying to finish a task, not with beta testers who enjoy finding bugs and power users who enjoy complexity.

There’s a decent chance the pressure is easing on its own. Subscription fatigue is real, teams are consolidating their stacks, and the model layer is starting to absorb the edge cases that used to justify feature number 214. When something else can handle the rare path, the application underneath is free to stay narrow.

Pixel got there first. She uses two applications, the bowl and the litter tray, one feature each, one hundred percent daily active usage. I’ve never once seen her wish either of them did more.