In today’s episode, Steli and Hiten talk about the process of killing features in your product. Steli and Hiten discuss the difficulty tied to killing a feature, but how it can be necessary to simplify your product. Since killing a feature can affect your current clients, they also discuss how to handle this transaction in a way that builds trust. Tune in to find out when it’s time for you to kill a feature, why Hiten believes killing a feature is an brand building opportunity with customers, and how to prevent the need to kill a feature in the first place.  

Time Stamped Show Notes:

  • 00:05 – Today’s episode is about how to kill features in your product
  • 00:35 – Killing features is part of building a great product
  • 01:03 – Hiten re-branded his site to Product Habits so that they could focus on creating better products
  • 01:58 – Steli says that in order to make a product better, it should go through different versions
  • 02:50 – It is hard to kill something that already exists in your product
  • 03:14 – Hiten says it’s hard to kill a feature because there are emotions attached to it
    • 03:43 – An easy way to get over the emotional aspect is to check what is and isn’t being utilized by your user base
    • 04:50 – Make the process objective and easy to discuss  
    • 05:15 – You also have to check sales versus utilization
  • 06:23 – Hiten says that as a project manager, you have to look at data constantly and consistently
  • 07:16 – Steli thinks knowledge is NOT what is lacking in people when it comes to killing a feature
  • 08:19 – There are features that are being used during marketing, but are not utilized afterwards
  • 09:22 – Steli asks Hiten how he handles customers that are vocal about certain features of his product
    • 09:46 – Hiten says removing a feature can be likened to breaking up a relationship
    • 09:55 – Customers can really get used to a feature
    • 10:03 – Offer an alternative to the feature or be open with your reasons to your customers
    • 10:25 – You can build better relationships with your customers because you are letting them in on your decisions
    • 10:44 – If you know why you are killing a feature, you can better communicate it with your customers—thus a brand building moment is forged
    • 11:00 – It’s okay if people leave if they do not like the changes you made
    • 11:15 – Put yourself in your customer’s shoes
  • 11:41 – There are no good or bad reasons in killing features, but it means you are building less into a product
  • 12:02 – Killing a feature meant you built TOO much
  • 12:21 – “There is never a bad reason to kill a feature and, at the same time, you need a good reason to kill a feature”
    • 12:30 – You have to assess the usage of a feature and all the other features of your product
  • 13:20 – Killing a feature will help make the product simpler, easier to use, and more valuable for your customers
  • 14:43 – Steli and Hiten think that killing a feature is NOT a bad thing
  • 15:10 – The better way to not killing a feature is to not build it in the first place—focus and create only what you need
  • 16:14 – Hiten’s tip is to brainstorm objectively with your team about which product or feature needs to be killed
  • 17:04 – Steli’s tip is to be more thoughtful in the building phase and the importance of open communication between the team and customers
  • 18:39 – End of today’s episode

3 Key Points:

  1. An easy way to kill a feature is be objective about it—is it being used or not?
  2. Communication between your team members and customers is crucial—both in deciding what feature to kill AND the conversation you have after you’ve killed that feature.
  3. Be more thoughtful in the creation and early stages of building your product; build only what you need.


Steli Efti: All right.



Hiten Shah: You might get some good rants on this one. Sorry-



Steli Efti: Awesome.



Hiten Shah: … Ahead of time.



Steli Efti: All right, this is Steli Efti.



Hiten Shah: And this Hiten Shah.



Steli Efti: In today’s episode of The Startup Chat we’re going to talk about how to kill features in your product, or maybe we’ll just rant on how fucking difficult it is to kill something once you’ve developed it into existence. The reason why I wanted to talk about this with you, number one is because it is such a big part of building a great product and it’s something that I don’t find … There’s a little bit about it out there, but it’s not something a lot of people think about. Most of us worry about how to pick what to build and how to build things really, really well. You have a big focus now on educating people on product management and you have a newsletter everybody should subscribe to. Give a little shout out to that.



Hiten Shah: Yeah, absolutely. It’s called, and I rebranded. Same email list, but I rebranded my weekly newsletter to really focus in on product. It’s still about SaaS and all that, but I really wanted to focus in on how do you create better products. One, I’m glad we’re doing this episode just because I think about this literally daily now and I know it’s one of the biggest challenges people have, which is basically how do you kill a feature? How do you even decide that you need to do that? It’s one of the things that the best companies are great at it and companies that are struggling, this is one of the big reasons that they struggle in terms of growing their product or making it better.



