The Unlaunch Manifesto

One of the most valuable product culture trait I’ve observed and seen bear fruit is to evaluate critically our past launches and work. When a certain feature doesn’t feel right for the current time and the state of the product, we’ve grown to not be afraid of unlaunching it.

Unlaunching is a balancing function to keep the bloat in check and helps you constantly evaluate & evolve your product positioning.

It’s very important to keep the health of the product intact. It’s a mark of a great product team that is capable of looking back and cleaning up as needed.

I shared this observation on Twitter and got a few interesting responses from folks who wanted to know more about how to think about unlaunching.

So here it is, a way to help you rationalise and execute an unlaunch –

Why unlaunch

Didn’t you (or your past teammates) spent weeks and months launching this? You (or they) sure did but that’s not the reason to keep dragging things along.

There are many potential reasons to evaluate periodically and unlaunch features when needed.

Here are a few scenarios that qualify as such instances:

No longer works as intended: It worked well when it launched but your product has now evolved and that feature has lagged behind since the team couldn’t keep investing in it. Now it’s no longer functioning as intended in the current state of the product – deemed an integration failure.
Difficult and expensive to maintain / support: Because you couldn’t invest in bringing the feature along as your product evolved, the lagging feature now requires inefficiencies in your current work (legacy design patterns and code) to keep maintaining it. Often, this means a lot of engineering and design bandwidth spent in keeping up the support.
Inconsistent with product strategy & story: The market has evolved, your product has evolved and so has the positioning and strategy of your product. These changes mean that some of your features no longer make sense in the current version of the story. Time to cut the cord.
Inherently limited shelf life: We often don’t think about this but there’s roughly 20-30% of features in products that have a limited shelf life. Many growth hacks would fall in this bucket. They sort of work for a while and need to be killed once they have run their course.
Low and declining usage: This is pretty straightforward. Users evolve and their usage patterns evolve with them. Many a times the user base grows out of certain features and then those features don’t make sense anymore.
Increasing clutter and distraction: The product needs to do a few things really well. It also needs to map very sharply to the user’s needs. The more features accumulate, the more they create clutter and distraction and dilute the core value of your product.
Dangerous false precedence for creating similar mistakes again: This is a very big issue. How many times have you heard this: “We’ve already done this in our Profile section. Why worry about it here? Let’s just do what we did there.”? We anchor on our past work as validation and if the past work now stands on rocky grounds, you’re unknowingly leaving the door open for more problems by not killing it.
Opportunity cost often goes unmeasured: By keeping a dysfunctional feature alive, we’re unable to make room for better work. Think about what you’re not able to do because of the dead weight you’re continuing to pull.
People shipped features that the users didn’t need, to get promoted: You might have seen this happen, you might have not. It can happen sometimes. This is why unlaunching and leaning up a product should be rewarded as much as launching is.

Great okay, I’m sure that’s enough reasons to at least get you started thinking about the inefficiencies in your own product.

How do you think about actually unlaunching something though? I’ve got a high-level action plan that you can use.

🔌 How to unlaunch

When you intend to unlaunch something, you’re looking at a ~4 step process. You can omit or shuffle the steps around as needed but I’m sharing what I’ve seen work well.

Let’s go step by step:

Isolate first: Isolate the feature in code, design and the feature footprint. How far and wide does the feature sprawl? What areas of your product does it touch and affect? In my experience, this step is what deters most attempts of unlaunching something. Nobody wants to go dig deep into the stale spaghetti because there’s a potential risk of screwing things up massively in unexpected ways – this is why this work needs to be protected and incentivised.
Test with an ablation: Turn off the feature for a small % of users and see the response in the numbers. It’s also worth doing a long-term ablation on the side to gauge the long-term impact of the removal.
Unlaunch: Do it… anticlimactic but very satisfying nonetheless.
Communicate responsibly: There’s probably non-zero people who cared about that feature (it’s never zero so yeah, this step is important) and you need to communicate through the right channels. Think of letting your users know, send out comms to business partners, update your support documentation and help center articles and so on.

If users don’t care when it’s gone, they probably didn’t care that it was there.

There you go. Try this exercise once and share with me your unlaunch story!

It’s liberating and the right thing to do, to unlaunch something that you know is no longer helping your product positioning and the value prop to the user or worse, is no longer functioning authentically.

– @hvpandya