The Art of Persisting Versus Ending Features
Twitter announced this past week it is killing Fleets. That’s after rolling out the feature to everyone just eight short months ago.
For those unfamiliar, Fleets were Twitter’s take on Stories, which pretty much every social media platform have copied from Snapchat over the past few years. Stories (or Fleets, or whatever the flavor) are an ephemeral post that disappears after a period of time, usually 24 hours.
As we’ve discussed on Product by Design (my other podcast), stories make a lot of sense in certain contexts. I happened to think that Twitter was one of those contexts. They make less sense to me in other contexts (looking at you LinkedIn).
Regardless, Twitter has decided to axe the format on its platform. It had given Fleets special prominence at the top of the feed.
So how do you decide if killing a feature is the right move? First, it comes down to your stated goal. Are you achieving what you set out to do? That’s why having a stated goal is crucial, and why I’m a fan of frameworks like OKRs to give you a way to set goals and measure success.
According to Ilya Brown, VP of Product, “We hoped Fleets would help more people feel comfortable joining the conversation on Twitter,” he said. “But, in the time since we introduced Fleets to everyone, we haven’t seen an increase in the number of new people joining the conversation with Fleets like we hoped.”
It’s a difficult problem Twitter is trying to solve, and a laudable one. According to Pew Research, Twitter is not representative of the broader population (something easy to forget for those of us who use it often). Not only that, but the majority of tweets come from a small minority of users.
So Twitter has a goal to get more people involved in the conversation. And the goal with stories (or Fleets) was to do just that. But over eight months, the data didn’t prove out the hypothesis. More people didn’t get involved. I haven’t seen exact data, but I assume that they likely saw super users taking advantage of Fleets while normal users weren’t. Which probably furthered the divide rather than narrowed it, especially given the prime real estate of Fleets.
They also mentioned that usage of Fleets wasn’t high enough. I don’t know what benchmarks they were using or what expectations they had, but their goals had not been met.
Next, how much time do you allow a feature or product to find its fit?
Was eight months enough time? That’s always a difficult question. The Verge believes that it was sudden, and it does feel like a short time. How long should you persist with a feature or an experiment before giving up?
On the one hand, give up too early and you risk missing out on a winning product or solution for your users and your company. If you stick with it long enough to gain traction and adoption, then it may make a huge difference.
On the other hand, you may not have a winner at all. And sticking with something may just be throwing good money after bad. Just because you’ve invested in something doesn’t mean you should stick with it. Especially since there is a cost associated with maintaining features as well as the opportunity cost of having a team devoted to a feature when they could be working on something else.
As you can see, there aren’t many clear answers. There isn’t a science behind sticking with a feature versus killing it. There isn’t a formula or definitive playbook for this. Which is why it is so difficult. Which is why product is so difficult.
In Twitter’s case, Fleets weren’t driving the results they were hoping for. While another feature copied from another company has been: Spaces. While Stories from Snapchat may not have worked out right now, Clubhouse rooms have clearly been a hit, and it looks like Twitter is going all in on Spaces.
Spaces offer some of the same solutions that Fleets do, namely they are also ephemeral in nature. But Spaces are also different. They bring in an audio component, which is a different medium. They also offer the ability for creators to different forms of monetization and interactions that weren’t available before.
To Kill or Shelf?
So do you completely kill a feature, or do you put it on a back-burner and let it ride?
Twitter decided to kill off the feature. This is certainly the cleanest way to do it. No code to maintain or bugs to mess around with. But also no chance that your users will continue to adopt it or find interesting ways to use it.
I’ve done this as well. When a feature wasn’t working, we’ve killed it. It is a very hard decision, especially when so much work has gone into it. It’s easy to get caught up in the sunk cost fallacy.
On the other hand, we’ve also let features ride, even when we’re not adding to them. Just because it’s not actively being developed doesn’t mean it’s not adding value to users and to the business. And we can always come back to it to decide if we want to invest or kill it.
We’ve also done this (and are doing this now). I look regularly at our features, especially ones we aren’t actively developing. Some of them have taken on new life for some of our users, and we revisit them to decide if we should invest in them. And others we actively decide if we need to pull them from the code (which we also do regularly).
So don’t let anyone tell you it’s all or nothing. You have to develop it or kill it. It’s rarely so black and white in my experience. Maybe in theory. But in practice, and out here in the real world, there is a lot of gray area. And that’s where we live as product teams and product managers and designers.
Right or Wrong?
So is Twitter right or wrong to kill Fleets? Without all the information, it’s hard to say. It’s always sad to see interesting features bite the dust. When it’s in favor of better things, I think we can all get on board. The risk is when companies go the way of Google, and build things only to kill them in a few months much to the dismay of all of us who use them. Then we stop trusting anything you do. Experiments are fine, but if everything is an experiment you are going to kill, then something is wrong.
Other Good Links
Creating the Future of Work (article) - You know I’m a fan of reimagining how we work, and this is a long read about just that. “The idea that everything stays the same except for a few changes around the edges caused every incumbent to lose in the face of step-function change. The ideas in this essay might not be the best experiments to run and the suggestions might even sound ridiculous, but whatever you do next make sure to change a lot because employees, customers, and shareholders are all changing.”
Managing Burnout in A Design and Product Career: A Conversation with Carien Moolman (podcast) - Burnout-chronic workplace stress that hasn't been successfully managed-is becoming more and more common. But what can we do about it? In this episode, we talk with experience designer Carien Moolman about her experience with burnout. We discuss the 3 predictors of burnout and what each of us needs to overcome and avoid burnout in our careers. We also talk tips and tricks for avoiding burnout as product people.
AI Designs Quantum Physics Experiments beyond What Any Human Has Conceived (article) - This is my kind of science (or science fiction). Artificial intelligence pushes the boundaries in areas we couldn’t even conceive. “Originally built to speed up calculations, a machine-learning system is now making shocking progress at the frontiers of experimental quantum physics.”