Steli Efti: Let’s talk about that. How do you even get into how do you decide what to build? There’s one big thing that I have a rant about, and I’m not sure if that’s going to be a separate episode. I’ll let you guide me, but it’s this idea of we’re going to build a feature and this is going to be version one. Then, down the line, we’re planning to make it better and then you do that version one. You decide to build this with the version five in mind in terms of, this is going to be really valuable. Version one you don’t think through it as carefully because you think, “Well, it’s just going to be the quick thing that we’re going to get out the door and then we’re going to iterate on it.” You get it out the door, you never iterate on it. Three years later, it’s still stuck in version one and then version one sucked and it didn’t add enough value. I’ve seen this so many times with other products and companies, but I also saw this with us. We made this mistake where we put things out the door in version one and a year later it’s still fucking version one and we haven’t worked on it the way we wanted to. I feel like that may be a separate thing or it may be related, but I think it’s common knowledge that once something exists in your product it’s so hard to kill it. Let’s talk maybe about … Well, let’s rewind. Let’s talk first maybe about when and how should you even consider killing something and then we can talk about why it’s difficult and how to do it.



Hiten Shah: Oh, man. Okay, this is great. I think it’s super relevant. One of the reasons you end up in this position where you’re not willing to kill a feature is because you invested so much in it early on and then you never iterated it, and so you have this emotion around it. You know it sucks, and you don’t really know what to do about it, and you just keep adding new features because you think, no offense to sales teams, but a lot of times sales teams always want the new shiny thing, so your product builds the new shiny thing. A lot of times product teams just want to build new stuff and don’t actually go back and iterate old stuff, yet lost of users are using the old stuff or not. I want to just give one thought, which is you have to find a way to remove the emotion out of these decisions. The easiest way to do that is basically go figure out what parts of your product are getting the most utilization and the least utilization from your user base. What you do is, it looks like a chart and it’s like top to bottom is 0 to 100% and that’s your whole active user base, so everybody logging in every week, and then each bar is a feature and the percentage of users that are using each feature. That makes it super easy to understand. Okay, is that thing that we built a year ago and haven’t iterated on actually being used by people, or is it not? It’s not to say that if it’s not being used you kill it. It’s not to say if it’s being used you don’t kill it, but it’s more so to help you understand what’s going on. What parts from our product are actually being used by people? And then being able to start the discussion that way instead of starting it in the way of like, “Oh, we launched it. We never iterated it. Let’s go iterate it now,” or, “We launched it, and we don’t now. It sucks. Let’s go kill it.” I like to make it objective and I like to make it very easy to be able to look at and have an informed discussion because there’s a lot of emotion around this topic, especially on product, especially with sales teams. One of the common ones I’ve seen is sales teams sells a very specific feature. They think people are buying because of the feature, but people don’t end up using because of the feature. Yet, it sells well. That’s been a pretty common scenario. Then when you look at utilization versus sales, you realize that, oh, it sells well but nobody uses it. What does that mean?



Steli Efti: That’s so interesting. Yeah, yeah.



Hiten Shah: Then you get 100 more questions which are not emotional, and that’s what I love starting with with any product, especially one that’s been running for a bit.



Steli Efti: Yeah. Remember, I think Intercom has this framework or written about this where their prioritization is you’ve built something new, or you take existing features and then you, step one, are trying to make more of your users use those features, and then step two is make these users use these features more frequently. Then all you do, you think about new things to build, so kind of taking what you have and making sure that all your users get value out of it and then they get more value out of it. One measurement of that could be frequency. From your experience, you’re talking to so many different startups, how many startups actually really look at these usage numbers and know what parts of the products are being used, how much?



Hiten Shah: Yeah. As I’ve dug into product management a lot lately, and how people do product, build it, iterate, you’re basically … I have a line which is, you’re essentially not in the top 1% of product managers unless you’re actually looking at data. One lens on data is this exact lens. This is probably the most important lens to start with because there’s no tool that’s going to tell you what percentage of my users are using what feature. It’s usually a database call and things that are a little tougher to get to, and you might not even be tracking that properly yet. I think it’s the number one thing I would do on any product that exists and has at least hundreds of users, is go figure out what parts of the product they’re using and what parts they’re not. You can break that up in all different ways. You can probably hack it together using Google Analytics, which is what I’ve done before to quickly get to it. But basically, the top 1% of product managers look at data all day, every day, and it’s only 1%. Most people are making gut calls in product today.



