End of Life: Retiring a Product
One aspect of product management that people talk about in theory but rarely practice is the product life cycle. That is, we can birth and grow a product but we rarely retire one. Every year there is a new release with new features and new platform support. A software product is like Frankenstein’s monster: we launch it and now... it… is… alive!
What’s the worst thing that can happen to a new product? The worst thing is some sales. Now you have a bad idea but also customers to support. If you try to discontinue it, you get complaints from those customers and their sales representatives. Perhaps this is why only 20% of technology companies report discontinuing software products, according to the Software Product Management: Best Practices (2004) report from SoftwareMinds.
There’s also a belief that, once developed, software is free. How much does another copy of software cost? Sure the first unit was expensive but subsequent copies are free, right? Because hardware uses atoms, subsequent units have hard costs. But when bits are free, there is an inclination to think that there are no costs. But what about technical support? What about demands for a new feature? What about upgrades for new operating systems?
How do you kill a product that is no longer profitable? And how do you know that it’s time?
How to decide
The easiest way to know that a product should be killed or sold off is when it no longer fits the company’s distinctive competence and market strategy. Regardless of the costs, a product that doesn’t make sense in the context of the rest of your products just confuses your customers. It makes sense for Starbucks to sell coffee makers but why is GE offering memory sticks, MP3 players, and headphones?
For companies with a direct sales force, it’s fairly common to see good software sitting idle when the sales teams have too many products. Sales people put their energy into the products that are easiest to sell and that have the highest payback. Therefore, some products—each a good idea—just aren’t top-of-mind for the sales force and get ignored.
Even if the product once fit into the company’s market strategy, a product no longer generating revenue should probably be retired. Sure, some products are used to help close a deal: “Sign by the end of the month and I’ll throw in this free software.” But product managers with responsibility for the “free floor mat” product better have proof that the pull-along sales are worth the continued investment in the product.
Nothing is more frustrating to a customer with a problem than finding that the product’s vendor knows little about its own product.
Usually product managers just know when a product is past its prime. But the political ramifications are intense. The product is a pet project for one of the founders, or is critical to one (and only one) customer, or the sales people resist removing even one product from their bag.
Despite an inherent sense of when a product should be retired, product managers need a data-based method to justify the decision. The easiest way is to assume that at least one person in your organization must stay up-to-speed on the product. The rough cost of any technical employee is $100,000-$150,000 a year. Is it worth $100,000 to maintain the product?
Another method is to get an estimate for support from a third-party: what would they charge you to perform bug fixes, new platform upgrades, and ongoing customer support?
The most accurate way to decide to discontinue a product involves Activity Based Costing. Evaluating the cost of activities required in delivering and maintaining the product easily delineates a profit maker from a profit taker. For more on ABC, you’ll have to pull out your college textbooks.
How to implement
Assuming that you’ve made the decision and have executive support, what are the mechanics of product retirement?
First, stop paying commissions. Regardless of what else you do, ending the commission program will guarantee ending the life of the product. Only then should you tell Support, Services, Sales, and customers.
Be clear. Tell employees and customers that this product is no longer viable for the company. While the company will fer technical support and bug fixes for one year, the product will not be enhanced or improved in any way including adding support for new operating systems and platforms.
This notification is usually done via letter or email to the buying contact in the client site.
Here’s an example from FusionOne:
Several months ago, we informed users of our free FusionOne Basic service that we would no longer be supporting the free service, and urged users to upgrade to our fee-based FusionOne Plus service. Therefore, effective March 31, 2005 FusionOne will permanently discontinue the FusionOne Basic service. After that date, the Basic service will no longer be available, and any data stored on FusionOne servers will be permanently deleted. We will not be able to provide access to that data in any form after March 31, 2005. We strongly suggest that Basic service users retrieve and/or delete any data stored inside the FusionOne service prior to this date.
We encourage you to learn more about FusionOne’s other service offerings for mobile phones: MightyPhone ™ (www.mightyphone.com) and MightyBackup ™ (www.mightybackup.com).
We sincerely appreciate your support and regret any inconvenience this necessary action causes you.
This message is clear and specific. It explains when support will cease, what actions to take, and recommends available alternatives.
Fire your customers, keep your customers
The downside of retiring a product is that you may lose a customer. But poor support and no upgrades will make the customer leave eventually anyway. But customers who demand continued support for obsolete products may not be customers we want to keep. Some companies take a look annually at those customers who take more than they give: those who do not pay their bills on time; those who make excessive use of customer support; those who berate our employees unfairly. It makes sense to look at the customers of obsolete products and question if they are customers worth keeping.
Conversely, some customers of older products might well be worth keeping. How many customers choose not to upgrade to the latest release because they cannot cost-justify it? Consider offering a free upgrade to the latest version or to a replacement product to keep a satisfied customer. The revenue lost is more than offset by the cost savings of not maintaining old technology.
You need to support your customers’ environments but not one customer’s environment; that is, you must support the environments of a statistically relevant set of customers. Most industries upgrade quickly while others continue to use old platforms. Your customers may need continuing support for a platform long after the vendor has dropped support. Check the statistics on your customer-focused website to identify which operating systems are being used. Microsoft ® has been very upfront about the lifecycle of their operating systems. Go to support.microsoft.com and search for “lifecycle” to see exactly when support will be discontinued for various products.
Doctor Frankenstein didn’t know that his monster must be killed but the villagers knew. The product team that creates a product may not be the ones who can make a rational decision to retire a product. Let the numbers decide. Absent rational arguments to the contrary, a product whose cost exceeds its revenue should be gently but publicly destroyed.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.