PRODUCTHEAD: Should I retire … (my product)?

exit music (for a product)

---

tl;dr

Your users must value your product more than it would cost them to switch

An end-of-life policy sets out the process you will use to retire products for customers

Think about your users and customers’ technical and economic issues first

Retiring a product gracefully means making a plan

---

a favour: please share this with other product people

every PRODUCTHEAD edition is online for you to refer back to

hello

I take a couple of weeks’ break and now I’m thinking of retiring.

Not for me personally, I should hasten to add; I’m far too youthful (and poor) to consider retirement at this stage in my life. Rather I’m talking about retiring products and features.

A product bait-and-switch #

What set me thinking about this was a bait-and-switch. A product I was using was surreptitiously retired and replaced with something so different in function, I had to stop using it.

Like many others, I use WordPress to run my blog, I Manage Products. If you’re unfamiliar with it, WordPress’s core publishing software is augmented by open source plugins written by individuals and organisations, some free of charge, some paid-for. Each of these plugins is a product in its own right, and the most popular have millions of users.

I was using one particular plugin to help me with the layout of my site. It did the job well, and I was happy to let it auto-update because the author did a good job of updating it without breaking it.

Last week, without warning, an update swapped out my plugin for something completely different, completely screwing up my site. It was purely good fortune that I noticed the change early on and was able to revert the update. Otherwise I’d still be desperately reworking my site instead of writing about it now.

What had happened is part of an annoying trend with the more popular indie WordPress plugins. Many are being acquired by larger organisations for the sole purpose of replacing the original plugin with their own product, thus co-opting an unsuspecting user base. With broadly the same functionality, and by locking some premium features behind a paywall, the idea is that they’ll force the users to start paying. Some companies drip-feed the changes to lessen the impact of the transition; others — as in this case — do not.

I am certain that these unscrupulous outfits make enough money to justify the approach from the small percentage of the user base that sticks around and bothers to pays up. But they’re certainly not winning any friends by doing so.

Why are you really killing off your product?

Whether we call this sunsetting, decommissioning or end of life, it all boils down to the same thing: taking away an active product or feature from users. If you’ve been a user of Google’s products over the years, you’ll be used to having the rug pulled from under your feet with painful regularity.

Mostly there seems to be only really two reasons why companies send products and features off to join the choir invisible.

1. Nobody is using it

2. The company doesn’t want to* keep the product or feature going

* “Doesn’t want to” covers everything from a change of company direction and strategy, to a desire to purge unprofitable or duplicate products or features, to wanting to slim down staff numbers and costs by trimming a whole self-contained team.

However, there is also a more obscure third reason why products get put out to pasture:

3. The user needs have evolved beyond your current product to the extent that it is more practical to create a new product than it is to keep incrementally extending the existing one.

Left behind by a changing market #

Even if you’re diligent with your user and market research, this is harder to spot in advance — particularly so when you’re in the middle of it all — because the change happens slowly and progressively over time.

Just look at Meta’s Facebook demographic crisis as a good example of a company seemingly being caught on the hop (or in denial) by its aging core user base — a problem years in the making. In comparison with OG Facebook users now in their 40s and 50s, people in their 20s and 30s have a very different (and arguably more sophisticated) set of needs around how they interact and communicate online with their peers.

By the time you’ve observed your users numbers dropping, it’s already too late to start work on the replacement product. Some other organisation is already meeting those evolved user needs far better than you. In Meta’s case, the threat wasn’t in fact Instagram (which they acquired), but rather TikTok, Snapchat and possibly also BeReal, as well as the competing social experience offered by in-game communities.

Meta’s other big bet on the metaverse looks increasingly late and lacking substance when you consider that people have been meeting up and interacting for years in virtual spaces such as Animal Crossing, PlayerUnknown’s Battlegrounds and Roblox.

Pull, don’t push #

Whatever is prompting the need to kill off a product or feature, it’s always going to be easier to handle the migration to a replacement if the majority of your users demonstrably want the upgrade. To cut a long story short, this boils down to finding a new product-market fit.

Doing so will be more difficult than first time around. With an existing product and its user base, you will have to work doubly hard to avoid the trap of thinking you already know what those users need. All you really know for sure is that your existing product doesn’t meet their needs any longer.

Despite how proud you and your team are about your new product, people will not upgrade just because it’s new. Forcing an unwanted upgrade on them will only push them elsewhere.

Instead, can you ensure your new product is so in tune with your users’ evolved needs that they can’t wait to get their hands on it? Retiring an old product is much easier if the new product is pulling your users to it, rather than you having to push them to migrate.

What to do with those laggards? #

Laggards are the segment of your user base who, rightly or wrongly, value the stability of what they currently have over anything new.

I recently swapped out my glitching version of Microsoft Office 2007 for the latest version. I was gratified to find that 99.9% of what I used it for remained cosmetically unchanged. There were even options to emulate the behavioural quirks of older versions.

