Bootstrapped Founder #38: Killing Features for Fun and Profit

Dear founder,

If you add features to your product indiscriminately, you will end up with a gigantic bloated mess of software. One way to deal with this is to be very careful when deciding if new features should be added. Another rarely used approach is to remove unused and outdated features. Removing the cruft from your SaaS product is akin to pruning a hedge: you will end up with a more recognizable shape and a clearer vision of what your product is all about.

How Customers React When You Remove Features

Here’s the thing with change: there will always be people who hate it, with or without reason. While notorious complainers can be safely ignored, pay close attention to people who react negatively to product removal. Your target customers should be the ones that you delight with your product, and you never know how people use your product in weird ways until you break a workflow that you never expected to be possible. You want to remove a file upload button because everyone drags their files into the browser? There will be that one user who uses their keyboard only. Removing the feature makes the whole product unusable to them all of a sudden.

Make sure never to remove accessibility features because you don’t see the need for them yourself. Impaired users rely on these things to be able to use your product. Build as much accessibility as possible into the product from the beginning.

When to Remove a Feature

In some way or another, every reason to remove a feature from your product boils down to feature creep. Here are a few examples, both with reasons why they should be removed and how they come to happen.

Remove unused features. When customers stop using features, they either found a better solution to their problem or they have a different problem to solve. As a result, unused features clutter the user interface of your product, not providing any value to your users. At best, they are a visual nuisance; at worst, they produce unintended side-effects, confusing your customers by their presence. Your codebase will also show signs of bloat when unused features stick around for too long.

We removed such a feature at FeedbackPanda. It was initially introduced to allow our customers to migrate and amend their data from one product version to another. As some of our customers were rather slow to adopt the new version, we left the interface component in for a long time and forgot about it. Half a year after the last customer finished migrating, we finally removed the feature. While doing that, we figured out that some of our customers had misused that feature to change their data in weird ways that we didn't understand before. Talk about a side-effect!

Remove features that distract from product focus. Sometimes, you build things because you think your customers need them, but they turn out to be misaligned with your purpose of solving your customers' critical problem. Those features can make other features less effective or at least harder to find and use. This is the ultimate incarnation of feature creep. It's what will turn your product into a tangled mess if you don't regularly trim the fat.

Remove features that make the product too complex. Very similar to features that distract your users are features that overwhelm them. Many products have seen their customers churn because they became hopelessly complicated to use. It all starts with the intent to provide more value, but it eventually turns into feature overload.

Remove features that are expensive to maintain. This removal opportunity is often overlooked. Some things that are part of your product may, at some point, cause performance issues or incur higher monetary costs than you're willing to pay. Often, it's easy to engineer and maintain heavy-duty features at the beginning of a business with only a few customers. Examples of this would be heavy background-processing of customer data, complicated imports, or extensive export scenarios. While limiting access to this feature may work, removing it is also an option if it's do-or-die.

Why Does Feature Creep Happen?

Feature creep happens for many reasons, and all come from a genuine belief that, at the moment when you conceptualize and build the feature, it's useful and providing value to your business and your customers. But, of course, just because you believe so doesn't make it real. I have built many features that I felt to be absolutely necessary only to shamefully admit defeat and remove them a few months after launching them.

Here are a few situations where I should not have added a feature but did anyway:

I just wanted to build it. Sometimes, you're only interested in understanding how things work, and you think you need to build it. I did so with the FeedbackPanda invoicing system. What started as a simple part of the application, not much more than a list, ended up being a PDF-generating monster and tax-calculating monster of a feature. In retrospect, that's a rabbit hole I should have never even looked at from a distance.

I just wanted to get and convert a big customer. In a prior startup, I built several features for a prospective customer who promised to sign up if only those features were implemented. Of course, they never signed up even when I had deployed the changes, but we kept the feature in the application because we hoped that other customers could benefit from it somehow. They never did.

I thought it was the one feature I needed to release for things to start happening. This is an example of the classical "Next Feature Fallacy": the thinking that the next thing you do will have the big impact you're waiting for. But it usually doesn't. Usually, it will be yet another attempt at making a big difference and failing. This is a great opportunity to dust yourself off and try again. Just make sure you remove the feature that has proven not to work. Don't keep it hanging around.

There are a number of other reasons that can cause you to build things you shouldn't have:

• "Premature Optimization"-like integrations. You thought you could use this eventually, and you'd better already have it in the product before you need it. Maybe you intend to eventually partner with a service, so you build an integration ahead of time. And then the partnership falls through, and you never need it. Many technical founders then fall prone to the sunk cost fallacy, thinking that since they already invested their time, the functionality needs to stay there.

• You're trying to capitalize on trends. Ever implemented social-media-like functionality even if your customers never interact? I built a Facebook-like social stream with messages and comments for farmers who never took the time to use it because they were too busy harvesting their vegetables. But social media feeds were everywhere, so we just had to have something like this, too. It was not required at all, and completely unused, but we believed that we could pull it off.

• You saw it somewhere else, and it looked rather cool. Founders get inspired by other software all the time, and then build something very similar in their own products. What they forget is that every feature exists within the context of a product. That cool overlay animation you see on a social network for designers will completely confuse your almost technically illiterate users. Try to avoid things that are not essential to your product.