Steli Efti: Yeah. That’s crazy, right? This is one of these cases where I feel like it’s not that the knowledge is lacking. People know they should be doing this, but then there’s all these emotional reasons or whatever other reasons why they’re just not doing it right now, right? Let’s say that you look at the data. You take what you said, which is gold, which is let’s take the emotions out of it. Let’s make this more of a rational discussion, and let’s have information that is informing our decision making, versus just our own biases. Still, I find that, just like you said earlier, just because a lot of people use it doesn’t mean that you shouldn’t kill it and just because nobody’s using it doesn’t mean that you should kill it, right? Then there’s always the argument, the problem is that once you have a feature out there there’s going to be always people that use it and love it. Not always, but most of the times there’s always some customer that will appreciate something just the way it is, even if a lot of other customers don’t care for it. Then, it becomes … It might be … I didn’t even think about sales because that’s not a challenge that I see day in day out with my team, but you are so right. Often, sales teams, certain features sell well in the marketing or the sales part of it, but they’re not being used well afterwards. It’s just something that the customer thinks, “Wow, this is a compelling reason for me to buy this,” but then when it’s actually time to use these things they never do. I’m even thinking about the flip side of that, which is more of the account management or success team and support team. People that know the current customers really intimately and they know these super passionate customers that are really attached to a certain part of the product, and then whenever it comes time to decide to move the product in a different direction that might mean that we should leave a certain feature set or even kill it, they become these massive advocates internally and politically against it because they’re like, “I know that a lot of our customers love this,” or, “I have at least five customers that they would cancel immediately if we took this out.” How do you deal with that championing … How do you deal with it that you will have … Or in certain products that maybe are not B2B, you have these end users and if you take something away they get on social media and they rant and it becomes this big public perception thing where, oh shit, we killed a piece of a product that all these users loved and they became really outraged about it. How do you deal with taking things away from customers and the response that comes with it, the outrage from users or the internal outrage from your employees, your team members?



Hiten Shah: Yeah, it’s kind of like asking how do you break up with somebody. It’s not that extreme, but it’s close, right?



Steli Efti: I never thought about it that way.



Hiten Shah: Yeah. Some founders … I mean, not founders. Some users, customers, get really used to a feature. One, it’s communication compassion at the end of the day. If there’s an alternative to it or explaining your reasoning behind it, being able to address their objections to why you’re killing it, or just being honest. It just depends. Really, if you know why you’re killing the feature, why not share that with the customer as openly as you’re willing to, or as openly as you can? Because look, those are moments that I call brand building moments. Those are moments where you can actually build a stronger connection with your customer because you’re letting them in on why you’re making this decision, like, “Hey, we can’t support this feature anymore. It costs us too much. We have to move it to the paid plan, or we have to just kill it. We built it badly,” or whatever. Just be honest. I guess my biggest answer is if you understand why you’re killing it, you should be able to figure out a communication path that allows you to actually make it a brand building moment and make it so that the people who are going to stay with you stay with you. The people who aren’t because they love that feature, but yet you don’t want to support it anymore, they’ll leave and that’s okay. People have to get good with that. Another thing is communicating early about you doing this and giving them time to move the data over, do this or do that, those are the kind of things that can be really helpful. The easiest trick, just like with many things, is just put yourself in their shoes and figure out what would be the best thing you can do considering essentially you’re breaking up with them.



Steli Efti: I love that. The empathy part of it and also the breaking up part of it are both brilliant ways of thinking about this differently. Now let’s get to the core of the question, which is what is even a reason to kill a feature? What’s the best reason and what are bad reasons to kill a feature, kill a part of your product that exists today?



Hiten Shah: I don’t know if there are any good or bad reasons. I love when people kill features. It’s just like-



Steli Efti: Why do you love it?



Hiten Shah: It’s just one of my favorite things because it means that you’re going to build less. You’re going to have to support less in the product. It also means there’s probably a problem with your product development and your engineering because you’ve built too much. If you need to kill a feature, you’ve actually built too much. It’s almost like point of reflection where you can actually double down on improving processes, improving your thinking, improving your research methodologies, not letting engineers or product people just build whatever they want with no justification. To me, I feel like there’s never a bad reason to kill a feature. At the same time, you need a damn good reason to kill a feature. I know that sounds super weird, but I look at it like if no one’s using a feature you probably want to kill it unless it’s so important that you need to make it better because everyone in the space has it and it’s just a feature you need. Then you’ve got to really think hard. Should we make that better, or make other parts of the product better? Again, it goes into all these debates and it’s very contextual to your features, your product, your point of view, your opportunity. Really, I haven’t found a category in a business that’s like product because it’s the one that touches the customer more than any other piece of a business, to be honest, even more than marketing, because you’re touching the customer. They have to use the thing. And, it’s the one that has the most indecisiveness in business, and it’s also the one where there is the most amount of confusion of what should I do, and why should I do it? It’s very hard to say, “Hey, these are good reasons. These are bad reasons” because, again, killing a feature enables you to make the product simpler. It enables people to use more parts of the product that are more valuable for them when you do it well. I don’t know, it’s kind of hard, dude. I’ve killed a feature that’s been really popular just because it made no sense to support it in the product anymore because it was killing our servers and it was costing us too much. When we did a profitability analysis, we realized that, oh my God, this is the thing that’s making our AWS Amazon bill so high. Things like that. Again, you got to really dig in. It’s data.



