When to retire a software product?

[Mark Dalgarno]

Regardless of what some developers may say it's possible to prolong the life of most software applications almost indefinitely.

So, the question is when should you retire a software product and how do you decide? I'm interested in examples where people have retired a product and how they arrived at the decision to retire it.

[David Locke]

When a category comes into existence and a market leader selected, the category's market becomes predictable, and has a fixed size. Firms selling in that market consume the category. There is very definately an end to a category. Sure, births and deaths can keep a category going and growing, but commoditization comes much earlier.

As a category is consumed, the customers change, so you have to keep changing the product. Sublimating the interface for late market customers or consumers clearly force you to create a new product with a new name. Otherwise, you lose your technical enthusiasts. The sublimated interface should be a SAAS application.

The transition to late market marks the end of growth, so if you want more growth, you will need a new underlying technical innovation. That doesn't mean retirement. You can retire a product when the product based on the new technical innovation has replaced the revenue stream.

Price-based competition sets in much earlier than the entry into the late market. Since revenues fall and costs rise, transitioning to SAAS will help for a while.

Commoditization can occur in a market at any time. It happens when you have provided your customers with more than they need or are willing to pay for. You need to find a new vector of differentiation. Having found it, you will still have to wait, again until the revenue stream is replaced.

[Jeff Celander]

I have seen products retired because the niche they filled disappeared, cost of maintaining it was more then the revenue, the company got bored with it, the sales force said they could not sell it, the companies strategic goals had changed. I have seen products with a small customer base making a steady profit retired because the revenue did not meet company minimum revenue requirements. I have seen products retired after being merged with several other related products to make a new product. The rules for retiring a piece of code is totally up to the eye of the beholder.

If a peice of code makes a profit and fills the need of some customers then why not squeeze all of the juice you can out of it.

[Mark Dalgarno]

Jeff Celander said:

I have seen products retired because the niche they filled disappeared, cost of maintaining it was more then the revenue, the company got bored with it, the sales force said they could not sell it, the companies strategic goals had changed. I have seen products with a small customer base making a steady profit retired because the revenue did not meet company minimum revenue requirements. I have seen products retired after being merged with several other related products to make a new product. The rules for retiring a piece of code is totally up to the eye of the beholder.

Thanks, some good examples here.

Jeff Celander said:

If a peice of code makes a profit and fills the need of some customers then why not squeeze all of the juice you can out of it.

I guess it depends on whether you could be doing something more profitable. On the other hand you might make some customers unhappy by retiring a product that they were using.

[Steve Jones]

You need to know the cost of your time. And examine other opportunities. If the product doesn't meet the criteria of making what you spend on it (time, resources, etc.), then you ought to consider EOL.

If you don't have a suitable upgrade to move customers to, I'd look at Open Sourcing it as well. You can gain quite a bit of goodwill from this, perhaps still charge for support, and get people interested in what else you do.

[Thomas Otter]

Generally, if you can maintain the solution and still tick over a profit, then it probably makes sense to do so.
Big software vendors like SAP and Oracle increase maintenance towards the end of the product life cycle, a) to make people more likely to upgrade and b) finance the maintenance.

This needs to be done carefully though, as not all products can take this model.

Make sure you have an alternative product before you kiss good bye to a predictable revenue stream,

[Bill Bither]

Instead of retiring the "shareware" product that I first developed when bootstrapping my company, I decided to donate all proceeds to charity. The product itself has had only one update since 2002 (to support Vista) and we get very little customer support from it. The revenue has eroded due to lack of updates and no marketing, but it still results in a significant donation to this small Charity, checks that we send them every month for a consistent revenue stream.

The result is a lot of good PR, employees who are happy to accommodate the few support requests we get (because it goes to charity) and low customer expectations as it's clear we do not profit from this product. My company received the Mass High Tech Citizenship award last year because of this and other charitable efforts that our company participates in.

The product is listed here:
http://www.eyebatch.com

If support costs are low, but revenue seems pretty insignificant as your company has grown, consider this approach.

[David Locke]

Jeff Celander said:

If a peice of code makes a profit and fills the need of some customers then why not squeeze all of the juice you can out of it.

Mark replied:

I guess it depends on whether you could be doing something more profitable. On the other hand you might make some customers unhappy by retiring a product that they were using.

There is a point in the technology adoption lifecycle where you transition from the early mainstream market to late mainstream. You have sold half of the seats remaining. Growth has ended. A lot of companies die here. You need a new technology, not just a new product. You need a new vector of differentiation or in Mark's word, you need to do something new.

The old product needs to be rewritten, so it presents a market appropriate interface. You might go SaaS here, since you need to be cost focused. You cannot retire the old product until the revenues from the new product are there.

The next market transition will be to an information appliance or embedded application. The costs are vast. The technology disappears. Most companies don't go here. Their product finally dies where they have to enter this market, the laggard market.

Death might mean selling your application to another vendor. Lots of products continue to exist long after their birthing vendor has died. You will still want to keep those customers, so you would need a product to cross sell them.

And, even if you never reach the laggard market, you might find yourself commoditized long before that. Commoditization can occur anywhere on the technology adoption lifecycle.

[allan kelly]

It depends on what you mean by the word "retire".

We're talking products here so lets ignore in-house applications.

There is technical retirement - when the company accepts the developers will saying "too much technical debt" and "we have to rewrite it" and there is marketing retirement.

I've seen a couple of examples were developers complain and complain eventually get their way. I think this is ALWAYS wrong and usually the result of inexperience management (don't understand the software business) who are scared of developers; and software developers who only know how to create software not maintain it (in which case do you trust them to write version 2.0 and maintain it?)

If things really are that bad then you need to create a new product but you need to creating for one (or more) niches of the existing product. You do not write version 2.0 from scratch. Any "rewrite" should be market led.

Which also brings us to version 2.0. Despite what many developers think, and what a lot of marketing would have customers believe these are very rarely completely new products. Microsoft are masters of this.

In todays world any technical versioning is internal only, version numbers are in the control of marketing. If calling it v.2 will sell more than calling it v.1.4 then call it v.2 and vice versa.

So now we've defined it as a marketing issue it more a case of how much money can you make and whether that covers the cost of maintaining/supporting the software. However its not just a case of does it bring in more revenue than is costs there is also opportunities to consider.

If you can create a new product and sell it to your existing customers as an "upgrade" or "replacement" then you might want to end of life a product.