The art of removing features and products

Teams are praised whenever they release a new feature (or product) to their customers. Imagine the internal ‘pat on the backs’ and recognition that occurred when Gmail fully launched dark mode for the mobile app, Figma released multi-account to switch between personal and work design spaces, or Apple announced their M1 chip. Employees on these teams likely felt proud to share something new with the world and maybe even posted their accomplishment on LinkedIn to spread the word and celebrate.

VP of Product and Design, Mixpanel

Neil Rahilly is the VP of Product and Design at Mixpanel. Prior to this position, Neil was VP of Engineering, after working as a Software Engineer and leading Infrastructure Engineering. Before Mixpanel, Neil was the co-founder of Atomic Contacts.

VP of Programs and Partners, Reforge

Fareed Mosavat is the VP of Programs and Partners at Reforge. He was the Director of Product at Slack, focused on growth in the freemium, self-service business. Previously, he led growth and product teams at Instacart and Zynga.

Chief Product Officer,
Eventbrite

Casey Winters is the Chief Product Officer at Eventbrite. He was the Growth Advisor in Residence at Greylock Partners, Growth Lead at Pinterest, and first marketer at Grubhub. He advised companies like Tinder, Hipcamp, Reddit, Canva, and Pocket.

Now, what if teams were honored just as much — or even more — when they successfully deprecated features and products? Arguably, killing portions of a product is one of the most challenging aspects of leadership. Our biases, and several other reasons, encourage us to keep things. Even the most experienced product managers have little to no experience and craft in reverting decisions after a feature has already made it live into production.

“Joining an All Hands meeting to demo a new feature is always going to feel better than coming to the meeting as the grim reaper saying, ‘We killed this feature.’ To change this culturally, you really need to work hard at emphasizing quality throughout the user experience.”

Neil Rahilly – VP of Product and Design at Mixpanel

Even after features or products are deemed to have little to no value, teams keep them around for ages instead of responsibly removing them. The most common argument we hear is, “This [small subset] customer regularly uses the feature and we’ll lose out, if we remove it.” Instead of associating unshipping with the traditional ‘What do we lose?‘ perspective, let’s reframe to a ‘What do we gain?‘ perspective. After all, unshipping can actually improve product metrics.

Through this article, we dive deeper into:

In this first section, we’ll define what it means to unship a feature or product by dissecting:

The cookie-cutter product development process consists of some variation of: (1) define and understand a customer problem (2) scope an MVP (3) conduct an experiment to measure impact (4) roll out the experience fully to the general audience

“The default stance for most product teams is ‘ship everything we build,’ when the default should be more like, ‘only ship what is clearly valuable.’ In practice, the latter is hard to do because teams are rewarded for shipping. Promotions don’t happen for not doing something, and ultimately you want to show impact. It’s hard to explain impact by doing nothing or removing things.”

Fareed Mosavat – VP of Programs and Partners, Ex-Director Product Growth at Slack

What’s missing in the above steps (1) through (4) is what happens after the conventional happy path. Additional steps should include: (5) monitor business and product metrics, as a result of the general release (6) iterate on the release with new experiments (7) evaluate the value of the feature/product on a regular basis

As part of (7), evaluate the value of the feature/product on a regular basis, unshipping should be an option the team entertains. Unshipping is the process of removing a feature or product that has shipped, and is live, to customers. If teams even evaluate the value of a feature/product, the conversation revolves around questions such as,”Why should we keep this feature?” and “What data supports users actively valuing it?” Both are leading questions since they imply the feature is advantageous and needs to be defended. Instead of defaulting to keeping most features, a more balanced approach is thinking through “Why should you NOT keep this feature?” which we’ll cover next.

➡️ Unshipping* = removing a feature or product that is live to customers

*Other names and phrases for unshipping: killing, reverting, deprecating, sunsetting, rolling back, removing, winding down, retiring, and obsolescence

In most situations, ideas form around unshipping as the value of the feature/product are less apparent, compared to when it was initially rolled out. Highlighted below are the 8 standard reasons for why teams decide to kill features/products. It’s often easy to point to one or more of the unshipping reasons below and collect a list of features to kill. But, it is very difficult to actually execute upon unshipping. We’ll cover why in the next section, after reviewing examples.

