Not Enough SaaS Founders Ask This Question…

How do you know when you should kill a feature? Now, I love this question, primarily because it almost never gets asked. Rarely do founders ask themselves whether they should remove a feature because they're spending pretty much all their calories on figuring out what new features to add. And one of the common rationales, even when the idea crosses their head, is like, well, we've already spent the money to build this feature. We've written the code, we've tested it, we've rolled it out to customers. There are a few people using it. Why would I ever delete it? Because it's in there for free now. So we'll come back to that as to why that's a misguided notion. So in terms of figuring out the value of feature, there are multiple dimensions that an individual feature can create in terms of value. Number 1, the feature helps you attract more customers because that feature exists. Number 2, you're able to charge more for the product because the feature exists. 3, you can increase usage of the overall product as a result of having this feature. That means your daily active users or weekly active users goes up. And then finally, but likely most importantly, it makes customers happier and retain longer because this feature exists. So those are the kind of dimensions of value, right? And you can kind of measure, you know, to what degree does this help me attract customers? To what degree, if at all, does it help me increase the, you know, the price? Does it keep customers around? Does it get them to use the product more? Now that's the benefit side of the equation. That's the kind of value a feature might bring to you. Now let's talk a little bit about the costs of those benefits. Now to attract more customers as a result of a feature, you have to tell people about that feature. I know that seems obvious, right? But if you're going to use a feature as a way to pull more customers in, You have to somehow tell them that feature exists. And reality is that getting a potential customer's kind of mindshare, kind of getting into their brain for a fleeting moment of time, is a zero-sum game. What I mean by that is that any time that you spend explaining, promoting, telling them about feature X is time you didn't spend on feature Y or benefit Z or something else, right? So you're only gonna get a finite amount of time with the customer. There's a cost to kind of using up that opportunity to talk about this particular feature. That's thing number one. In the event that you want to charge more or can charge more for the product, odds are there's going to be a need to kind of, if you haven't done so already, have multiple tiers of the product that says, here's a tier of the product that doesn't include the feature. Here's a tier of the product that includes the feature and costs more. And there is a dramatically high complexity cost to when you add tiers of product and when you start to layer things and say, oh, we're gonna do a basic, pro, and enterprise, or whatever you call your tiers. I'm not saying there's not value to that, but I'm saying for this individual feature, if that's one of the kind of flagship things that causes them to upgrade, there is a cost to that. It may be worth it, but there's a cost. Cost number 3 is that although you've written the code, Code is never, ever, ever static. And though you may have written the code to implement the feature, you're gonna have to continue to invest in maintaining the feature to respond to questions and bugs and things like that. So there is an ongoing cost beyond the cost of initial development of the feature. So you need to kind of factor in what's the overall kind of carrying cost for this feature. And it's not just the kind of hosting and infrastructure cost. It's like, what's the actual thing it takes me, how much money do I have to spend as a result of this feature existing. The next cost is around having to teach customers the feature itself in order for them to use it. Now, this could be in the form of online documentation, it could be videos, whatever it is. Customers are usually not going to kind of absorb a particular feature, you know, through osmosis, so they're going to have to somehow be told why this feature is important, how they should be using it, and then helping them use it right in order for the feature to to deliver value to the customer. That has a cost. Now, whoever's supporting your product, now it may just be you, in which case this doesn't apply, but even if you have 1 or 2 people on your support team that are taking customer calls, they have to really understand the feature and have to be taught the feature in order for them to provide support to the customers that are using that feature. And there's a cost to that too. That means every support person you add, there's this incremental additional cost for them to learn this feature. Now it may not be huge based on the complexity of the feature, but it's certainly more than zero. All right, so that's kind of some of the kind of components of cost. One big thing that you have to recognize in terms of the existence of a feature is that when you have a feature in your product, there's what I call a decision tax. And here, for instance, because that feature exists, you're gonna have to make a decision. Do we bundle this feature in with our existing product? Do we put it in our free product if we have one? Or do we create a tier? You have to make that decision for this feature. If we implement our product on a different platform, let's say we have a web product and we're going to launch a mobile version of that product, do I need to then translate this feature into the other platform, into the mobile version, whatever it happens to be? That you have to make the decision. Not only do you have to do it, you have to— even just the act of making decisions like, do we need to do this, has a cost. If you localize your product to multiple geographies, multiple languages, You have to make the decisions like, is this a feature that I'm going to have to invest the time in and do I want to in order to kind of localize it for this geography? Is it kind of important enough? Does it clear the bar? So back to the original question, how do you know when you should kill a feature? The first thing to remember is you have to forget the cost that you've already spent implementing the feature. That's what in economics would be called a sunk cost. That's gone. You can't change that. What you need to ask yourself looking forward is the value that you reasonably expect to get, and that word reasonably is important. It can't just be a pie in the sky thinking. It's like, oh well, if I squint just right, this feature has the ability to kind of triple our customer base. So you have to be rational in terms of looking at the future benefit that you might derive from this feature along those dimensions that we talked about. And then weigh those against the actual costs of having that feature around. And if a feature cannot carry its own weight in terms of the costs are higher than the benefits that we can reasonably expect to get from that feature, you need to consider killing the feature. And one pro tip in terms of kind of retiring a feature or taking it out of the mix, you almost never wanna kind of pull the bandaid directly off. One way to kind of ease your way into it is to gate that feature to say, okay, well, all new customers on the product effective right now, I'm not going to give them that feature. It just won't even show up. We're not going to put out our marketing materials, but it's also not going to be available in the product. This has a couple of benefits. One is you will get a sense for what the actual impact is of that feature not existing for new customers. When they join, are they emailing you and saying, hey, wait a second, I thought you had this feature, or I find this thing is missing. That'll give you a sense before you've actually done the deed. Then after you've seen that and you've seen the data, you can then retire the feature for existing customers based on how ingrained that feature is and what the overall adoption or usage is. You can give them a time window to say, hey, in a month, 3 months, 6 months, whatever it is, we're going to be retiring this feature. You should expect that some number of customers that use that feature are going to be unhappy. That's life in the big city, and you can't kind of keep that. There will always be some people, and often they will be the kind of the vocal minority. But just from a pure business perspective and a pragmatism perspective, you can't carry all features just because there's exactly one customer or a handful of customers that really, really want that feature. It just doesn't make sense. So anyway, thanks again to Mubs for the question. That's when you should kill a feature. Hope this was useful.