Shutting down a product is the inevitable consequence in the lifecycle of any product. A recent example being the shutdown of Google Reader, an announcement which greatly saddened me. The problem with product life span is that we never anticipate it, and rarely plan for it.
Sunsetting vs. Shutting Down
Firstly a clarification – there’s a difference between “sunsetting” and “shutting down.” “Sunsetting” is leaving the servers up with the product still usable, but not doing any more development or content work on it. There needs to be a cost benefit analysis done before this decision is made, but in my opinion, the vast majority of products don’t need to be shut down. With correct server architecture and management, you should be able to run very small userbases with very low fixed costs that remain profitable.
When Do You Shut Down?
A good company will generally make the decision to shut down a product when the vast majority of users who have made purchases have already voluntarily stopped using the product, never to come back. The danger is of course if there are whales who are loyal to the product with lots of high-value potential still using it. My opinion is that once these users are few enough in number that it is no longer profitable to maintain the product, you could manually start a conversation with them about moving them onto another product with a set of privileges or content to recognize their commitment to the original product.
How to Shut Down a Product
A few pre-emptive steps to take:
- Make sure the end user license agreement (EULA) is clear that the product could be shut down.
- Give users plenty of notice. This is a lot more about communication and making sure that the userbase is given appropriate advanced notice. Typical minimum notice is 30 days. If for some reason that isn’t possible, consider enforcing a 30 day refund policy, so that any purchases made within 30 days of the actual closing date are refunded to the user. This sort of a buyer guarantee helps players feel more confident when using the product.
- Replace the original product page with links to other related products. If you are a company that has produced multiple products, this becomes an interesting portfolio optimization problem and you, of course, want to shift users over to another product on your platform.
- For big products that affect substantial portions of your audience you might consider a special compensation package.
- If you also run a community forum and it is pretty active, then consider leaving it up for at least a month, sometimes more if it stays active. The idea is to let users continue to correspond, perhaps organize the move over to another product together, etc. It also lets them rant a bit, which can be a helpful step in the mourning process of losing a product.
These packages are typically broken into 3 tiers, with the first including all users who used the product a fair amount (perhaps membership for X period of time) as well as anyone who ever spent any amount of money.
The second tier would include users who put substantial time and use into the product, as well as anyone who spent a non-trivial amount of money, and then a top tier of big spenders.
These compensation packages tend to be generous (worth at least as much as the minimum spend within a tier) and are offered in a few other products to give users some options. They can be products with similar functionality on your existing platform or a revenue share deal with a partner. Managing a set of packages like this is very time consuming so it should only be considered for the biggest products, but as a developer it makes sense to provide some generous incentives to your users to encourage them to move to another product in your portfolio.