PRODUCTHEAD: Sunsetting a product or feature
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
product spirit (fade out) #
every PRODUCTHEAD edition is online for you to refer back to
tl;dr
When sunsetting a product or feature:
Explain why honestly and be transparent about how it will impact your users
Be understanding as they may be disappointed or frustrated by the change
Be responsive and supportive by answering your users’ questions and helping them with the transition
If possible, offer your users alternative features or solutions
hello
This week’s PRODUCTHEAD features articles from Des Traynor and Janna Bastow advising on the how and why of sunsetting a product or feature. Once you’ve decided to kill off a feature or decommission a product, how you go about doing so will be quite different depending on whether your software lives in the cloud or on users’ local machines.
Maintaining Cloud / SaaS software versus locally-installed software #
From a product management perspective, one of the best things about a cloud or software-as-a-service (SaaS) product is that each and every one of your customers can always be using the most up-to-date version of the software.
When your customers install your software locally, despite your encouragement to run the latest and greatest version of your product, you end up with a user base fragmented across different major and minor versions.
Now think about when you need to roll out a critical security patch. With a cloud / SaaS product, you deploy the patch to your production system and you’re done (forgive my over-simplification).
With locally-installed software, you essentially have a couple of courses of action:
- you can apply the patch to the most recent version only, then somehow convince your entire fragmented user base to upgrade to it (which is never gonna happen); or
- you patch each and every minor version your customers are using so that they can ‘upgrade’ without fundamentally changing the version they’re on.
While this second option sounds like an almighty logistical pain in the bum, ‘rolling’ Linux distributions such as Debian are kept up-to-date to date in this way. Users get the benefit of regular security updates without the concern that these updates will fundamentally change how the software works. (Unanticipated functional changes may break dependent software or integrations.)
Sunsetting a product feature #
Let’s think about when there’s a particular product feature you want to remove. From a purely technical standpoint, this can be quick: in cloud / SaaS software, you can make this change with relative ease, again ‘just’ with an update to your production system.
But in locally-installed software, you have to schedule the change for a future version upgrade and wait for your fragmented user base to catch up, if they ever do. Even if your users are relatively good at updating to the latest and greatest version of your product, it will take some time before you can consider that feature to be truly dead. I offer some thoughts on how you can handle this in “OMG EOL – LOL (or: How to take a product to end of life)”.
And don’t forget that the removal of that feature may give your users a strong incentive not to upgrade, anchoring them at the last version retaining the feature, and creating a different set of problems for you to deal with later down the line.
Why are you sunsetting the feature in the first place? #
Just because you’re technically able to sunset a particular feature doesn’t mean you should. In one of the articles I’ve featured this week, ProdPad co-founder and CEO Janna Bastow lists out five of the more common reasons:
“How to Sunset a Product – Everything You Need to Know”, Janna Bastow, ProdPad blog
- Not enough customers use it
- It’s too costly to maintain
- It’s built on other technology (which no longer permits usage in the way you need)
- It’s diluting your value proposition
- It’s blocking the effectiveness of another feature
I think it’s interesting to note that most of these reasons are framed from the organisation’s perspective. So I would add another to the list: “a better way exists for users to do what they’re trying to do” — and this may be another feature in your or someone else’s product.
Understanding the current position #
Before taking the decision to sunset a product feature, the most fundamental questions to ask are who is currently using the feature, and why? Rather than retread old ground, I cover these in much more detail in the PRODUCTHEAD edition “Should I retire … (my product)?”
But this does point to the need for some user research. With luck, you should have some quantitative analytics to tell you how many users are using the feature you’re trying to sunset, and how frequently. Again this will be easier for the cloud / SaaS gang, but it’s not impossible for local software if you’ve been fastidious about instrumenting your features and gathering telemetry.
As always, analytics will tell you what’s happening (and when), but to find out why, you’re going to have to talk to people. In another of the featured articles this week, Intercom co-founder and Chief Strategy Officer Des Traynor suggests finding out who are the “real users” of the product feature, and who are the “dabblers”:
“Let’s say it’s a calendar feature you’re removing. Dabblers might only have 1-5 events, and haven’t added/viewed them in months. Real Users will have lots of events and interact with the calendar on a weekly basis. Dabblers won’t even notice you removing the feature, real users will lose their shit if you break their workflow.”
“How to sunset a feature”, Des Traynor, Intercom blog
Communicate honestly, transparently and often #
Unless you’re in the fortunate position of killing off a feature that nobody was actually using or cared about, you’re going to have to tell people what’s going on, why and when.
Because you’ve done your homework and spoken to a sample of the remaining Real Users, you should have a pretty good idea of why they still use that feature. The way you tell these people about your plans needs to be structured around their needs. This includes your understanding of the disruption you’re causing them.
You may be able to point them to an alternative way to achieve the same goal, whether within your product or elsewhere, and if practical provide a seamless way to migrate them. As Des Traynor also suggests, at the very least, you should let them retrieve their data in a usable format for them to take elsewhere.
When Google decided to shutter their Stadia cloud gaming platform, they won back a lot of goodwill by refunding users’ game purchases, and ensuring they could unlock their gaming controllers for use with other gaming consoles, PCs and platforms.
Don’t forget that you need to communicate internally also. There may be other teams in your organisation who have been regularly using, selling, blogging and answering questions about the feature that’s going away. Make sure you let them know in good time, and like your users, show you understand the impact to their work and provide an alternative where necessary.
Final thoughts #
Whether the reasons for sunsetting a product feature are user-centric, beyond your direct control, or are entirely to benefit your organisation, the changes will inconvenience and possibly annoy some groups of people. You may not be able to avoid this entirely, but your approach can certainly mitigate some of the intensity if chosen wisely.
Speak to you soon,
Jock
what to think about this week
How to sunset a product – everything you need to know
Sunsetting a product is tricky. Product managers want to make the right decision for the business and not disgruntle any customers or stakeholders in the process.
Measure both expected and unintended impact
[Janna Bastow / ProdPad]
How to sunset a feature
If you’re not making mistakes then you’re not making anything. Some features will be a win from day one, some need a few tweaks, some need a few weeks, but some just Don’t Work Out As Planned.
Often art is defined by what you take away
[Des Traynor / Intercom]
recent posts
Getting your first job as a product manager
Job adverts present a chicken-and-egg problem: they all need you to have product management experience to secure a job, but you don’t yet have a product management job to gain that experience.
Don’t let this discourage you!
Practical tips for breaking into a career in product management
[I Manage Products]
Force multipliers
Recently I was explaining to a client why I focus my efforts on finding “force multipliers”. These are what I call activities that allow us to extract multiple benefits from a single piece of work. You could think of it a little like a workplace fusion reaction, where the output ends up far greater than the input effort.
Getting more out than you put in
[I Manage Products]
How to sharpen up your vision and strategy
When the vision and strategy are focused and clear, they allow product managers to prioritise and filter the possible options for their products more easily.
Use these straightforward questions and worked examples
[I Manage Products]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from exceedingly early Christmas decorations.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”
— Lyndsay Denton
Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, Twitter and LinkedIn.
Leave a Reply