I think there's a good point in there, but it's hidden by the linkbait headline.
You should be willing to cut out features that aren't used. They cost money to maintain, they make the system more complex (which costs money) and they confuse customers (which prevents money from coming in).
> You should be willing to cut out features that aren't used.
How about the features that everybody wants but weren't marketed / made accessible well?
In other words, I think such a statement (as well as a fair part of the article) are too simple. How do you know people just don't want the feature, but can find it and understand it?
The extreme example of this is an entire product. If a product has few users, because it has recently launched or was just badly marketed, does that mean you should cut all features, i.e. the entire product?
Feature-cutting can be a dangerous process, and should be done with EXTREME caution. No one wants to be another Microsoft, who intelligently decided that the timeline "was not a vital feature" in its Movie Maker.
I would argue that if useful features that can definitely improve an user experience is not being fully taken advantage of, it's likely a case of poor implementation. In one of my projects, I remember adding a feature near the launch - but I (wrongfully) assumed people would be amazed and tell each other how great it was. A year and a half later, I had a giant thread on my forums with +1's asking for the exact same feature I had already implemented.
once upon a time there were two startups. both launched a so-so product. users liked it, kinda. both startups analyzed their product after the start phase. both saw: hey, users aren't using 90% of our features. one startup decided two ditch 90% of their features, the other said: but hey, we already invested so much work in it, we don't want to throw it all away. lets make a reDESIGN (with DESIGN in UPPERCASE letters).
one startup was bought 1 year later, the other is now (3 years later) switching their strategy to mobile (as their website stuff ... just ... did ... not .... work ... out).
hope you like the story. you can decide for yourself which startup was bought?
Fairly common-sense, an actual example would have helped. It's pretty obvious that you should kill features that no one uses. But it's never the case. In practice, a handful of users use it, so now what, do you do?
In the example given, it was only used a couple times in as many years... And their answer was to kill it and wait for someone to complain.
For something that's used a little more, I would say survey the customers who use it and find out why and how they use it. Maybe they use it because they actually want something else, but it's the best they could find. Maybe they use it by mistake, thinking it does something else. Maybe it's actually quite useful, and nobody knows it exists!
If none of your customers uses it for what you think is a good reason, I'd push hard to get rid of it.
At a previous company, every few months someone would write up a bug report saying feature X didn't work. (Different each time, of course.) After investigation, it would turn out 1 of 2 ways every time:
1) The feature works just as intended, but is so seldom used that the CSRs didn't understand how it works, and neither did the customer.
2) The feature has never worked properly, and nobody had tried to use it before.
The time spent dealing with those 2 situations cost the companies about 10 hours of my time every couple months. I have no idea how much CSR time it cost, but it was probably quite a bit more than my time. They didn't bring any customers in, and they didn't keep any existing customers. The features only ever cost money.
You can re-design for many different reason.
If you wanted to redesign for better visual structure that would be one thing where you aren't necessarily cutting features but layouting them better.