PRODUCTHEAD: Not bricking it – retiring a product with good grace

exit music (for a product) #

every PRODUCTHEAD edition is online for you to refer back to

---

tl;dr

Just over half of product managers surveyed rate themselves poor at retiring a product

Consider how people may continue using your product after it is retired, or the company exits

Activists are pushing to prevent companies from bricking devices reliant on cloud software

---

hello

Retiring a product or feature is so much more complicated these days. Just over half of product managers give themselves a ‘poor’ or ‘very poor’ rating for the skill of product retirement.

This doesn’t come as a huge surprise. It remains difficult for product managers to gain hands-on experience. For one thing, it’s still a comparatively rare event; we may launch several major releases while we look after a product. In contrast, retiring a product is usually a one-off hard stop. One day it’s there for people to use, the next it’s not.

In the past I’ve characterised retiring a product as an ‘anti-launch’. All the effort and coordination that goes into making a product launch successful is mirrored and multiplied when you want to discontinue a product. I’ve also written before on PRODUCTHEAD about retiring a product for the right reasons and how to handle with good grace those laggards who insist on clinging to the product or feature to the bitter end.

Decommissioning a product is more complicated than it used to be. Part of this is due to the conflict between the concept of ownership and the reality of products with software that relies on the cloud to function. (I looked at ownership in the context of software subscriptions a couple of weeks ago.)

When hardware is reliant on cloud software #

When customers buy a hardware product, they reasonably have the expectation that it’s theirs to do with what they wish, and that it will continue to function broadly in the same way it did when they bought it. If I bought a kettle, I would be more than a little surprised if one day it suddenly started chilling the water.

And yet, this kind of unanticipated change in behaviour happens surprisingly often with smart devices. They rely on cloud software services to function as intended and can gain or lose functionality at the whim of the manufacturer. The question then becomes whether the lifespan of the device will outlast the desire of the manufacturer to keep those cloud services running — or outlast the manufacturer itself.

Recent history is littered with examples of smart home devices that have become expensive paperweights because the manufacturers realised that running a cloud service to eternity cost a heap of money, or because the manufacturer was bought out and killed off, or because they simply went bankrupt. Slide, iHome, Gigaset and LOQED are just a handful of examples. (The thought of relying on a startup’s kit to get in and out of my house fills me with so much anxiety.) But unless you were deep into the home automation scene, these would likely have passed you by.

So how do better-known and more financially stable companies handle things?

Spotify Car Thing #

Spotify briefly offered an in-car hardware player, the Car Thing, which was aimed at those without Android Auto or Apple CarPlay. They discontinued it less than two years after launching it, bricking the device and leaving owners with no other option for reuse. Spotify wasn’t even going to offer a refund until a class action law suit prompted them to u-turn.

Google Stadia #

Google launched its Stadia game streaming platform in November 2019. By January 2023 it was no more. In contrast with Spotify, Google had the good grace to offer full refunds for all purchases of software, hardware and additional downloadable content (DLC) without requiring customers to return their kit. Notably, before the platform was shuttered, Google pushed out a final firmware update that let people use its proprietary game controllers with other gaming systems, i.e. not bricking them.

What about pure software? #

All of the examples so far have been hardware devices reliant on a cloud software service. What about pure software? We can put cloud-based subscriptions to one side because you never really own anything. There are however still software products that you can buy a perpetual licence for and install locally. In theory, you can keep using it for ever more. But in practice there’s a catch: many rely on a online licence server to activate or unlock the software for use. When that eventually goes away (and it will), there’s a good chance that you’ll be locked out or stuck in a hobbled evaluation mode.

Retiring products with good grace #

In web design, there are a couple of concepts intended to deal with the problem of people using a potentially wide variety of browsers to access the web page. With each exhibiting different levels of capability from vendor to vendor, operating system and earlier or later versions of the browser, it’s a major headache to find common ground. The two approaches are graceful degradation and progressive enhancement.

With graceful degradation you build your user experience assuming your ideal web browser will be accessing it. If a less capable one tries to, the functionality of the web app degrades so that it remains functional, but more basic. Progressive enhancement is similar but works in the opposite direction: you start from a baseline of the same user experience for all, and more advanced features become available to people with more capable web browsers.

We should apply these same two concepts our cloud-reliant software and hardware products, ideally progressive enhancement. In other words, everyone should be able to use a product they’ve purchased to do its intended job. As a bonus, certain additional features may be available if the product happens to be online, but it otherwise works perfectly fine offline.

Google Stadia took the course of graceful degradation out of necessity. The main product was the cloud gaming platform rather than the controller devices, but at least they made the effort to let owners keep using the hardware they’d purchased.

Other manufacturers of cloud-reliant products are being urged to unlock or open-source them and the services they rely on before they brick them, so that hobbyists — or even other companies — can step in to keep them useful and functional.

Final thoughts #

We have less frequent opportunities to retire products than we do to launch them, so it’s understandable why product managers feel less experienced in this part of the product life cycle. However, we should be preparing for our product’s demise long before we decide to decommission it. We may not have much warning or control over when a product will be retired, if the company pivots, is acquired or goes bankrupt.

The core concept product managers should consider before retiring any product is how we can make the process as painless as possible for any remaining users. We often think about the obvious considerations such as plenty of advance warning, good communication and migration paths to replacement products. We also need to anticipate people wanting to use our products beyond the point the services they rely on, even the company itself, cease to exist. This means designing in graceful degradation or progressive enhancement from the outset, and thinking about unlocking or open-sourcing any supporting cloud services as part of the retirement process.

Speak to you soon,

Jock

---

---

what to think about this week

Why we’re bringing Pebble back

I started working on Pebble in 2008 to create the product of my dreams. Smartwatches didn’t exist, so I set out to build one. I’m extraordinarily happy I was able to help bring Pebble to life, alongside the core team and community. The company behind it failed but millions of Pebbles in the world kept going, many of them still to this day.

Pebble lived long enough to see its defunct company reincarnated

[Eric Migicovsky]

Regulation through “bricking”: private ordering in the “Internet of Things”

Internet-enabled “smart products” operate through networked software that links the devices to their manufacturers’ servers to enable the collection and distribution of data, and, as a result, these products are vulnerable to software disruption. This article examines “regulation by bricking”, which refers to the deliberate impairment or destruction of software with the intention of negatively affecting product functionality.

Held to ransom by cloud-reliant products

[Natasha Tusikov / Internet Policy Review]

---

---

recent posts

Navigating your product management career

Ross Webb and I have been chatting about product management career progression.

We cover topics including:

» Thinking of visibility as a strategic competency, not self-promotion

» Controlling your narrative through regular updates

» Building cross-organisational relationships deliberately

» Mapping your stakeholders’ preferred communication styles

A roundtable chat on moving into product leadership

[I Manage Products]

New technology alone is not the answer

New technology is not going to suddenly make all the challenges facing an organisation disappear overnight. Why? Because more often than not, those challenges are social not technological. Technology alone rarely solves ‘people problems’.

AI is neither a panacea nor a magic bullet just as digital wasn’t for UK gov

[I Manage Products]

What freelance product management is really like with Jock Busuttil

Off the back of his recent article for Mind The Product, Liam Smith interviewed me about my experiences in freelance product management.

We cover topics including:

» Should you hire freelancers in your product team?

» How to be successful as an external hire

+ more :-)

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from carrot cake.