"In the early days we added too many features."

I've heard this from most of the people we've interviewed for Kill the HiPPO, our book on feature prioritisation for bootstrapped software founders.

In a research interview we conducted yesterday, the interviewee shared a powerful way to stop the inevitable UI clutter that results from this:

(I can't say who the interviewee was yet; our process is to always get chapter drafts approved by the interviewee before we share info about them and their product.)

When your software product is new, you'll get positive comments like "it's so simple" or "I like that the user interface is uncluttered." You'll bask in this praise. You'll think you are a master designer of software. Whereas the reality is that your product is simple and uncluttered because it doesn't do much yet.

That initial praise will often be followed by a feature request: "It's so simple, but...it really needs feature X or improvement Y".

And you'll say "Great feedback! Of course it does!" and you'll rush off and implement that thing. And because your software is simple that thing will be done quickly and delivered quickly and the user will be mightily impressed. And you'll feel great and tell yourself how great you are at customer support and at listening to customers and at delivering improvements.

Your product will still feel simple and uncluttered, but actually you've just made it slightly less simple and slightly more cluttered.

You were able to deliver the improvement so quickly because your product hasn't had time to develop complicated interactions between components. But you've just introduced the smallest sliver of technical debt. So small you can't see it or feel it, but it is there.

Repeat this story 20 times or maybe 50 times and one day, without you realising it, you reached the point where no-one describes your product as simple or uncluttered anymore.

And you stopped delivering improvements in a day, because now anything you add has consequences all over your product.

That's when it is time to follow the adage "Remove a button, add a button".

Adage? Make it a mantra!

Obviously you can't always find something to remove. But probably you can 90% of the time? Or even 95%?

Look for the old feature that is kind of obsolete now. Remove it.

Look for the setting that almost no-one changes. Make it default to the common setting. And remove it.

Look for the button that could be replaced with a UI concept that barely existed when you first added it but is now ubiquitous, like hash tags or infinite scroll or "slide right to archive"

We've removed a couple of things from Feature Upvote, my own software product. And we should remove more.

We've always done it cautiously, waiting to hear negative feedback.

Surprisingly the negative feedback doesn't come. It turns out that if you are careful in what you choose to remove, and if you do the removal in the correct way, it can be a painless process. Most of the time.

But if I did remove a button and got plenty of negative feedback, I'd reintroduce it pretty quickly.

Here's a cautious way to remove something from your app:

1. At first, simply hide the button or setting.
2. Deploy and wait a couple of weeks.
3. User uprising flooding your customer support? Okay, it was the wrong thing to remove. Show the button again. Find something else to remove.
4. Not a peep from your users? Turns out no-one cared or noticed? Now you can remove the underlying code.

​