Upsides to Unshipping: The Art of Removing Features and Products

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.

Casey Winters is the Chief Product Officer at Eventbrite and co-creator of the Reforge Product Strategy, Retention + Engagement, and Growth Strategy programs. Previously he was the Growth Advisor in Residence at Greylock Partners, Growth Lead at Pinterest, and first marketer at Grubhub.

Fareed Mosavat is the VP of Programs and Partners at Reforge and co-creator of the Reforge Product Strategy program. 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.

Keya Patel is an Operator in Residence at Reforge. Previously, she was the Director of Product Growth at Headspace and a Product Manager focused on Growth & Monetization at Dropbox. She has expertise in subscription models across B2C and B2B.

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.

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:

The 8 times teams decide to unship
Why it's grueling to unship
The problems that manifest, while avoiding killing a feature/product
How to successfully sunset (internally at an org, externally to customers)

Why should you NOT keep this feature?

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

The typical product process and where unshipping fits in
The 8 times teams decide to unship
Examples of unshipping (from Slack and Mixpanel)
Metrics improvements, from unshipping

Your product process is missing some steps

The cookie-cutter product development process consists of some variation of:

Define and understand a customer problem
Scope an MVP
Conduct an experiment to measure impact
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.

The 8 Reasons To Unship

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.

Each of the illustrated reasons are equally good, and valid, reasons to unship. Typically, features that lack strategic alignment are the most important to identify and to sunset.

no longer aligns with company strategy and direction
example: Dropbox's 2014 foray into photo sharing, through their Carousel product
under delivers on value to customers, with too many issues or not being intuitive
example: WhatsApp's 'Delete for Everyone' chat message feature has unintuitive limitations: all parties need to be on the most recent app version, the app may not actually be able to delete the message, photos/videos will not delete, and recipients see a cancelled sign to indicate a message was deleted by the sender
has naturally diminishing returns
example: Instagram event stickers (for getting vaccinated, Pride) are posted to Instagram Stories by each user 1-2 times at most since the associated event can be ephemeral
engages only a small subset of users
example: Slack's remote control screen sharing, which attracted pair programmers
solves a customer problem that was important, but is no longer significant
example: Apple launched the butterfly keyboard in 2015 to provide thin, stable keys for typing and thinner laptops. Since then, customers voiced the thin/stable nature is not what they're looking for, over the quality of typing experience.
is competing with another feature that better solves for the customer problem
example: Headspace's Sleep music (musical tracks) versus their Sleepcasts (bedtime stories, which includes ambient sleep music)
works for other products, but not this product
example: Facebook introducing avatars, seeking to mimic the Bitmoji and Snapchat integration
has exorbitant technical costs with maintenance
example: Twitch tipping streamers through a system of "cheering" called Bits. Users can fund their Bits account through PayPal or Amazon Payments. This involves platforms that support payments/cash outs, social currencies, integrations, and gamification.

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)

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.

What metrics your team will notice internally...

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

Decrease in support tickets and support costs related to the deprecated feature, especially if it was a feature that was buggy or contributing to significant technical costs
Decrease in pager alerts (incidents) for engineering team since the feature/product is removed from the code base
Decrease in data center costs due to less/no information about the feature being stored
Decrease in latency times as a result of fewer requests related to the feature being made to the server on loading state screens or in the background, therefore allowing a user to their desired experience faster
Increase in win rate against competitors, by having more focus on core product areas instead of being an all in one — and hard to explain — solution
Increase in retention over time from bringing in more users for the right reasons (the core features and products) versus things the product does not serve well (the things that are unshipped). These higher qualified users are therefore more likely to stay around for longer.

"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)

...and what your users will tell you

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

Increase in product's NPS due to users having a clear use case the product solves for, while also not having superfluous bells and whistles that create confusion
Increase in Twitter sentiment similar to increase in NPS, where customers write fewer negative complaints and sentiment moves to be more neutral to positive
Increase in app store ranking similar to increase in NPS, but can also be combined with a more performant app (internal metric) with more intuitive features or product design as a result of the product being less bloated
Increase in organic acquisition through marketing channels such as word of mouth or referral. This increase comes from anchoring the messaging on a smaller set of things, that really matter, which can also aide in paid acquisition.

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.

The human element
Tech focuses on short-term growth
Benefits and carrying costs are hard to see
Biases at play

The human element: Feeling sentimental towards the feature

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:

