Why is sunsetting software so difficult
Software companies have gotten better in increasing their output (thanks to improved development processes) but obviously not all the deployed modules, screens and APIs go on to become winners. If a module has not caught on, the cost of actually keeping it ‘alive’ is likely higher than the cost of gracefully retiring it. However, most organizations do not have good processes to identify these underused features and remove them from the offering. In the best case scenario, the underused software only consumes minimal QA resources on an ongoing basis, and in the worst case, it becomes an impediment to the development of other competitive modules (either because of legacy hurdles it imposes, or due to it getting more and more intertwined with critical modules). The product management and engineering teams likely know about the bloat but the pressures to get another release out the door often pushes off any serious sunsetting / retirement discussion.
Measure what needs to be removed
To identify the bloat modules objectively and transparently, Product Management should (along with Engineering and Sales’ input) lead the initiative to establish the metrics that will be used to identify the modules to be sunsetted — for example if module revenue (or browser X usage) falls below x%, the department will start monitoring actively and if it falls below y%, the business will discontinue the module (the ‘start monitoring’ metric will help give sunsetting planning visibility to other departments in case they need to either take corrective action or inform clients — more like an early warning system). Metrics should be in the usual areas of revenue (LTV, MRR, penalty, etc.), volume/usage (% of targeted users actually using it), legal implications (generally a binary value, with possibly a financial implication). The metrics and the thresholds may need to be adjusted by product or business line. In some cases, PM may need to get a final sign-off from either executive management or a few specific clients (generally depending on the enterprise value of that client).
Dedicate development budget for addressing the bloat
Product Management and Engineering teams should proactively dedicate a small portion of their development budgets for addressing the bloat (call it whatever may work for your organization — “Technical debt handling”, “Operations issues handling”, “Performance optimization”). The budget does not have to be spent evenly across the year — it could be concentrated in a single release every year, or spread in different amounts per release. The point is the process should be institutionalized and agreed upon with management so that the difficult decision is not put off forever, or that management does not express surpise when it comes time to pay this portion of the bill.
Dos and don’ts
Communicate to internal groups and clients
Once the sunsetting candidates have been identified, PM (along with Marketing) should communicate the following:
· Timeline for retirement
· How will data (collected through those modules) be handled (archived / given back to the client)
· How can users substitute for the functionality (if needed, PMs should be willing to guide clients towards 3rd-party sources in case they offer solutions for the sunsetted modules)
· Compliance implications (if any)
Conduct a webinar
· The PM team may also want to do a webinar specifically to address each of above issues proactively. The only thing worse than not retiring something is to retire it and then have an important client make the inconvenient call up the executive chain.
Monitor Support calls post deployment
· Once the release has been deployed, PM should work closely with Support to monitor the client calls to proactively identify any major negative impacts
Check dependencies on other groups
· Ensure that Ops / Finance has removed the sales related line item for the module (if individually sold), Marketing has removed references from collaterals and that Help team has updated all printed / online help materials.