3 ms·

I would love to. But users freak when you take things away. And when users freak, sales and marketing freak even more. The fact that a "cleaned up kitchen" may

I would love to. But users freak when you take things away. And when users freak, sales and marketing freak even more. The fact that a "cleaned up kitchen" may be better for the user community and product as a whole, is lost on the sales and marketing types who tend to be very focused on achieving short term goals rather than mid and long term ones.

wruza 6y ago
Wouldn’t you freak too if your bike was suddenly stripped of pedals “because we found out new users are better without these”? Software products are shared between different users who build their own processes on top of that. No surprise they complain when someone breaks these because “cleaner look” or “better for the community” (what does it even mean?). If you believe in a fresh start, start a new project instead of tricking everyone into something they probably can’t use effectively anymore.
- ajmadesc 6y ago
  A better analogy would be getting upset that your dozer, back hoe, fertilizer spreader, auger tractor, had the steering wheel replaced with two ropes you pull on
  - DivisionSol 6y ago
    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 6y ago
      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.

wruza 6y ago

Wouldn’t you freak too if your bike was suddenly stripped of pedals “because we found out new users are better without these”? Software products are shared between different users who build their own processes on top of that. No surprise they complain when someone breaks these because “cleaner look” or “better for the community” (what does it even mean?). If you believe in a fresh start, start a new project instead of tricking everyone into something they probably can’t use effectively anymore.

ajmadesc 6y ago
A better analogy would be getting upset that your dozer, back hoe, fertilizer spreader, auger tractor, had the steering wheel replaced with two ropes you pull on
- DivisionSol 6y ago
  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 6y ago
    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.