The solution? Don’t take things away (if you can possibly avoid it.)
How to launch software changes without pissing people off
Jonas Downey
45113

I disagree with this very broad statement about taking things away. I agree with your general points, but like pruning a tree, getting rid of the bad makes the tree stronger and healthier.

Software “rots” over time — what was important then, whether internally or functionally is less so today. Also, the way people use software changes for many different reasons. I think software should be a living thing.

Of course there are core features, but witness any of the MS Office family to see how badly they have gone wrong with featuritis. Meanwhile, Google’s office tools provide the sharing, speed, and omnipresent functionality that MSO just can’t seem to get right. My company has standardized around MSO and I still just open a Google Sheet to do 90% of what I want, then export to .xlsx.

I think the core difference is whether a feature is really something some cohort of users wants and can gain value from. And, as you suggest, let users choose to enable the feature. I sensed that Microsoft, and the many other products you raise simply add features because mindless product managers have some backlog of ideas that are “next”.

Slack recently enabled threads. I am not sure I love the implementation, but it was very subtle and is very useful. It didn’t get in my way, and as our company gradually begins to adopt it, more learn, and it spreads. It’s non-invasive and truly helpful. Another feature was to have channels you have started writing in show a little pencil in the gutter. This is a clever way to gently, incrementally, and subtly introduce functionality.

Meanwhile, taking away noise is just as important. I worked at a company with a product that has been around for 15 years. It’s got most of those 15 years of features buried in there … somewhere. So many are not used, or used by one customer. All the rest of users just have one more thing to look at. It’s easy (well, should be!) to offer a general function such as your Set up the Home Screen and this is a great way to reduce noise. But sometimes it’s better to just make it go away.

Until you remove functionality, its noise is still there in the software, even if hidden in the UI. In my current company we got bit recently by a latent bug from a long time ago. A new customer started using a feature that was implemented “lightly” … when no one really used it, it just sat there for more than a couple years.

Then a month or two ago it started getting used it turns out there was a memory issue that, after 10 or 15 “saves”, eventually took down a machine in our cluster of appservers. This went on for weeks — when you’re getting thousands of requests a minute, that one needle in a haystack is hard to identify. But it was an incredible distraction and waste of a lot of senior engineers’ days, nights, weekends, and so on.

It takes a great deal of discipline to keep a product fresh, nimble, light, fast, modern, competitive, and fundamentally solid. And part of that discipline is making things go away.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.