Slack’s interactive screen sharing feature gained a following among remote-first companies with a pair programming ethos. The feature allowed up to 15 people on a call to have remote control of your screen. Each participant had their own cursor and could type, edit, scroll, click, or code. It directly solved an important problem for a specific audience and these power users really enjoyed the real-time collaboration nature of the screen share.

“Slack ultimately decided to kill this feature. First, it was a niche feature, with relatively low adoption, which was not strategically aligned with the long-term goals of the company. Second, there was a high cost and complexity with maintaining it, especially as we were working through a re-architecture of the front-end.”

Fareed Mosavat – VP of Programs and Partners, Ex-Director Product Growth at Slack

Mixpanel achieved its initial market traction and first wave of hyper-growth as a product analytics tool, starting in 2009. A few years later, an adjacent market need emerged for user communications and A/B testing, based on users’ actions. To fill this gap, Mixpanel launched a product called Messages & Experiments.

Over time, very large, and separate, markets formed around these two product lines. This made the demand for more types of product analysis – Mixpanel’s core competency – immense. Keeping up with Messages & Experiments at an equal level was, therefore, a tall order.

Fast-forward to 2020, and Mixpanel asked itself an integral prioritization question: could they be best-in-class in both markets, if they split their focus? The answer was a clear “no,” so they opted to double down on their core (of product analytics) to best meet user needs and maximize long-term revenue growth for the company.

The “unshipping” involved a pre-announcement a year before the end-of-life date, and included preset arrangements with messaging and A/B testing partners that customers could migrate to.

“When we stepped back, it was clear Mixpanel was building the 6th or 7th best messaging tool. How is that meaningful, if we’re already world-class with our analytics tool? We shouldn’t have been spending the time, money, or people hours to go into other verticals. We were trying to do way too much and couldn’t build for quality for our customers.”

Neil Rahilly – VP of Product and Design at Mixpanel

Free tracking for up to 100k users/month. No credit card required. Unlimited data history and user seats.

Get Started

Now that we have talked about the 8 times a team may unship and examples of unshipping, let’s map out the metrics that can move when killing a feature or product. The positive metrics impact is likely the least intuitive part of unshipping, because most teams have an ingrained mentality around ‘What do we lose’ versus ‘What can we gain.’ In reorienting around ‘What can we gain,’ there are two sets of metrics to monitor with unshipping: (1) Internal – employee and organization related metrics to monitor and (2) External – customer impact.

Across support, engineering, sales, operations, and product, the team should notice benefits around:

“The decisions to sunset parts of the product have made a huge difference across the board. Most notably, our NPS tripled in the last 18 months due to the focus on feature quality over quantity. We also got a nice retention boost and have increased win rates against competitors to a really strong place. Not to mention, there’s also been a decrease in support tickets and support costs. It’s great to see this type of validation.”

Neil Rahilly – VP of Product and Design at Mixpanel

By having more focus and higher quality of core features and products, positive metrics changes to expect include:

As mentioned in the ‘8 times to unship’ section above, it’s relatively straightforward to enumerate features to kill and why. In practice, there is greater complexity in actually taking action to unship. The top reasons for why it’s complicated to unship features or products are below. We’ll describe each throughout this section.

What this is:

You associate some sort of human connection, which is sentimental or nostalgic in nature, to that feature or product. For that reason, it’s hard to immediately understand why it should be removed. Examples of the human connection you may feel include knowing: the engineer who scoped the feature invested a week into planning, the sales rep you’re close with mentions the feature in intro calls with potential customers, or that your cousin regularly uses the product.

Moreover, the human element plays out when there is broader strategic misalignment and employees have conflicting incentives. In particular, teams may feel their feature needs to stay alive to help hit organizational goals. Or, sales reps could be commissioned on selling certain add-ons or features without their pay structure being revisited often enough. If the wrong behavior is being manifested, through the human element, then it’s probably rooted in the wrong incentives.

Finally, the human element cannot be chalked up to silly feelings that can be ignored. People can believe their jobs are at risk or their career will be derailed if a feature is being removed or their product area will be sunset. As people’s fear builds, they are more likely to act irrationally or rely on the human element.

Additionally, the human element isn’t just about the people inside the building who built, sell, support, or think about the feature, as mentioned in the previous three bullets. It’s also about the users who spent their social capital talking about the feature and love it. The more narrow a feature is, the more likely it is that there is a subset of engaged, loyal, vocal power users who care a lot compared to the average user. It’s also likely that these power users create word of mouth loops to bring in additional new users to the product.