When it comes to office productivity software, I am the very definition of a laggard — the bits of Microsoft Office that I use on a frequent basis have essentially remained unchanged for over 20 years, and that suits me just fine. In this regard, I fear change. It would slow me down.

It would seem I am not alone. Despite strong challenges from Google, and the existence of free-to-use alternatives such as LibreOffice, Microsoft continues to dominate the market share for office productivity software. There is a good reason for that.

I would hazard a guess that Microsoft’s Office product team knows that there are whole companies of people still happily pootling along on an ancient version of Microsoft Office. If and when they upgrade, there’s likely going to be a gap of 10-15 years between their version and the current one.

While Microsoft has most certainly added things to Office, upgraded features and changed technology platforms over the years, they have also been careful to keep the core user experience relatively consistent, albeit with the odd exception.

By doing so, they’ve made the transition from one version to another almost seamless. Other than the humble web browser, I can’t think of any other product whose look and feel has remained so consistent over such a long period of time.

Microsoft has correctly identified that the core needs of their Office users remain broadly the same, and has clearly invested a great deal of time and effort innovating their platform without fundamentally changing the core experience. They’ve carried their laggards with them, and that is reflected in their continued market dominance.

How many laggards? #

If my version of Office 2007 had continued to work glitch-free, I am certain I would have carried on using it for several years more without upgrading. It did what I needed, and I needed nothing more. When I need to do something different, I use a different tool for the job, whether that’s Google Docs, Miro or Notion.

So when thinking about product retirement, you have consider the likelihood that you will never convince the laggards to upgrade.

Your tactics will depend on the dynamics of your particular user base.

If laggards make up a significant proportion of your users, then this is a strong signal that there’s still value in continuing to address their particular set of needs (as distinct from the evolved needs of the other users). Can you identify and isolate their typical workflows? Do you understand the nuances and quirks that they rely on?

If you need to ditch a burning platform, can you emulate those workflows, user interface elements and quirks on a more stable and easily maintained platform? Your goal is for laggards not to notice a difference, so resist the urge to make tweaks.

If laggards are a relatively small proportion of your user base, can you afford to lose them all when you discontinue the product? If they protest the changes, will they be so vocal that they affect the migration of the otherwise compliant users?

Final thoughts #

Retiring a product is something you should primarily do in response to evolving user needs. Doing so as a result of internal corporate pressures alone will inevitably be a bitter pill for your users to swallow.

Remember that the gap between the needs of your laggard and non-laggard users will eventually grow to the extent that it is no longer practical to meet both sets of needs in the same product.

Sunsetting an old product goes hand-in-hand with creating a new product that meets the evolved needs of your users, which means finding product-market fit anew.

Where you have large numbers of laggards, it can be worthwhile to craft a product strategy that carries them with you to defend your market share. This may result in additional cost and effort to recreate or update the legacy product while also building and maintaining the evolved product in parallel.

If you’re unable to make this trade-off then it is important to consider the implications of losing all your laggard users before you retire your legacy product.

Speak to you soon,

Jock

---

---

what to think about this week

A guide to surviving the product zombie apocalypse

Look around: It’s a desolate wasteland. Zombies walk the earth, slowly, relentlessly. They are hungry and they don’t discriminate. Before they turn on you and eat you alive, it’s time to blow them away and send them to their final rest. This isn’t a scene from a movie, it’s your product portfolio. But the threat is no less real, and your need to act is no less vital.

Communicate not just what is new but what is going away

[Pragmatic Institute]

OMG EOL – LOL (or: How to take a product to end of life)

Product managers are full of contradictions: if we’re not busting a gut to launch something, we’re trying to kill our older products off.

Sensible reasons why a customer won’t upgrade

[I Manage Products]

---

---

“How to … retire a product gracefully”

As Product Managers one of the toughest challenges we face is to determine when to withdraw our product from the marketplace. Its much easier to build and launch a product then to discountinue a product, especially if there are a few remaining customers still using the product. I have personally closed a handful of services and for me, it was sad to close a service which I had spent much time building. However, there comes a time when it makes good business sense to cease the service offering, to stop selling and supporting the product in the marketplace.

A structured withdrawal

[Nick Coster / Brainmates]

EOL from the Customer’s POV

As seasoned product managers, most of us eventually have to phase out old versions and completely eliminate old products. This is called End of Life (EOL) or End of Service (EOS), and is important weed-clearing. It’s generally motivated by our internal economic needs: rebalancing resources in our product portfolio, reducing support costs, moving customers to the latest version, abandoning products that can’t pay for themselves.

Dropping old products creates problems for your customers

[Rich Mironov / Mironov Consulting]

recent posts

The 4 unintended side-effects of risk aversion and what to do about them

When we become more worried about risk, four unintended things also tend to happen: bottlenecking, erosion of trust, ossification of process, and a risk appetite that tends towards zero. Here’s what you can do about them.

It’s all about the safety net

[I Manage Products]

The agency trap

How can product management fit into an agency business model when requirements or specifications are often contractually set in stone by the client up-front? Spoiler alert: not easily

Product company or agency?

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from back to school blues.