Over indexing on the opinion of those closest to the feature (for example: the product manager who led feature creation, the marketers who use the feature as a value proposition)
Falling into the power user trap
Personifying the feature by reliving the nostalgia of the initial development process and team
Thinking, "What would [this person] think, if they knew we were considering killing this?"
Incentives are based on shipping meaningful features that can last forever (for example: sales teams' comp structure is directly tied to specific feature add-ons)
Employees routinely ask about layoffs and job security in private and public forums

"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:

Reduce the emphasis - Write out all the qualitative and quantitative information you have about the feature. The human element should be just a single piece of the full picture. Prioritize the bits of information that are most important (for example: strategic alignment of the feature should out rival the human element).
Flattery - For the people who are apprehensive about killing the feature, use flattery. The time they've spent on the feature to date is enormously appreciated and respected. Explain to them that, as humans, our most valuable asset is where we spend our time — and you greatly value their time and brainpower. Now, hypothetically speaking, what opportunities could open up if you could give them some of that time back?
Reassurance - Assuage fear around employees losing their job or their work not being valued, as a result of deprecation conversations. Talk through how important and respected this decision is. Also, mention new opportunities that will open up (as a result of sunsetting) which should validate security, stability, and career trajectory.

Tech focuses on immediate revenue growth, but removing features is associated with long-term growth

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:

Weekly and monthly business and product reviews are solely talking about short term (revenue or engagement) strategy. Profitability and multi-year planning only comes up at the investor or board level.
Roadmaps are developed around 'quick wins' encouraging immediate, incremental movement in metrics. Multi-week product features are usually deprioritized.
Product managers and business leaders are asked to tie every idea to a revenue value

"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:

Surface long-term growth - Create opportunities for the company to discuss long-term (2+ year strategy). This can be through company-wide show and tells or roadmap reviews. From there, the operating teams should consciously set milestones to monitor growth along longer horizons, which is not always as apparent in day to day.
Celebrate non-revenue related wins - Normalize thinking about longevity and durability. Share celebratory messages for initiatives that cannot easily be quantified in revenue value. This includes pull requests that eliminate hundreds or thousands of lines of code, a switch to a new vendor that helps reduce downtime, or Accounting closing the books within 2 business days of month end instead of one week after month end.
Portfolio approach - In roadmap planning, make sure that 'quick win' experiments are coupled with medium/long term bets, which can allow for step-wise changes in performance metrics. These medium/long term bets should take up at least 20%+ of the roadmap. Using a portfolio approach can prevent teams from merely producing quick wins, which in turn proactively prevents more easily killable features. Make sure the leadership team is bought in to this diversified approach that can allow for sustainable growth.

Benefits and carrying costs are hard to see, since the 'cost' goes well beyond number of engineering weeks

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:

The benefits of unshipping a feature are not discussed or superficially mentioned. Instead, there's an amplified concern with 'what ifs' (what if we lose X customers, what if a news outlet picks up this deprecation and it's bad press, etc).
Performance and operational metrics are not at all baked into company level reporting. As examples, there will not be goals around support ticket volume or incident response time.
Tech debt and maintenance conversations are siloed in to engineering and dev ops teams. Product managers, designers, and other stakeholders do not acknowledge fragile areas of the code base or development cycle, when researching new features.
Product managers would make a completely different decision and engineers would execute in a completely different way, if they didn't have to account for a legacy feature.
People across the company put in unrecorded 'end of day time' into the feature through bug fixing small issues, helping the support team answer questions about the feature, or documenting nuances.

"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:

Performance and operational metrics - These metrics are established and have leadership advocates who understand the impact of monitoring these non-revenue goals. Additionally, there can be maintenance metrics that do not improve in a traditional way. For example: X days since last critical payment method processing failure or X untested pathways due to errors afters nightly automated tested.
Transparent tech debt - Product Managers are asked to attend tech lead and engineering specific conversations, to understand areas of tech debt or underlying performance enhancing improvements. Alternatively, Product Management and Engineering partners consciously and regularly surface and address tech debt and maintenance costs in their conversations, without simply moving on to discuss new development areas.
Document carrying costs - Spend no more than 15 minutes to identify who is involved in upkeep for a feature. Then ask each individual for rough timing of time spent per week/month in thinking about that feature. By gauging the overall time spent at the company on a feature, you'll have a better idea of context switching and prioritization against other initiatives.

Biases at play overshadow underlying thoughts

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.

Maintaining status quo leans towards keeping the feature as it is currently, to avoid change in workflows or unpredictability resulting from removing a feature.
Avoiding sunk costs means continuing to keep the feature due to all the time, thought, and energy that already went into the feature — admitting it's necessary to kill the feature would mean defeat and a sunk cost in the original feature investment.
Loss aversion is the preference to avoid losses, rather than acquire equivalent gains. More simply said, this is the sentiment that it's better to not lose $50, than to find a $50 bill on the street. In the case of product teams, they don't want to incur losses. The perception of a negative outcome, via sunsetting a feature, outweighs the newfound time to explore the next feature.

Biases at play - How to know you're falling into this pitfall:

