I recently sent out this tweet, judging by the number of RTs and likes it struck a nerve:
At this point in my career I understand that a feature that only takes a few hours to build can create hundreds of hours of support and maintenance in the future. Just because it’s easy to build does not mean you should add it to your product.
— Scott Bolinger (@scottbolinger) August 22, 2018
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.
Getting Real
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.
Comments
4 responses to “The Real Cost of That “Easy to Build” Feature”
That’s a great writeup Scott. After creating products for so many years I have the exact feeling. Though I can’t help myself but build or tinker with new things, but what I understood that if you can build it, maybe you just shouldn’t because the pain it creates after that. Making a product is only 20%, 80% is sales, support and everything else.
Ya being a “maker” we like to make new things, so it’s hard to step back and look at the big picture sometimes.
Important topic Scott and you’re right on. We’ve learned hard lessons about exactly this. An additional thing to consider is whether new features might begin to attract slightly different users. We’ve introduced features and integrations before which resulted in entirely new audiences coming to our products. That’s great until we all find out that these new audiences came because of that new feature and the rest of our product is a poor fit. Those users push the limits of our products hard because their use cases are our edge cases.
Essentially, it’s important that the new features don’t just appeal to more people. They must appeal to the _right_ people. Identify the needs of the ideal customer and build for them.
“it’s important that the new features don’t just appeal to more people. They must appeal to the _right_ people.”
Man that’s some good stuff Kyle. You’re smart 😉