Julia Harrison
Senior Director
Overcoming obstacles to shutting down a digital service
With decades of experience in infrastructure operations and product leadership, I’ve been responsible for shutting down numerous services which have reached the end of their useful life. The process of shutting something down isn’t easy, and there are often more stories of failures, resulting in products which limp along for years, than there are successes.
When teams have put time, effort and care into creating a product or a service, it’s hard to let go. But whether it’s an internal experiment you’ve been working on for a few weeks, or a client-facing service like Microsoft’s Skype that’s been running for years with millions of users, there are good reasons for leaders to make the important decision to shut a service down. That might be:
What seemed to be a great idea turned out to be less valuable than hoped
What was successful for a time has become less valuable and no longer justifies continued investment
What was – and still is – a great idea was built, enhanced or maintained in a way that hasn’t stood the test of time. It’s become risky, unstable, and too costly to maintain.
In all of these cases, the bottom line is the same: the cost isn’t worth the benefit.
If you continue with the status quo, you bear the ongoing cost of technology, the cost to employee morale and potentially greatest of all, the opportunity cost. If your time and energy are invested in propping up low-value products, at some point it will mean missing out on something transformative.
How to shut down
Sometimes it can take years just to move from realising a product needs to be shut down to even setting a date to do it. But however long it takes, overcoming the blockers of successfully shutting something down will demand three things: a confident narrative, support for your clients and support for your teams.
1. A confident narrative
When confronted with news of a shutdown, stakeholders are likely to raise objections. Equally, teams may feel that the decision to shut down is a reflection on their work, or a sign of failure. A confident, well-reasoned narrative will manage opposition and bring people with you. The following is a useful guide to follow:
We tried some things. Write a potted history, just a few lines, of the thing you are shutting down.
We learned some things. Explain what has led to the decision. Linking out to blog posts which chart the journey you’ve been on can help to give some background to the decision (one of the many ways in which working in the open makes things better).
We’re acting on what we learned. The alternative – learning something and not acting on it – would be deeply irrational. There’s no need for an apologetic tone here: retiring a product is a normal thing that happens.
This is how it makes us stronger. Describe your learnings from this product which will inform future work, and remind people of the time and energy you can devote to more valuable things, and the risks and costs you will no longer incur.
We acknowledge the challenges and impacts on others. While the risk of objections from a client or attacks from your critics can be daunting, these fears don’t justify not going ahead with the shutdown. You do need to be ready to do right by people, however, and that starts with acknowledging how your decision will affect them.
2. Support for your clients
Your clients’ needs are best understood by talking to them. This should be done as early as possible – using your confident narrative – and communication should be regular and sustained throughout the process. If there are clients who rely on the product you’re retiring, give them enough notice to make their exit as smooth as possible.
Pragmatically, there’s an upper limit on the amount of support you can give each client, user, or group of users. That will depend on how much pain they’ll experience from the product shutting down, how much that affects their relationship with you, and how important that relationship is to you.
Understanding those factors might involve working with different people in your organisation such as account managers and user researchers, who can surface any risks early. If the overall risk of retiring the product seems high, consider running a pre-mortem workshop to identify potential problems and develop plans to mitigate them.
3. Support for your teams
The morale of your people directly affects your organisation’s ability to meet its objectives, so ensuring your people are looked after is an important part of any value equation.
It can be difficult to see a product you’ve worked hard on reach the end of its useful life, or to see your great idea fall apart on contact with messy reality. But it’s also soul-destroying to put in continued effort towards a lost cause. People will experience a range of emotions, and making space to acknowledge those feelings is important. If the shutdown presents a major upheaval, give people safe spaces to ask questions and air concerns, and make sure employee support programmes are easy to access.
However, when it feels appropriate to do so, focus on the positives. Reflect on what the team has learned from the experience that leaves them better equipped to develop future products and fulfil the organisation’s goals.
Making it easier next time
There will always be challenges in retiring a service or shutting down a product. But you can make things easier for your future selves by starting with the end in mind. There are some key questions you can ask before you even commit to building a product:
What problem are we solving, for whom?
How do we know it’s a real problem?
How will we know when we’ve solved it?
How will we know when it’s time to stop?
As a product starts to take shape, you can ask at regular intervals:
What happens if we decide to shut this down?
What support might our clients need?
How might that influence our design now?
Shutting down is not defeat
Whether it’s an experiment or a long-running service, retiring a product might feel like failure. But shutting something down when it is no longer viable is a rational choice, not a decision that represents defeat, and making that choice in good time is something to reward, rather than discourage. As advocates of test and learn, we see letting something go as a normal step on the road to building better services.
That doesn’t mean, at the point of announcing a shutdown, that explanations aren’t required, or that your teams and clients won’t need support as you transition away from the service. But it does mean that you can lead the process with confidence.
What’s more, retiring a service that isn’t working is an opportunity to develop one that is. Working with your teams to build and reflect on what you’ve learnt – and applying those learnings to new projects – will allow you to develop something transformative.
Written by