When a property company compares software, the feature list does a lot of the deciding. One platform offers two hundred capabilities, another offers eighty, and the two hundred feels like more value for the money, more room to grow, more boxes ticked. The longer list wins the comparison, and it wins for a reason that feels like common sense: more is better, and you would rather have a feature and not need it than need it and not have it.

That instinct is wrong often enough to be worth examining, because features are not free just because you are not using them. Every capability in the product you bought is something you navigate around, scroll past, train new hires to ignore, and carry as complexity whether or not you ever touch it. The feature you will never use is not sitting harmlessly in a menu. It is making the features you do use a little harder to find, the interface a little more crowded, and the whole system a little heavier to operate, every day, forever. You paid for it once in the purchase, and you keep paying for it in the friction it adds.

The research has a name for this

This is not a hunch. It is a documented effect with decades of study behind it.

Marketing researchers Roland Rust, Debora Viana Thompson, and Rebecca Hamilton named it feature fatigue: the well-studied finding that products loaded with capabilities win at the moment of choice but disappoint in actual use, because more features make a product harder to use. Across three studies, published in the Journal of Marketing Research and later in Harvard Business Review, they found something specific and damning: consumers know that products with more features are harder to use, and they choose the feature-heavy option anyway, then pile on still more when given the chance to customize. The regret comes later, once they are living with the complexity they chose.

The mechanism is an asymmetry in what buyers weigh and when. Before use, people give the most weight to capability, how much the product can do, which is exactly what a feature list and a demo showcase. After use, they give the most weight to usability, how easily it does the thing they actually need, which the feature list never measured. So buyers systematically choose products more complex than the ones that would actually make them happiest, because the qualities that win the purchase are not the qualities that make the daily work good. The property company reading the two-hundred-feature list is standing exactly where the research says people over-choose.

Why the unused feature still costs you

The counterintuitive part is that a feature can cost you even if you never once use it. The cost is not in the using. It is in the presence.

• It crowds the features you do use: Every capability in the product takes up space in menus, screens, and settings, and the ten features your team relies on now sit among the hundred they do not. Finding and using the core functions is slower because they are buried in the noise of everything else, so the unused features tax the used ones continuously, by making them harder to reach.

• It raises the cost of learning the system: A new hire has to make sense of the whole interface, not just the part they will use, and a product dense with capabilities is a product that takes longer to learn and is easier to get wrong. The unused features lengthen onboarding and widen the surface area for mistakes, even though nobody will ever deliberately touch them.

• It adds decisions that did not need to exist: Every option is a small choice imposed on the user, which way to do a thing, which of several overlapping features to use, whether the setting matters. Capability the team does not need still generates decisions the team has to make, and the accumulated weight of unnecessary choices is real friction, spent on operating the tool rather than doing the work.

• It is something you keep paying for: Features are maintained, updated, and supported, and that cost lives in the price of the product whether you use them or not. You are funding capability you will never benefit from, and carrying the complexity it adds, on every renewal.

None of these show up on the comparison sheet, where the extra features appear as pure gain. They show up later, in the daily experience of a team operating a heavier system than it needed, which is precisely the gap between the capability that won the purchase and the usability that governs the work.

What this looks like in a property operation

The pattern is concrete in property software, where the temptation to buy the maximal platform is strong.

A team chooses the system with the most capabilities, reasoning that a growing portfolio will grow into them. Two years later they use a familiar fraction of what they bought, and the rest is not dormant, it is in the way: the reporting module thick with options nobody selected, the settings screens full of toggles for workflows the company does not run, the menus listing modules the team was told to ignore during training and has ignored ever since. The core tasks, the leasing, the rent, the maintenance, the reporting they actually need, are all a little slower to reach and a little harder to teach because they live inside a product built to demo well against every competitor rather than to be used well by this team. The features they never adopted did not add value they might someday capture. They added drag they pay for now.

The honest part

Several qualifications keep this from becoming a naive argument for buying the thinnest possible product, which is its own mistake.

More capability is often genuinely valuable, and under-buying has real costs too. A platform too thin to handle a commercial lease, a multi-entity structure, or a growing portfolio will fail you exactly when you grow into the need, and the friction of a missing feature is worse than the friction of an unused one. The argument is not to minimize features. It is to stop treating a longer feature list as automatically better, and to weigh usability, the experience of the features you will actually use, as heavily as capability, which the buying process systematically underweights.

