You spend months - sometimes years - building a new feature. Once it's shipped you celebrate, and move onto the next thing. But product development isn't exclusively new feature development. In this talk, Amy will draw on her experience killing products at high-scale businesses. You'll learn why product development teams should constantly evaluate their product portfolio, some techniques to help you always-be-evaluating, and some advice on how to gracefully deprecate your products.
← All talks 
Build Product Turing Fest 2018
Killing Products
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hello. How's everybody doing? Good. Yes. Great. How many of you are on a team building software products? Okay. That's probably the majority. How many of you have killed one of your features or an app that you've worked on? Okay, a few of you.
So hopefully, there'll be something familiar in this. But the reason that I wanted to talk to you about this is because I think it's a topic that we don't often hear about. When we talk about building products, we talk about finding a product market fit, iterating on the new thing.
But we don't talk about this part of it, which is the emotional journey that you go on. And actually how you feel a connection to the products that you've spent months of your life working on. And how often thinking about something that you've put so much of yourself into, not working out anymore, is the hardest thing to do.
So to introduce this topic, want you to imagine, and probably if a few of you are involved in building products, this won't be too unfamiliar. Imagine that you've spent the last six months building a new feature. It's something that you validated. It's something that customers have been asking for.
You're really excited to get this out of the door, but it's been a really grueling development process. It's been a hard problem for you to solve. You had maybe somebody quit in the process of building this thing. It's been tough. But by all accounts, it's been a success.
You launched your feature. You had users on it. It's something that you and your team are really proud of. In fact, you might even stand on stage at a conference and talk about it. But fast forward a couple of years, and the market has changed.
Your product has probably evolved, and now the feature that you spent that time on that you're really proud of, it doesn't have any users anymore, and there's increasing amount of bugs with this feature, and you don't have any engineers left who know how to fix those bugs.
This isn't too hard to conceive, actually. This has definitely happened to every product that I've worked on, And this isn't technical debt. This is product debt, and I'm here to convince you why it matters, what you can do about it, and some tactics for killing products.
So, I guess just to introduce me, I'm a product manager at Spotify. I work on the consumer experience in the iOS and Android apps. We call it core experience, And I've been there since January this year, so around six months. And at the moment, I have the great privilege of working on podcasts.
So, if you're a Spotify user, you might have noticed that we've been slowly increasing the visibility of podcasts in the app, and this is something that me and my team have been working on. Prior to Spotify, I've worked at a few different companies, from fairly early stage startups scaling those, where the challenge is building an audience, converting them, through to larger media companies where we talk a lot about digital transformation.
And prior to Spotify, I spent the last three and a half years at Twitter, where I was the product manager for TweetDeck, which is Twitter's app for power users and journalists. While I was at Twitter, I was responsible for killing two entire apps, as well as deprecating several features within TweetDeck, and I'm actually gonna talk about one of those examples a bit later on.
But first, let's explore why we should kill products, why I think this is important. So this diagram might be familiar to you. It's sort of a classic illustration of the lean development process, which we talk a lot about. Hopefully, everybody's familiar with. But sort of the first great trap to fall into when we talk about this is only talking about this through the lens of new product development, an iteration of features launching new things.
Actually, this is sort of especially keen because we talk a lot about failing fast in this process. If you fail fast all of the time, if you constantly pivot, your app's gonna be littered with the corpses of your failed features. And what you don't want is your users to be stumbling over those corpses.
The second sort of trap that we often fall into once we've launched something, once it's out there, is to think that this is something that comes for free. Oh, we, you know, it doesn't cost us anything. It's out there. You know, what harm is it doing?
But nobody's using it. You haven't iterated on it for a really long time, and you're probably not gonna prioritize the time to iterate on that thing. It's not a free feature. There's always a cost to software. One of those costs is creating bloat, you know, a bloated feature full of all these stumbling blocks for your customers to come across.
You sort of think, oh, they're out there for free, but there's a lot of things that are gonna get in the way of the core flows that you want your users to complete. Do you know what their core flows are that your users wanna complete?
Actually, that's often the hardest thing to understand. If you've mapped them out, then you should be constantly testing within the holistic flow of your product. Can my users complete the core flows that they're supposed to complete? And I think, again, through the lean development process, we often think just about testing the part of the app that we're developing and not testing the whole product holistically.
So, don't fall into this pitfall. But I guess just a note on this because I think when we talk about usability bloat, often it's easy to confuse that with complexity. Sometimes complexity is necessary. Having worked on an app for power users, then complexity is definitely important sometimes, but even complex products can have straightforward usability.
What isn't okay is if you can't decide what the default behavior should be, so you build three versions of that thing, and maybe hide a couple of them in settings. It's gonna take just a whole bunch of extra time, and users don't ever notice that they're there, and it's just two other things that need to be tested and maintained and fixed.
So, as we talk about this, there's two sort of main criteria definitions of those I'll talk about in a second. So, costs associated with building products and the value that those products bring you. These are the evaluation criteria. So, what do I mean by costs?
Costs can be physical costs. Quite clearly, thing that this feature has a backend, there's some storage costs involved, but actually, even if it doesn't, the thing people often forget about is instrumentation itself, the data processing and data storage associated with that, has a physical cost.
It might not be a lot, but it adds up. Time is usually the hidden cost that we don't often talk about. So, the time that it takes to test this feature when you're developing a new one, the time that it takes to maintain it if something goes wrong, and the time that it actually takes to investigate this thing that you forgot existed and is causing some funny behavior, and nobody knows how it works anymore.
So, you have to spend half a day, half a week investigating it. That just takes time away from the things that are adding value. Usability costs, talked about this a minute ago. Is it confusing? Are users dropping out of your funnels because they don't understand why something is here, and they feel stressed or confused about it, or they just can't complete a flow.
And finally, strategic costs. So a little bit difficult to measure, but the cost of having a feature in a portfolio or an app in a portfolio that isn't adding value is something that definitely needs to be taken into account. So value, there's only two elements to this.
Customer value, does it add value for your users? Is it helpful to them? Is it a reason that they're opening the app to use it? And strategic value. The best kind of value is where both of these things exist in one, but sometimes you need something that's strategic for the business rather than customer value.
Hopefully, it won't be putting people off the process of doing that. So, that's why we should kill products. Let's talk about when. The most obvious one is when it's just the end of a whole product's life, And, actually, this is often more straightforward.
If a product's had its day, then you often sort of know, I don't want this product in my portfolio anymore. It's not necessarily adding value. When I was at Twister, two products that I was responsible for shutting down were Curator and Engage. Curator was an app for journalists to curate tweets, and Engage was an app for creators and influencers to track their Twitter following and measure it.
The reason that you've never heard of those two is why we shut them down. They were detracting from the core value of our business, and they were sort of interrupting our ability to prioritize the things that were adding value because resource is finite.
So, for us, the cost of maintaining them was no longer worth the strategic value that those apps are bringing to the business. Where it gets a little bit trickier is within a product that is adding value, there are parts of it that definitely aren't.
So, how do you know when a feature is past its sell by date? And these are, I think, some of the ways to identify when it's time to make a decision about whether to deprecate. And the first three are things that you will just come across in the process of developing something.
So, there's a bug that you don't wanna fix. This feature is in the way of another better, more valuable feature, or there's literally a security problem with it, and you have to shut it down immediately. These are the three things that are gonna force your hand into a decision of killing a product.
Where I hope to convince you to also consider deprecating products are in these two things. It's no longer adding value to you and your business or your users. Consider shutting it down. Or if it's confusing, then be intentional about it. Don't wait until your hand is forced to consider whether it's time to deprecate a feature.
Okay, so we've come across something that we might want to consider deprecating. Let's evaluate it against our costs. Can't remember them. Physical time, strategic, and usability, and value, customer value, and strategic value. So, the first two, if I could put them on this lovely little chart.
The first two, fairly obvious. If the value to cost ratio is low value, high cost, it's probably a candidate for killing. It's really taking your time, your effort away from the things that truly matter. If it's high value, and it doesn't cost you a lot to maintain, brilliant.
We want more of those. That's great. Where it gets a little bit trickier is where the value's high, but the cost is high. It gets trickier because value shifts. Value isn't constant. So you need to make sure that if something is costing you a lot to maintain, it's costing you a lot strategically, then is it adding enough value still?
And if that value changes, maybe it's time to reconsider it. And the other thing that I really wanna caution you about, if you remember when I said nothing is free, be wary of the features that don't cost you a lot, but that don't add a lot of value.
Because you might think, oh, well, it doesn't cost a lot, so let's put it out there. But it's really easy to end up with hundreds of these things, and if you add all of them together, then the cost is quite high for a lot of low value, and eventually, all those features are gonna be the things that your users are stumbling over.
So, be wary of those. Okay, so we're gonna walk through a couple of examples, like three made up examples of features. These features don't exist. It's just a made up app. And we're gonna evaluate them against these criteria. So the first one is login. Login is a core flow.
The cost of maintaining that feature is quite high. You need to store those login details somewhere. You need to make sure that this service is always up so people can always log in, but the strategic value is high for this. Let's say you're an e commerce app.
People log in. You've captured their email address. They put things in a basket. You can email them to remind them to continue shopping, and conversion is gonna be higher as a result. So, this one probably, even though the cost is high, the value is more than worth it.
The second one to look at is one of those tricky little things that isn't adding a lot of value, but doesn't cost us a lot. So, a color setting. So let's say, you know, the default color setting in your app is light theme, and you offer a dark theme for users.
Well, the value for those users is, you know, if you stare at the screen for long amounts of time during the day, a darker setting on the screen is easier to read. So we have a reason that we have a color setting. Not a lot of people use it because it's hidden in settings, but for those people who do use it, it's valuable.
If I had a pink color setting because I like the color pink, and I thought it would kind of be fun Easter egg to hide it in there, yeah, it's not costing me a lot, but is it adding a lot of value? This might be a candidate to consider killing.
So two fairly extreme examples, but the third one is a little bit trickier. So we have a bookmarking feature in our fake app. It might be that there are some users who love bookmarking things, but most of them never found the feature. Most people won't need it, and most people just don't care.
But for you, there might be strategic value in having this feature. So, you know, it could, in some way, increase conversion, or it could increase retention. The trick with a feature like this is to actually understand, can I prioritize the opportunity to iterate on this and see if we can increase the strategic value?
Can we try and make it more obvious to people? If not a lot of people are using it, then maybe let's change when we introduce people to this feature. If you don't think that you can prioritize the opportunity to iterate on that, maybe it's a candidate for killing.
So, I kind of abstracted it a little bit there with high, medium, and low, but this is literally something that I do in a spreadsheet, which is why it looks like a spreadsheet. You can rank your features according to these different settings, and then literally add up the totals, and then you've got an ordered priority list.
This is something that we do when we order our backlogs, our roadmaps, but consider auditing the features that you have against these same criteria. Alright, so we understand why we should kill products, and we understand when to identify a product to kill, So, let's go kill one.
So, there's sort of five steps that, from my experience killing products, I would encourage you to think about as you go through this process. The first one, arguably the most important one, get consensus internally. Unless you're a tiny company, then often the hardest part of killing a product is convincing everybody internally that this is a good idea, especially if there's people that worked on the product who still feel that emotional connection to it.
So, a tactic that you could consider using is to do a kind of roadshow. Make sure that you meet and explain to all the different stakeholders why you want to kill this product, and to invite them to give their feedback on it. You might discover that there's a consideration that you hadn't realised.
Your mind might be changed by going through this process, but fundamentally, the reason this is most important is to give everybody the opportunity to be heard so they feel like they've come along with you on this journey, and often it feels like a bit of a slog to go through this process.
Oh, I don't want an endless list of twenty new risks that I have to go and address, but honestly, that's part of getting the job done, and so you should feel good at the end of the day being able to say, This was a risk, and this is how we're dealing with it.
The second thing that I'd absolutely encourage you to do, having not done this in the past and knowing that the worst thing is not doing this, is just knowing when a product's gonna be killed from your customer's perspective. So, pick a date, announce that date, and make sure that you can actually meet that date.
So, don't announce it until you know you can do the work. That's another thing to mention with this whole process. Killing products isn't something itself that comes for free. It's kind of like technical debt. It's product debt process. You need to schedule time to kill products to get that time back later on.
So, make sure that it can fit appropriately into your roadmap. The third thing, again, that I highly encourage you to do is not shy away from explaining to your customers why you're killing their favorite feature. Even if the reasons are technical, you can find language to explain in a non technical way why you're making this decision.
Because, honestly, not explaining it is the worst thing. Hand in hand with that, I think, is inviting your customers to engage with you in a dialogue about their favorite feature. When we were killing features in Twitter, we had a lot of very vocally passionate users who loved any opportunity to drop an F bomb towards us.
But this is amazing because it means that their passion is sort of directed, that energy and that passion that they have, we can direct it to something helpful and productive for our process. So, we acknowledge that this is a feature that you use a lot.
This is the reason why we're deprecating it, but please tell us how you used it, why it was important to you, and how else we can improve. And finally, don't forget to celebrate this process and this feature like you would any new feature launch.
Go for dinner. Have a celebration. So, a colleague in my team at Spotify was responsible for shutting down the running feature earlier this year, and something amazing that she did to celebrate and mourn was collect stories and memories from everybody involved in working on that feature and share those around internally.
So, collectively, we could be proud of the work that we did and proud of the decision that we made to deprecate. Okay, that's five steps for killing a product. I'm gonna walk you through an example that I worked on at Twistr. I don't know if anybody uses TweetDeck here, but a decision that we made in, when was it, twenty sixteen, was to shut down the native Windows app for TweetDeck.
So, the reason that we made this decision was because in our decision making points, we came across this as a blocker for a new feature that we wanted to launch. It had taken us about nine months of work to get to this point, and we discovered that it was going to be about two to three additional months to support the feature in this product.
And so, it was a tough decision, but we decided that it was actually better to shut this app down than to put in that extra work and block getting the new value into the hands of our customers. We also thought that we wouldn't degrade the user experience too much by shutting this down.
So, let's go there because they call me a project manager. Sort of response that we got from announcing this, why I use this as an example, is because we actually didn't explain it very well. So, the reason that we were shutting it down is because we wanted to launch Twitter login for TweetDeck and to support it in the Windows app would've meant a rewrite of the Windows app.
We just didn't want to do that. So, we were like, Oh, people won't understand that if we explain it. So we're just gonna kind of just say, Oh, we're just gonna shut it down and not explain why. So I absolutely highly encourage you try and find language to explain to your users why you're shutting something down because they just sort of ripped into us with this.
Although, yeah, what we did do, I think, was something kind of nice through this. So, we went through this process. We got internal consensus. We went on our roadshow explaining to people why we were shutting this down. We introduced a banner in the app giving people thirty days notice.
From that banner, we linked out to a blog post, and in that blog post, we gave people instructions on an alternative that we thought would sort of replace the need for a desktop app. And then we also, within that forum, presented an opportunity to feedback to us.
You might not like this decision, but we want you to tell us how we're doing. We want you to tell us how else we can improve. They still dropped their f bombs at us, but I think this was a really great learning process for how to communicate.
So, just to recap, and these are the three points that I hope that you take away from this talk. The first one is consistently evaluate the feature set that you have. Find a way to understand holistically, can users still use my app? Is the value that we originally created still applicable, or has it shifted?
Secondly, make sure that you find time to do this before it gets too hard and too painful. As you're going through your lean development process, give yourself time to sweep up your corpses of your failed features. Still fail fast, but sweep them up.
And finally, when you do go through this process, just communicate as openly and honestly as you can because trust me, it's the only way to make sure that you continue to build trust in your user base and your customers. So, thank you. Thank you, Amy.