
A Methodology for Retiring Products - craigkerstiens
http://neovintage.org/2016/01/24/a-methodology-for-retiring-products/
======
cheez
Here's my strategy, which seems to work. Build product A to the point where it
can run on its own with a skeleton support team.

Build product B such as if it is a completely new product. Incentivize people
to move from A to B. Don't bitch if they don't. They'll keep paying you and
won't cost you much to support.

If the domain changes such that it requires drastic changes to product A, then
you didn't do step 1 properly.

It's working so far for the product I have now. The biggest complaint is "Hey,
I hate the way you did X, I want the other one back." "OK, here you go:
<url>".

They keep paying.

I don't understand it. The new one is awesome. Ah well.

------
mud_dauber
It helps if your industry has an accepted framework for EOLs. Semiconductors,
for example, has a commonly used spec with recommended data, timeframes and
communication styles.

It also helps if you risk-manage your supply chain. Most of the hardware EOLs
that I've seen involve a 3rd party supplier suddenly shelving a factory or
piece of equipment with little notice.

------
perflexive
>Recommendations for moving to another service.

I think the article understates the importance of this. As a customer, I won't
be nearly as upset about a product being killed if you show me some good
alternatives, so that's critical.

