April 2, 2018 by Vinko Buble

"We have at least the courage of our convictions to say we don't think this is a part what makes it the great product, we're gonna leave it out, some people are not gonna like that, they're gonna call us names..." - Steve Jobs

Illustration by Taylor Grant

Take a look around the room you’re sitting in. Chances are there’s something there that you never use but haven’t thought to get rid of. We’re natural hoarders, and software development is no different. It’s hard to recognize the parts of your product that you might not need anymore, and removing them feels risky: how can you justify taking away a feature your team has invested a lot in or losing some users of a niche feature? It can seem like a step back, but actually this is part of moving forwards.

Feature Creep: Taming the Silent Startup Killer

Every feature you add increases your product’s complexity exponentially. And complexity is a big reason many new startup launches fail. Removing feature clutter keeps your development fast. With less features, your production system will stay lightweight and inexpensive. Most of all, a focused set of features lets you maintain a user experience that’s simple and delightful.

1. Think Before You Build

When you prioritize building features over research and evaluation, you’ll get stuck working on features your users don’t want or need. Don’t wear out your eraser! Just as a good writer spends much more time thinking than putting pen to paper, you should generally spend more time figuring out the context and impact of a feature than on building the feature itself.

Get to the root of your users’ problem first, before you put a tool in their hand. For example, if you’ve designed a drop-down menu that’s confusing your users, interviewing them will be harder since they are now focused more on what’s wrong with the menu than their original problem, which might require a different solution altogether.

2. Make Feature Removal Part of Your Routine

Feature clutter is a fear-based obstacle more than a logistical one. So before your team or users experience “feature shock”, it’s important to make removing things part of your routine. Make decluttering a routine part of your workflow and not just something you do in a crisis. I guarantee the element of fear will decrease, and you’ll start to focus on the possibilities you can create by cutting underused features.

When removal is scheduled ahead of time, it’s easier to get past the fear of short-term losses and see that the gains from simplifying are so much greater. My advice to engineers and founders I work for is this: the first cut is the deepest—once you make the first cut, the rest will come much easier.

Writers have an expression “kill your darlings”, for when you realize it’s better to cut a clever phrase to improve the flow of a story. Clutter is human nature, and editing is what separates the good from the great. However, innovation-minded development also means avoiding clutter from the beginning. Remember, building and cutting aren’t the only tools in your toolbox.

Illustration by Taylor Grant

Asking the right questions before writing code can help you minimize feature clutter, but you’ll still need to remove features from time to time. So how do you decide which to remove?

3. Let the Evidence Guide Your Decisions

As Facebook honed their algorithmic content feed, they decided to cut the live “ticker feed”, a feature that had been in use since 2011 but had become less useful with upgrades to the main feed. Product analytics can tell you which features are used the least, but you’ll need to contextualize this information.

Your users might ignore a feature because it truly isn’t needed, because it’s not designed the right way, or because it’s in the wrong place. Whatever the case, disabling the feature can give you valuable insight. If no one complains, it might be clutter! But even if they do, don’t just bring the feature back as-is; take this opportunity to explore your users’ problem and see if you can solve it in a better way.

When we neglect our erasers, we end up wasting resources improving mediocre features— resources we could have used to discover better solutions.

Removing features from your product feels risky, especially if you know it will turn away some users, but consider this: how many potential users are you turning away with an overly complex product? You might find that—just like cleaning your house— the space you made by letting something go is more valuable to you than the thing you were holding onto. Here’s the takeaway: practice researching before you build, and make feature removal part of your routine.

The difference between linear and exponential growth is making room for what you do best.