• You needed to release something, and it was quick to build. Sometimes, you feel like you just need to do something. You haven't released a new feature in weeks, and customers have always asked for something simple. It's not on your roadmap, and you didn't put it on there because it wasn't essential, but you know it will only take an hour or two. Now you have wasted your time twice. You didn't work on anything meaningful, and you will have to remove it again in the future.

No matter what your reasons were then, you need a slim and efficient product now. So, trim the fat, and start removing those obsolete features.

Removing a Feature the Empathetic Way

If you want to remove a feature, sunset it. Make a public announcement about the removal close to when people who use the feature would read it. Then, turn it into an optional feature, using a configuration toggle. Change that toggle to default to an "off" state, and measure how many people react to it. Inform them how to re-enable it and how to work with your product without that feature. If you feel confident that removing the feature won't impact a significant amount of your target customers, remove it.

Feature removal has multiple impacts: you can fully remove a feature, slowly wean customers off over a number of weeks, or phase out the feature via options until the last customer has stopped using it.

No matter what speed you choose, the most important thing to remember is to communicate the changes to your users before and after you remove anything. This will reduce friction between you and your customers. It prepares them for an impending change and reduces the likelihood of them getting confused when it finally happens. By keeping your customers in the loop, you're reducing the customer service load you'll have when you remove the feature. Also, once they know about the change, they can look for alternative ways to solve their problem if they were users of the feature before.

Use all the instruments at your disposal to communicate the removal to your customers. Tell them in-app and through an email. You never know where they are right now, and you need them to know both in advance through a thoughtful email and right when they are in the product, best in the location where the feature used to be. Update your knowledge base and prepare a transitionary video that clearly shows how to solve the problem alternatively if ever needed. The more you invest in communicating a feature removal, the less work you'll have on the customer service front.

There Will Be Consequences

Sometimes, you will learn that some features are part of very hard-to-change workflows for some of your users. Removing the feature will cause you to lose the customer in these cases. Sometimes, that is okay if the removal reduces complexity for everyone else. It's a balancing act. Be clear in your messaging, and insist on making the product a distinctive, slim, focused version of itself instead of succumbing to featuritis.

If people ask why you removed a feature they used before, give them good reasons. Customers will understand when you say, "less is more, and this is making the product better." For your customers, the overall usefulness of your product will trump individual features when they have a chance to think about it. They may complain, but unless they cancel their subscription, they will see it as a viable move.

Finally, by talking to customers before you remove a feature, you spread out the haters. The complainers will complain over a few days, sometimes to you, sometimes on social media, but their cries and yells will be sparse and manageable. Much better than when all hell breaks loose at the same time when you remove a feature without telling anyone.

All in all, slimming down your product can have a net positive effect on the business, your customers, and the value they receive. Keep this tool handy when you're doing some business introspection. Not all questions have to be answered with a "What if we build this?"—some deserve a "We don't really need this!"

You can find this article on the blog. I also recorded a podcast episode where I talk more about my experiences with feature creep, removing features, and what not to build.

Links I Found Interesting

I wrote about building my own invoicing system earlier. That was a pretty stupid move, but at least I didn't build my own accouonting system. Mostly, because I didn't even know how that would work. This week, I came across Double Entry Accounting for Developers, which opened my eyes to the thing I always thought was incomprehensible. Turns out it's not. It just needs to be explained in a way that's compatible with my developer brain. If you never understood accounting either, check it out.

Ryan Ashcraft quit his job last July to jump into being an indiepreneur. In his article Learnings From A Year of Being Indie, Ryan shares the FoodNoms story, from ideation through prototyping to the final product. He shares highlights and learnings, and it looks like Ryans journey from passion project to successful product was both instructive and enjoyable.

Nabeel Qureshi published an essay called How To Understand Things, in which he discusses the concept of deeply understanding something instead of just accepting the most obvious explanation. It's a remarkable essay about intelligence, the will to think, context, and intuition.

I found a number of very curious and insightful links this week that are not related to bootstrapping, but are incredible nonetheless: from Harry Eng, the Master Bottle Filler through finding sanctuary from the Northern Ireland Troubles in Street Fighter II arcades to Hügelkultur, a version of raised garden beds. Enjoy!

Bootstrapping Success Stories

Marko Saric of Plausible Analytics wrote an extensive post on How to pay your rent with your open source project. The article offers many useful business models, their opportunities and pitfalls. Since Plausible is taking a bootstrapped approach with a free and open-source analytics tool, they will have to act on their own advice here, and it looks like it's working: the business is at $2,000 MRR already and climbing.

Sumit Kunar of Tresor One reached 500€ MRR with his portfolio tracking application for Stock and ETF portfolios. It looks like he found his audience, and they appreciate his product. It won't be long until we see Sumit reach 1000€ MRR. Can't wait to see that happen!

Stefan Vetter, founder of Friendly, a suite of ethical marketing tools, shares his learnings from growing the business from zero to $1,000 MRR in 94 days. I'm humbled to see that my Audience-Problem-Solution-Product approach seems to have helped him focus on building a laser-focussed product to the point where he has now hired his first employee. Congratulations, Stefan!

Thank you for reading this week's edition of The Bootstrapped Founder. If you like what I wrote about, please forward the newsletter to anyone you think would enjoy it too.

If you want to help me share my thoughts and ideas with the world, please share this episode of the newsletter on Twitter or wherever you like, or reach out on Twitter at @arvidkahl.

See you next week!

Warm Regards from Berlin,

Arvid