When you should consider killing features, even if you love them
A couple months back, I read about Youtube shutting down Stories as they transition to focusing on shorts (see the original Techcrunch article here). This stuck with me, as seeing such a big company decide to shut a new product area down as an admission of defeat made me introspect a bit on why I personally struggle to kill features.
I find it easy to change priorities prior to a feature being complete, but once a feature is out there, it’s like the feature develops it’s own inertia. Even after you realize the feature isn’t critical to your company mission, somehow you still get pulled into fixing bugs, supporting fringe customers who want that feature, and always somehow wondering why this feature comes back to haunt you.
Now we all know that it’s best to think through a feature and why you’re building it prior to actually building it to avoid these problems. Isn’t the goal of product management to only build what you need? But in reality, you’re constantly making decisions with limited information, so you will make wrong decisions. You never really know how a feature will get adopted until you put it out there.
So if it’s important to put things out there to see if they worked, why not just throw stuff at the wall and see what sticks? The problem is that features don’t just cost the company during active development - they also cost the company over time. Once you put a feature out there, you have to maintain it, tweak it, and address customer issues. So if a feature isn’t really serving you, it’s probably costing you.
If features can cost you, should you just kill features liberally? Absolutely not! Shipping things and then killing them shortly after is a surefire way to cause user whiplash. You can’t just ship a feature and decide a month later that it was the wrong thing to do. Internally, it’s also a big morale hit to just throw things away for no good reason.
You don’t have to be in a rush to kill a feature if it’s not costing you
Note that I’m actually saying something a little controversial - that you don’t have to be in a rush to kill a feature if no one is using it and it’s not costing you. That’s because timing is key - perhaps you built a feature too early. That doesn’t mean no one will ever use it! The market might be a bit early, or your customers haven’t adopted your product enough to get to more advanced features yet.
We built a one-off feature for a customer who never converted (don’t get me started). It was a complicated feature to implement, but we implemented it anyway. In all honesty, it was a feature that made sense for others and helped us get around a feature gap, but it probably didn’t need to be implemented right then.
You might think that this feature is a good candidate to kill, especially since the customer didn’t convert! But we didn’t kill the feature. We let it sit there, unused for quite some time, months really. We did this because we knew it was likely someone else would need it.
Now customers use it as a workaround for the feature gap we had, and we would never consider killing it now.
Don’t kill a feature just because you don’t have time to make it perfect
The most difficult thing to do as a product manager at an early stage startup is to scope things down and accept imperfections. The problem is, when you scope a feature down to cover a single use case, users will inevitably want to use that feature for other use cases, exposing feature gaps.
For example, we built a couple views specifically for debugging purposes, but users started to use the views in their usual workflow. And obviously the experience wasn’t optimized for that. In times like this, you might wonder whether or not you should kill a feature that isn’t fully featured enough as (1) it might be embarrassing to admit to users that your product has some significant limitations and (2) if you don’t have time to further augment that feature, doesn’t that mean it’s not important enough to keep?
This is when you really have to stand firm. When you first built the feature, you built it to solve a specific problem within a specific scope. If it is successfully doing that, then it’s doing its job. The fact that users now want to do something net new that is outside of the original scope is a net new prioritization problem. Rather than thinking about whether or not you should kill a feature, you should think about whether or not you want to re-prioritize the follow up work.
If you decide that the follow up work isn’t mission critical, then you simply have to live with the feature gaps. After all, having feature gaps is a necessary evil. Even the biggest, largest companies have feature gaps, so of course you’ll have feature gaps as well as a startup.
So when SHOULD you kill a feature?
I covered a bunch of cases when it would be a mistake to kill a feature, but when should you kill a feature? I think there are two reasons to kill a feature:
it’s not in your core remit and is attracting the wrong type of customers
it’s not driving usage and costs more than it’s worth
Case 1: It’s not in your core remit and is attracting the wrong type of customers
Let’s say you built a feature that was a bit of a hail mary. You heard a request from a customer and thought, well why not? An example I can think of related to my startup is ticketing software integrations - we actually had a competitor start with this as an integration, but it’s not a software offering that our core personas in Growth and Sales typically use.
We obviously haven’t built out a ticketing integration quite yet, but let’s say that we did. And then we start attracting a bunch of users coming to us to handle support use cases, but we don’t actually serve them that well, so after coming for a week or two, they churn.
This is a good case where you should consider killing the feature. It’s simply not worth the effort to maintain and is attracting the wrong type of customer. Funnily enough we probably will build ticketing integrations as we’re hearing our persona request it, but you get what I mean!
Case 2: It’s not a critical feature and costs more than it’s worth
A feature that we built a while back (and ultimately killed) was Salesforce ID syncing. I’m not going to get into the details because it’s ridiculously convoluted and complicated, but we had noticed that some customers needed a solution, and we thought it was worth providing one.
Fast forward a year later, we discovered that it was way easier to just teach customers how to set up ID syncing correctly on their own (without using our solution), and that our solution was complex, hard to monitor, and not worth the maintenance cost. We’ve since hidden it because we simply don’t want people relying on it. When you build a feature and discover there’s a better way to solve the problem, it’s okay to kill that feature rather than having customers stumble upon the feature, fail to succeed, and then ultimately have a bad experience.
At the end of the day, I don’t think killing features should be top of mind for you at a startup. You might have the urge to delete code and clean things up, but when you’re trying to iterate towards product market fit, spending too much time cleaning things up is a waste of time. That being said, investing in bad fit features is similarly a waste of time, so if you notice that certain features are costing you too much, definitely consider cutting them from your product portfolio.