Closing Down a Product, Gracefully

Series: product dev November 03, 2016

Almost weekly it seems that a service or app shuts down and someone submits the announcement email to discussion sites for it to be skewered by internet commenters for following the same anti-patterns.

I recently made the decision to shutdown a SaaS product that I’ve been running. After looking through examples (both good and bad) of these kind of announcements, I wanted to share the handful of guiding principles that I found useful.

Empathy for users

It sucks when something you use shuts down. Even if you fully support the company’s decision, it still sucks. While it sucks for me, personally, that I’m shutting down this product, it sucks more for the hundreds of users for whom I’ve added a low-value, high-urgency task to their plate.

Avoid focusing inward and using flowery language to describe your “incredible journey”. It’s not incredible for your users that you are shutting down, it’s a pain.

Give plenty of notice

It takes time for everyone to read your email or see your announcement. It takes time for users to discussion their alternative options internally. It takes time to transition to a new product. And you’ll need time to gracefully ramp down your infrastructure.

Be courteous and give as much notice as reasonably possible. In my case, I gave users 3 months notice that I would be discontinuing the product – and waived the cost of all paid plans during that period.

Provide migration options

Founders have a great sense of the competitive landscape for their product. They know what other options customers have. Share that information generously.

In the shutdown notice for my product, I included multiple options for free and paid alternatives – including a short summary of the product and how it was different (or the same) as mine.

It’s their data, let them have it

Users trusted you to store their data. It is their data. Make it painless for them to get an export of their data in an easy to consume format (CSV, not SQL dumps…). It’s not enough to point to your API and tell people they can scrape it themselves.

If you make it easy to export, competitors may help make it easy to import – making the transition less painful for your users. My app is pretty small and it still happened for us.

Don’t open source it

Multiple customers inquired about releasing the app as an open source project. This is almost always a bad idea. “Just throw the repo on GitHub” vastly underestimates the time and energy needed to support an open source project if you want it to be valuable for people.

Especially if there are alternate tools or competitors, releasing your code as open source without dedicated effort to support it will lead to a bad experience for everyone. It’s no fun to be the owner of a “dead” project on GitHub and it’s no fun to be a customer who inherits a big ball of legacy code that was never meant to run on-premise.

I know this is not what people want to hear, but it’s reality.

For transparency, included below is the email I sent to the 2,060 people registered for MoraleApp. After sending the email, I also added a site-wide banner to app that linked to a published version of the same message.

It’s not perfect but I’ve tried my best to follow the guidelines above:

built with ♥, Jekyll, and GitHub Pages — read the fine print