The human element – How to know you’re falling into this pitfall:

“Payments plans was a particularly challenging feature for Eventbrite to support. It had a mix of technical and operational issues and was primarily used by consumers purchasing expensive tickets for festivals and conferences. Our company strategy was moving toward smaller gatherings with lower ticket prices. The sales team that had traditionally sold to these higher ticket price event creators were not happy about this change.”

Casey Winters – CPO at Eventbrite

The human element – Some ways to counteract this pitfall:

What this is: Tech, especially venture-backed tech, is so focused on revenue growth over profit growth. This means less attention is paid to long-term growth on a daily basis. Although it’s okay and necessary to be in a growth mode at times and collect quick wins, it also means killing a feature becomes challenging. This is because removing features is not associated with short-term growth or immediate revenue gain, but rather long-term growth.

Short-term growth – How to know you’re falling into this pitfall:

“In early 2019, the Conversion team at Headspace focused on quick wins to the checkout and in-app purchase experience. These fast A/B tests demonstrated movement to the larger org and moved the conversion rate metric incrementally. Looking back, we were attached to some of those quick wins, making it hard to kill parts of our checkout design until we took a more holistic portfolio approach later that year.”

Keya Patel – OIR at Reforge, Ex-Director of Product Growth at Headspace

Short-term growth – Some ways to counteract this pitfall:

What this is:

Benefits are hard to see – High level company goals are often tied to revenue growth and product engagement/retention metrics. The benefits of killing a feature (less code to maintain, fewer support tickets, fewer incidents, UX improvements, more company focus, less context switching) are often diffused. These benefits are misaligned incentives that don’t obviously line up to high level goals.

Carrying costs are hard to see – Product teams think of cost in terms of engineering weeks and development time, but that’s not the true cost of a feature — the carrying costs are. The feature then needs to be maintained. Not just engineering is responsible for this maintenance, but also support, sales enablement, marketing, documentation, hand offs, and all future decision making. Simply put, the complexity is a drag. It’s difficult to measure the carrying costs each individual at a company spends on a feature, especially since the total time is broken into small and unrecorded time increments across teams.

Two sides of the same coin – Carrying costs are often the flip side to the benefits. By reducing carrying costs (through unshipping a feature) you’ll reap the oftentimes masked benefits.

Benefits and carrying costs are hard to see – How to know you’re falling into this pitfall:

“Eventbrite started actively shying away from projects that impacted our listings page because engineers and designers would have to account for old versions allowing for event creators to implement custom designs via HTML. Not only does that mean we are not iterating on one of the most important real estate areas of the product, but that we lose even more knowledge on how that part of the product works.”

Casey Winters – CPO at Eventbrite

Benefits and carrying costs are hard to see – Some ways to counteract this pitfall:

What this is: Our biases point us towards maintaining status quo, avoiding sunk costs, and loss aversion. So, when you reason that there could be a valid reason to unship a feature, there are also several biases easily countering your rationale.

Biases at play – How to know you’re falling into this pitfall:

Biases at play- Some ways to counteract this pitfall:

“We recently promoted a Product Manager who was the undertaker of deprecating features. It was important for us to show the company that the work he did was valuable — in part because it was hard to execute, with all the internal naysayers, but also because it made a huge impact. His unshipping was equally worthy of recognition as adding features.”

Neil Rahilly – VP of Product and Design at Mixpanel

Given the four areas above, on why it’s so grueling to unship, teams take a prolonged amount of time to actually kill a feature. In most situations, they even fall back into not retiring the feature. In these extended unshipping scenarios, teams should be prepared to live in a limbo state and accumulate credit card debt.

Living in a limbo state involves identifying that a feature should be killed, but not moving forward with its removal. Teams think that keeping the feature in the limbo state is fine because it’s not actively causing harm to customers or employees. On the contrary, residing in limbo is causing benign harm through maintenance and carrying costs. In this state, problems that manifest include:

“When debating whether to kill a product, you try to justify keeping it in so many ways. For Mixpanel’s Messaging tool, we told ourselves that the additional product line would improve stickiness and retention. But we were rationalizing. How could engagement marketing features improve retention for a product analytics tool primarily used by product teams? At the end of the day, we were just finding reasons to stall the real decision. This results in confusing yourself and the people around you, who are looking for a path forward.”

