Selrahc’s Platinum

I am now in charge of the product management for a bunch of “legacy” products. You know, those products that are old and, some cases, decrepit, but that our customers just love to keep around. They are comfortable like a well-work pair of jeans or broken-in shoes. But these products are based on old technology and we now have new platforms, enhanced capabilities, new UIs, etc. that should entice our clients to move…but some of them are stubborn.

So what do we do with these products that still bring in revenue (mostly maintenance, but some transactional)? They bring too much revenue for us to simply decide to throw that away (especially in this time of economic upheaval) as we fear those stalwart clients will move to the competition. And our new offerings, although more powerful, are scary in just those additional capabilities!

There are a few things that we have to look at for those products.

1. First, to borrow from the medical profession, do no harm. This means that our current clients must feel they are not in a dead end – even though the product itself will not be updated. These users like the product as it is, so we need to work with them to determine why it is still the best tool for them. We need to see if this is a niche that we need (want) to address with an offering, perhaps a modified version of an existing, high capability offering.
2. Second, we need to get these clients to move to something that we will want to support and augment in the future. We need to make this transition as painless as possible both from tool migration and from usage perspectives. Note that I states “as painless as possible” as it is often difficult to make this painless. Sometimes the artifacts do not migrate properly between the tools and require manual changes, sometimes the user experience is different. In either case, there will be some pain. From a tool perspective, the goal is to make sure that not information/data is lost in migrating the artifacts and to document the migration caveats. From a usage perspective, we need to document the changes in the way the tools look and in the way standard or common tasks are accomplished. This is where the user-centric design teams are very important. In all cases, we would want to consider services to help these clients including consulting, training, and pre/post-sales support.
3. Third, we need to arrange the two previous points so that our development, maintenance, and support costs are minimised. These are legacy products and are typically not expected to be a drain on resources. We also want to be able to move the resources from these products to our strategic offerings (which should be the migration targets!). Although this is not directly related to our clients, we can’t expect them to stay on the old, comfortable applications forever and, at some point, all these resources will have to move.

So how does this translate into actual plans and activities? This is where knowledge of your products and clients comes into play – and this is what I have to figure out for my products! I don’t yet have an answer, especially not a generic one. But I may just come back to this blog to let everyone know…