I recently sent out this tweet, judging by the number of RTs and likes it struck a nerve:
I sent this tweet while building a new integration for my product. It turned out awesome, but it’s going to create a lot of changes to our infrastructure, so I have to consider the cost of releasing it.
For me, the real cost of a new feature is not the time and money up front, but the hundreds of hours of support and maintenance it will create in the future.
I’ve been selling products for a while now, so I know all about supporting a feature that wasn’t hard to build. It’s a pain in the ass.
Over the short term a new feature creates a buzz, gives us a boost in sales, and gets our customers excited. But then the support tickets start rolling in.
“Your new feature broke this other feature in my edge-case website environment!”
“This new feature is great, but can it do XYZ also?”
“Releasing your feature caused a super weird bug and I’m not even using it!”
Now you have to hunt down bugs for edge cases you never knew about, add more options for the feature because customers demand them, deal with technical debt from a growing codebase, and on and on.
Sometimes when I’m building a feature I consider scrapping it, even if it’s awesome, because I know what’s coming. The bugs. The support tickets. The endless questions and problems. It’s almost not worth it.
When I can’t decide if I should build a new feature or not, I ask myself a few questions.
How to Decide If You Should Add That Feature
This is the big question. You have to add features to your product, but how do you know when to pump the brakes?
The answer will be different for every product, but here are some things I think about.
Will most of your customers use it?
Remember that a new feature makes your product worse for anyone that doesn’t use it. Most new features should be used by a large percentage of your customers.
If a couple people ask for it here and there, think about all the technical debt you are taking on just to make a small part of your audience happy. It’s not worth it, trust me.
Are you sick of people asking about it?
The folks at BaseCamp are really good at avoiding feature bloat. Here’s a great quote from their book Getting Real:
Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.
If so many people ask you for this feature that you are sick of hearing about it, it’s probably worth adding. For every email you get about it, there’s at least a few more people that want the feature but didn’t email you.
Will it bring in a lot of new sales?
Sometimes we add a feature for internal reasons. It’s a super advanced feature that we think would be fun to use, or our friends would be impressed by the technology. That’s not good enough.
Products need to make a profit, so if your new feature won’t reach a new audience or sell more to your existing audience, it might not be worth adding.
The hard part comes after you’ve picked the low-hanging fruit. You’ve built the features everyone asked for, and created the obvious integrations. At that point you may get an equal amount of requests for different things, and you have to sort the signals from the noise.
You could also do nothing at all.
Here’s an idea: don’t build any new features.
Remember that you always have the option to not build anything at all, and many times that’s the best choice.
A year from now you are going to be so happy that you didn’t build that one thing for that customer that just wouldn’t shut up. Having less technical debt is a freeing feeling.
It’s always a good idea to improve your core product, so why not spend some time improving what you already built instead of building something new?
What about you?
How do you make the decision to add a new feature?
I have a small team, I’m especially curious how you folks on large teams make these type of decisions.