Crucially, the researchers who named feature fatigue did not conclude that products should have fewer features. They concluded that the answer is better design, capability that does not create fatigue, features that stay out of the way until they are needed rather than crowding the ones in daily use. That distinction matters enormously here. A platform can be genuinely comprehensive and still feel simple, if its depth is organized so that what you do not use does not burden what you do. The goal is not less capability. It is capability that stays invisible until you reach for it, which is the same quality examined in the best software is the software you don't notice.

And you genuinely cannot predict every feature you will need, so some capacity you are not using today is a reasonable hedge rather than pure waste. The mistake is not keeping a little room to grow. It is buying the maximal product on the theory that more is always safer, and paying for that theory in daily complexity while the growth you were preparing for may never require most of what you bought.

Buy for the work, not for the feature count

The practical discipline is to evaluate software on the capabilities you will actually use and how good the experience of using them is, rather than on the length of the list.

When comparing platforms, identify the functions your operation genuinely depends on and compare how well each product does those specific things, in daily use, not in a demo. Treat a large count of features you will not use as a neutral-to-negative factor rather than a bonus, because each one is complexity you will carry. Weight usability, speed, clarity, how quickly a new hire becomes productive, at least as heavily as capability, since usability is what governs the work and capability is what governs the demo. And where a platform is genuinely deep, ask the design question directly: does the depth you will not use stay out of the way of the depth you will, or does it crowd it?

There is a single question that corrects for the bias the buying process builds in. Am I choosing this because of what it will let my team do every day, or because of a feature list that impressed me in a room I will never work in? The feature that wins the comparison and the feature that serves the work are frequently not the same feature, and the whole of feature fatigue is the gap between them. The best system for your operation is not the one that can do the most things. It is the one that does the things you actually need with the least friction, and lets everything you do not need stay quietly out of your way.

FAQs

Q1. Isn't more features better value for the money?
Not automatically, because features you do not use are not free, they add complexity you carry every day whether or not you touch them. A longer feature list wins comparisons because it looks like more value, but capability you never use crowds the capability you do, lengthens training, and adds unnecessary decisions. Value comes from the features you actually use and how well you can use them, not from the total count on the comparison sheet.

Q2. What is feature fatigue?
It is a documented effect, named by marketing researchers Rust, Thompson, and Hamilton, in which products loaded with features win at the moment of purchase but disappoint in use because the added capabilities make them harder to use. Across three studies, buyers chose feature-heavy options despite knowing they would be harder to use, then regretted the complexity once they lived with it. The qualities that win a purchase differ from those that make daily use good.

Q3. How can a feature I never use cost me anything?
Through its presence, not its use. Every capability occupies space in menus and screens, so the features you rely on sit among many you do not, making them slower to find. Unused features lengthen how long a new hire takes to learn the system and widen the room for error. They add options and decisions that need not exist. And they are maintained and supported at a cost built into the price you pay on every renewal.

Q4. Why do buyers consistently over-choose on features?
Because of an asymmetry in what they weigh and when. Before using a product, people give the most weight to capability, how much it can do, which is exactly what feature lists and demos showcase. After using it, they give the most weight to usability, how easily it does what they need. Since the purchase happens before use, buyers systematically choose products more complex than the ones that would actually serve them best.

Q5. Does this mean I should buy the software with the fewest features?
No. Under-buying has real costs too, a platform too thin to handle a commercial lease, multiple entities, or a growing portfolio will fail you when you need it, and a missing feature causes worse friction than an unused one. The point is not to minimize features but to stop treating a longer list as automatically better, and to weigh usability as heavily as capability rather than letting the feature count decide.

Q6. Isn't some unused capability a reasonable hedge for growth?
Yes, keeping a little room to grow is sensible, and you genuinely cannot predict every feature you will need. The mistake is buying the maximal product on the theory that more is always safer, then paying for that theory in daily complexity while much of the capability may never be required. A modest hedge is prudent; maximizing the feature count as a growth strategy is how you end up operating a heavier system than you needed.

Q7. Can a comprehensive platform avoid feature fatigue?
Yes, and this is the key point. The researchers who named feature fatigue concluded the answer is not fewer features but better design, capability organized so that what you do not use does not burden what you do. A platform can be genuinely deep and still feel simple if its depth stays out of the way until needed. The goal is not less capability but capability that is invisible until you reach for it.

Q8. How should I actually compare platforms then?
Identify the functions your operation truly depends on and compare how well each product does those specific things in daily use, not in a demo. Treat a large count of features you will not use as neutral-to-negative rather than a bonus. Weight usability, speed, and how fast a new hire becomes productive at least as heavily as capability. And for deep platforms, ask whether the depth you will not use stays out of the way of the depth you will.