The long term cost of features
Every feature you build is a trade-off.
You are trading customer benefit for 1) the effort to build the feature and 2) the long term costs of it existing.
In my experience, while the effort to build a feature is often taken into account by product teams, the long term costs are often unaccounted for — and this leads to making bad trade-off decisions.
This happens because long term costs accumulate over the years that your customers use your product, and the efforts of your team to support and maintain it. This, in comparison to build costs, makes them hard to measure and easy to discount.
The problem is that your long term costs often outweigh build costs because they keep accruing over the lifetime of your product, and scale with the size of your product and company, as I will show below. So by not factoring them into decision making, you will likely end up building features that are bad trade-offs in terms of cost vs. benefit.
By improving your understanding of long term feature costs you will increase the chances of this not happening. Which means that you’ll be more biased to building features that provide a huge customer benefit and easily offset both the build and long term costs.
Here are some of the things to keep in mind when considering additional features.
One more thing to maintain
Every time you agree to a feature, you’re not only agreeing to build it, but you are also agreeing to support it for the lifetime of your product.
The reason that this will be costly is because software changes a lot. Your feature might be working perfectly the day you launch it, but your work is far from over. You will constantly need to update it for the life of your product to ensure it is compatible with all future changes.
Over the long term, this is where the majority of your time investment of your feature will come from. This is because your build cost is fixed (once it’s built, it’s built) but the time you spend updating your feature will grow indefinitely throughout the lifetime of your product.
Example: Your product is a point of sale app. It allows your customers to sell their products in person. After many customer requests you decide to build a tips feature.
Let’s take a look at the amount of surface areas a feature like this would impact. For starters, your team would first need to add additional screens and functionality in your checkout flow, update receipts to correctly show tips (email, SMS, printed etc.) and update transactions summary pages to do the same. But what about exchanges and returns? They need to work with tips now as well so you’ll need to make changes to those flows. What about reports? Your customer will need to report on their revenues so you’ll need to make some changes there as well. And settings? You’ll need to add a discoverable section in there too.
Now, let’s assume it takes your team eight weeks to complete all of these changes. This is your fixed time to build. But going forward, anytime there are changes in the checkout, receipts, exchanges, returns, reports, or settings sections your team will need to update the tips functionality to ensure compatibility as well. This could mean updating dozens of test cases, rebuilding entire parts of the flow, or who knows what. This is where your long term maintenance cost will come from.
A great way to account for this cost is by asking yourself and your team: how much work will it be to support this feature as my product changes? Even this short mental exercise will go a long way to better understanding the real cost of the feature you are considering to build.
One more thing for your team to learn
Similarly, once you build a feature, it’s also now your responsibility to ensure that everyone that supports it knows what it does, why it exists (ideally), and how it works.
Let’s assume you have a five hundred people on your support team and you built the aforementioned tips feature, and an information package and documentation has been sent to the team. Now, let’s assume that together with context switching and reading it takes each of your support reps about twenty minutes to absorb the information. That is 20 x 500= 10000 minutes = 168 hours of company time just to get your support team up to speed. That’s over four weeks of time for one person.
On the engineering side, let’s assume that a hundred engineers will come across the feature in the source code over the course of its existence. Investing time to learn about the feature will be necessary in order to work on the area of the product, so let’s assume that this takes two hours of everyone’s time — this of course would vary widely depending on the nature of the feature — but, even at two hours, that’s 100 x 2 hours = 200 hours = 5 weeks of development time dedicated to just learning about the feature.
Regardless of the size of your company, the success of your product will depend on your team maintaining high context of what it does and how it works. Every feature you add to your product will make this a little more time consuming. This cost will be reoccurring as your support team grows and changes and will easily surpass your build costs in the long run.
One more thing for your customers to learn
I left this one for last, as it affects your customers rather than the team that maintains your software, but, it can often be the most impactful.
New features not only can make your product harder to maintain, they can also make your product harder to use.
“Every additional feature is one more thing to learn, one more thing to possibly misunderstand, and one more thing to search through when looking for the thing you want”.
Assuming your feature has a visual component, it will be one more thing that your customers will need to look at and decide on whether it is useful to them. This will add to the cognitive load required to use your product, which in short, will make it more mentally taxing to use.
Cognitive load is the reason using an apple tv remote is nicer to use than using a regular one. Even if you don’t use every button on a regular remote, just by them being there, they make your brain work a little bit harder to acknowledge and navigate around them to get to the button you want.
You can get away with a few extra buttons, but in general, you want your product looking a lot more like the apple remote than the other one.
Always factor in the additional thinking that you’re forcing on your customers to take on before adding a new feature to your product. A great mental exercise to ask yourself and team to uncover this is: how is my feature affecting the customers that will not use my feature?
The actual cost of features
You can almost never win your market (at least in enterprise software) without building a ton of features into your product. So my intent is not to dissuade from building features, but to caution against building the ones that may end up costing more than the benefit they provide.
In summary:
But rather:
This knowledge will enable you to make better decisions when deciding on features and ultimately means you will say no a lot more. This is a good thing. Because it will allow you to focus on the features that will return significantly more value than what they cost to build or, better yet, improve the ones that you already support.