Neil Rahilly – VP of Product and Design at Mixpanel

Accumulating credit card debit means you’re collecting more carrying costs. As mentioned in the previous section, these carrying costs are frequently overlooked maintenance costs, such as: incidents, minor bug fixes, latency, support FAQs that need to be added and refreshed, marketing collateral updates, updated documentation for gotchas, and needing to consider the feature in unrelated future situations.

These are just a handful of carrying costs associated with one feature. So, imagine the stockpile of carrying costs across multiple features or products. Similar to credit card debt, the more debt you accumulate, the more overwhelming it becomes to manage and make corrective decisions. In this state, problems that manifest include:

“People come to Headspace in high stress states and we wanted to be a trustworthy tool — which wasn’t always the case as we built up carrying costs over years on the Android app. By late 2019, we faced several complications: weekly incidents, decreasing Play Store rankings, support team frustration, internal hesitation to run Android experiments around old code, and more. Instead of ripping out and reevaluating features sooner, we were caught in a pile of debt. We luckily overcame it in mid 2020 with a major redesign of the Android app, killing some old features along the way.”

Keya Patel – OIR at Reforge, Ex-Director of Product Growth at Headspace

While living in the limbo state and accumulating credit card debt, problems start to fester for teams and companies, including:

So far in this article, we’ve covered challenges with unshipping and the problems that can manifest. To get to the execution piece of killing a feature/product, is a huge accomplishment in itself. Here’s how to set the team up to keep up the momentum with successful sunsetting processes. These approaches are:

The internal portion of retiring a feature or product will most likely be more challenging than the external portion. This is because of the challenges (the human element, focus on short-term growth, benefits and carrying costs hard to see, biases we hold) mentioned in section 2 of this article. Moreover, as more internal stakeholders are involved there is always the backdoor to reverse the unshipping decision when employees are not bought in to the idea. On the other hand, with external processes, there are less options to reverse or drastically change an unshipping decision after the information has been shared publicly with customers.

To successfully kill a feature or product, there are a few sure fire ways to increase the internal chances around unshipping when there’s too many cooks in the kitchen:

Defining the cuisine and identity of a restaurant (like upscale Tex-Mex, Indian, or Vegan) is congruent to having a cogent product strategy. The product strategy is the logical plan for how the product will drive its part of the company strategy. It’s the connective tissue between the company strategy and product roadmap and usually holds for at least 1-2 years.

Having a well-defined and socialized product strategy that can be referenced during internal deprecation conversations is crucial. Without this clarity, internal employees will be able to question and push back during each unshipping conversation. On the flip side, when a thought out product strategy is in place, it should be painless to point out how the feature does not align with the 1-2 year product strategy. And then, there should be a base level of agreement across key stakeholders that the feature does not back company strategy.

“In 2020, Eventbrite decided to focus our strategy on self-service products around smaller, frequent event creators. This made the decisions to sunset website creation and management for creators as well as on-site staff and hardware for large events very clear.”

Casey Winters – CPO at Eventbrite

Most restaurants serve only a handful of options in each appetizer, main dish, and dessert category. This is so they can center their time on cooking a smaller number of higher-quality dishes, instead of having ingredients on hand for hundreds of different selections. Said another way, restaurants spend time on quality of their dishes, not quantity of options.

Similarly, having and holding core tenants within a product culture, like ‘Less, but better’ or ‘Quality first’ seems cheesy, but can actually work. Emphasizing a theme or mantra around focus, prioritization, and quality of product makes it all the more hypocritical as teams continue to keep excess features or products that no longer align with the product strategy. So, referencing and championing a quality-related pillar allows for sunsetting to have purpose in the context of the product.

Free tracking for up to 100k users/month. No credit card required. Unlimited data history and user seats.

Get Started

“Mixpanel used to have a feature for running in-product surveys. It seemed like a great idea at the time, but users were always complaining about how it lacked this or that customization they needed. At the end of the day, we decided surveys detracted from the overall quality of our product, so we cut them. We weren’t trying to compete with SurveyMonkey, and had plenty of opportunity in front of us in the analytics market. Having features our users didn’t love simply wasn’t something we could accept at a philosophical or strategic level.