Instead of viewing change as an opportunity for growth and learning, the team views change as an unproductive nuisance
In relation to the feature, teams use phrases like "that's the way it's always been" or "historically, that's how we've done it," instead of looking at it with a fresh pair of eyes
You dwell on effort the team put in to the feature in the past, instead of balancing it with current opportunity costs
It's hard for team members to verbalize what could be improved about the feature or what mistakes were made in the initial rollout, since they were intimately involved at the outset
Experiments that did not yield a positive result are brushed under the rug as failures and losses, instead of being viewed as equal learning moments yielded by winning experiments.

Biases at play- Some ways to counteract this pitfall:

Beginner's mind - Instead of being complacent, introduce new employees to the feature and ask for their unbiased input. Or, ask someone close to the feature to imagine they were the Head of Product and what they would be doing differently. How would they stack rank each feature's impact to customers and the business?
Opportunity costs - List out the opportunities and initiatives that can be unlocked and resourced, if a specific feature is killed. Consider the additional optionality the team gains against the perceived loss.
Promote the unexpected - Foster environments where employees can challenge their biases and execute on unshipping. One way this can be demonstrated is through career progression. Promote employees who contradict commonly company-held beliefs, are not complacent, and are disposed to view work objectively to allow for unshipping.

"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)

Limbo & debt: It only gets worse when you wait

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.

Limbo state = the feature should be killed, but the team doesn't move forward with removing it

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:

Product becoming bloated - A classic jack of all trades, but master of none situation
Employee confusion - Uncertainty about company strategy and decision making, caused by not determining the fate of a feature/product
Decreasing user sentiment and retention of customers - Customers don't know where to direct their attention within a product. Should they still use a feature, that is not being updated / buggy? Should they use other features or alternative products to compensate?

"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)

Credit card debt = the more carrying costs accumulated, the more overwhelming to manage and make corrective decisions

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:

Slower development times - Engineers have to work around kryptonite code from past features, which should be unshipped. Or, developers have scope creep since they did not account for the complexity involved with how an older feature was set up.
Higher support and operations cost - Incidents, 911s, security issues, and other obstacles related to older features become the norm for on-call engineers to handle. Cross-functional team members also need to be involved in prioritization decisions related to minor fixes to the (retirement worthy) feature versus continuing with the established roadmap.
Bad example is set - By not sunsetting at the right times, teams set the precedent that it's okay to hold on to carrying costs and accumulate debt. The precedent ultimately hurts future decision-making, which can subconsciously rely on how historical examples have been set.

"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:

Internal - employee facing organizational process and communication
External - customer facing messaging and impact

Increasing the internal unshipping odds, even with too many cooks in the kitchen

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:

Clarifying what's cooking by having a clear product strategy
Simplifying the menu by focusing on quality
Declaring a head chef to move away from consensus agreements

Clarify what's cooking by having a clear product strategy

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.

Credit: Ravi Mehta, EIR @ Reforge and Former CPO at Tinder, Facebook, TripAdvisor

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)

Simplify the menu by focusing on quality

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.

"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)

Declare a head chef to move away from consensus agreements

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 simplier for each team to accept ownership boundaries." - Keya Patel (OIR at Reforge, Ex-Director of Product Growth at Headspace)

The final hurdle to unshipping — respecting the user

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:

Being transparent about the why
Giving appropriate time
Providing a substitute

You're transparent internally, now be transparent externally

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)

Give more deprecation time and leeway than you think

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)

Go the extra mile and provide substitutes for the soon-to-be sunset feature

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:

Recommend a partner or alternative at a pre-negotiated price. Ideally this should be at the same cost or price the customer pays. This is nontraditional, but allows your organization to (1) understand partners and competitors better and (2) build or rebuild goodwill with the customer.
Verify the feature/product offboarding is seamless. This means allowing a customer to save all their history related to that feature or having the engineering team build a new integration to seamlessly migrate that product's information to a new solution.

"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)

When your team next needs to unship, remember...

To identify and reiterate one or more of the 8 standard reasons to unship: strategic alignment, buggy, novelty, niche, obsolesce, redundancy, incompatibility, tech costs
Metrics can improve from sunsetting. Instead of thinking 'What Do We Lose,' think about 'What Do We Gain.' Some metrics to watch for improvements include: decreased support tickets, latency improvements, win rate vs. competitors, NPS, and Twitter sentiment
It's grueling to sunset features ****and products because of: the human element, tech focuses on short-term growth, benefits and carrying costs are hard to see, and the biases we hold
If the team avoids killing a feature or product for too long they'll end up in limbo state or credit card debt. Move out of limbo state and credit card debt as fast as possible.
Successfully sunsetting is difficult and involves internal and external themes such as clear product strategy, moving away from consensus-based decisions, giving customers time, and providing alternatives

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. Or subscribe to our blog (we post infrequently, but make it good).