Steli Efti: You know, well let me wrap this up with this question, though. Everything you said makes perfect sense, and then it makes me think, “You know what? Is there even …” When a company kills a feature in a product, usually it points to some level of thoughtfulness at least, or self-awareness. They realize that something is not being as valuable as they thought or that something went wrong in their product development. Then I was wondering, “Can I point to examples where killing features was thoughtless, where a company was killing features because it seemed cool?” I couldn’t come up with any example where I’ve seen a company take away things from their core product in a way that seemed very bad, but maybe there are. Have you seen any of these? Is there any bad examples of killing features? Maybe it’s such a healthy thing that almost nobody wants to do that. The ones that do, it’s almost always a positive thing but I’m not sure.



Hiten Shah: Yeah. Again, never seen it as a bad thing once the team gets to the point of conviction of doing it and gets through every team member that doesn’t want to do it.



Steli Efti: That’s the tough part. I think that also goes to, ideally, you want to set things up so you don’t have to kill features, so you build things with enough thoughtfulness, enough data, enough iteration that you don’t have to constantly have this massive list of things that you need to consider killing in your product, right?



Hiten Shah: That’s the better way. It’s preventative.



Steli Efti: That’s the better way of killing features, is never building those that you might have to kill. For most companies I would assume that they might get to that point, but usually most companies, most product teams, will not start that way without a lot of prior experience of making some mistakes, at least, and rectifying them. I love that we were able to get to that point. Let’s wrap this episode up with a tip from you and a tip from me, old-school style. We’re not always doing this anymore like we used to in the early episodes where we always ended up with a tip, but to wrap the episode up, what’s your top tip that you want to still share with people when it comes to killing features in a product?



Hiten Shah: Yeah, that’s great.



Steli Efti: Putting you on the spot, bro.



Hiten Shah: I don’t think a single product exists where you couldn’t kill a feature. I don’t think there’s a product on the market that exists where you just couldn’t kill a feature. So find a way to have a meeting and just say, “Let’s just not judge anything right now and just brainstorm.” This is my tip. Brainstorm with your team without judgment. Let’s make a list. Everyone just shout out what features should we get rid of, and make a list. It’s likely that the one that everyone thinks you should get rid of, that’s the one you need to dig into first and figure out what’s going on with it.



Steli Efti: I love that. That’s an interesting way of going. Who knows what’s going to happen if you just let everybody shout it out? Maybe everybody says the same thing, just because everybody intuitively already-



Hiten Shah: I say shout it out because it’s really hard to get people to talk about this.



Steli Efti: It’s so true. All right. I think that my tip is going to touch on a bunch of the tips that we said before which is understand that if you believe that there’s things in your product that need to be killed or that the team needs to be starting to track a lot more what the usage of certain features are and be more thoughtful on what to build or not to build, on any of these things you need to realize that it’s going to be all about communication, right? At first it’s about internal communication and taking the emotion out of it and then once decisions are being made it’s going to be all about external communication, what you said, the emphasis of it and the empathy of it to the customer. I think that a lot of times with this, people, they’re so convinced of their own opinions that they don’t consider how to communicate those opinions and get by, first from the team and then later on from the broader market of customer base. Spend more time thinking about communicating why you think things should be killed in the product. How can you back that up? How can you get people to look at that data on your team? How can you communicate that in a way that’s rational and not impulsive or emotional? Then, once the team comes to some kind of a conclusion, maybe everybody shouts out in a meeting the one feature everybody deep down knew is the thing that needs to be killed in the product. Even if you have that level of instant alignment within the team, then ask yourself, “Where will potential misalignment happen? Is it maybe with investors? Is it maybe with customers? Is it maybe with the press? Maybe somebody picks up that you’re killing this and makes a big press story about it.” Whatever that is, just think about the communication part. I think the communication part is a much bigger component to this in this decision making cycle and where the friction happens and frustration happens than people realize.



Hiten Shah: Love it.



Steli Efti: Awesome. This is it from us from this episode. We’ll hear you guys very, very soon.



Hiten Shah: Bye.