[DivisionSol]

Gonna push back on this analogy. Ripping out features that cause more trouble than they're worth is like moving a dozer, back hoe, fertilizer spreader, etc off your property.

Average users appreciate all the extra real estate of their back yard! So much time to do the thing they enjoy, gardening.

Power users hate you, they used those power tools every day! They felt in control! Their backyard garden was meticulously crafted!

Ideally when you take their dozer, back hoe, etc, you put them into an easy to access shed out of sight from most users. Of course it's an engineering/design challenge to 1) create a shed (segment these features without adding complexity), 2) make it easy to use for power users ("wahh, I gotta click through 4 more options!"). They might be able to pull out their auger tractor, but it just isn't as easy as starting the auger tractor right where they left off.

Even with an analogy, it's hard to say: "1% of our users use this feature, tear it out." Even when it imposes > 1% of work on all future features/releases/testing.

[wruza]

One thing to note is, the less users use a feature, the less you understand how exactly they do it. Of course from a saas point of view, it’s easier to serve most and forget about least (we are here). But technically, only n% of users have advanced tasks that require a dozer on their lawn, because their “lawn” was not meant to have a grass or a kids playground on it from the start. If you sell a product that initially has a dozer in it, it will be bought by 88 home owners and 12 construction sites, because it fits both. If you then remove a dozer, or even put it into “easily accessible place”, construction sites will stall, because their speed depends on having that thing always present on site.

As one example, search engines respect quotes less and less with years. So even if you quote few words, you may not find it anymore.

Another example is my bank app that combined searches from different pages into one omnisearch field. Before that, I could simply go to a specific card and search for “digi” to see recent digital ocean payments with dates, and screenshot it to my accounting guys (also scaleway, kamatera, you name it). Now I have to scroll through “suggestions this week” (ads) with random “digi” in them, and then tap on every DO payment, because some of them are my own expense (on a different card), and I can’t see dates in a list anymore, because “date” is a property of a payment, and omnisearch searches for all kinds of items, and their common class doesn’t have a date, so to speak. They broke it for me, because now instead of one “shutter-send” I have to wait for 5-15 REST queries to complete and shutter-send each of these, confusing my accounting, because they also prefer lists with dates. Not to mention that omnisearch may not show some items for an unknown reason, and that I have no idea who wanted to search for ads and other crap in a bank app, instead of having well-partitioned searches together with a proper omnifield.