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.
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.
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.
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.