Neil Rahilly – VP of Product and Design at Mixpanel

As with all major product decisions, there will never be consensus around the conclusion to remove a feature. Accepting this and still moving forward is crucial, especially when it’s the right direction for the product and strategic direction.

It will seem like there are multiple cooks in the kitchen who need to be appeased. One way to decrease that feeling is by declaring a head chef and giving ownership to an accountable decision maker. This can be a product manager, VP of Product, or other functional roles involved in deprecating aspects of the product — for example, the Marketing Manager should be the decision maker for retiring competitive collateral as the company outlook on competitors evolves. Giving and, more importantly, trusting the head chef is vital to move away from needing consensus based agreement.

“I remember when we decided to sunset our Lifetime product at Headspace and only allowed purchases through the monthly or annual subscriptions. There was initially back and forth between the Finance, Product, Support, and Marketing teams on this topic. After the VP Product and VP Finance named the ultimate decision maker, it was much simpler for each team to accept ownership boundaries.”

Keya Patel – OIR at Reforge, Ex-Director of Product Growth at Headspace

After navigating internal resistance to killing a feature, external messaging to customers is the final hurdle to overcome. As customers discover a product or feature is winding down, it might disrupt their workflow and cause frustration if they are paying for and relying on the product. At the very worst, loyal and prospective customers will write in to support, switch to a competitor, and tarnish the company’s reputation through social media. Steps to avoid the worst case, and successfully sunset from a user’s perspective, include:

Similar to being transparent and aligning internally with the product strategy, it’s equally important to share ‘the why’ to users. Be honest about why the organization is pulling away from a feature. Also aim to share the decision making process, evaluation, and tradeoffs that took place behind the scenes for power users and specific segments of users who may be shocked by the upcoming change.

Most importantly, surface what customers should expect going forward. This can take the from of a high-level roadmap that shares what’s on the horizon and how that better supports users and the product strategy. Simultaneously equip your sales, marketing, and support teams to also share a similar narrative for any questions that might come in from users.

“We had conversations with customers in advance, before announcing the wind down publicly. Some were initially shocked with the decision. But, during the conversations, we walked them through the plan so they could actually see how much care we put into it. We also openly showed them our product analytics roadmap so they could see how we were doubling down to help address even bigger needs they had.”

Neil Rahilly – VP of Product and Design at Mixpanel

In terms of messaging customers, this should happen as early as possible out of respect for users. More specifically, be proactive about messaging customers who actively engage with the soon-to-be retired feature/product. There should be a clear timeline with the sunset date and any other milestones that might happen (a milestone example: the date new customers to the product are no longer being shown a feature, but existing customers still have feature access until the final sunset date).

For large product deprecations, companies should give 6 to 12 months, or more, for a customer to migrate to an alternative solution — this was the case when Google+ shutdown. For smaller to medium sized product or feature deprecations, a minimum of a month should be given for users to adjust their routines. During the wind down, remind users of the upcoming milestone (via email, in product notification) so they prepare, especially if they are continuing to actively use the feature or product.

“We announced the sunsetting of our Messages & Experiments product line a full year ahead of time. It was the right thing to do because thousands of companies had campaigns built out that they’d need to switch to another tool. We hoped every single one of them would stick with Mixpanel for analytics, so we made sure to line up deals and turnkey transition plans with our messaging partners. You never expect this type of thing to be without bumps in the road, but there have actually been far fewer than expected. I think the lead time calmed the anxiety and gave customers plenty of opportunity to adjust.”

Neil Rahilly – VP of Product and Design at Mixpanel

The ultimate sign of caring about users’ needs, when retiring a feature/product, is still providing a first-class experience — even if that means the customer goes elsewhere. One way to approach this is to do the legwork and conduct assessments on behalf of users. Use your company’s leverage to:

“Deprecating support for a clients’ website is a pretty delicate situation. Eventbrite had to make sure we gave event creators time to understand the news and provide a lot of support and alternative options for their website hosting and assistance before we actually sunset those features.”

Casey Winters – CPO at Eventbrite

Free tracking for up to 100k users/month. No credit card required. Unlimited data history and user seats.

Get Started

Want to go deeper on evaluating and deprecating features? Apply to become a Reforge member to participate in our Product Strategy, Product Leadership, Scaling Product Delivery and other programs.