82: Replatforming the cash cow

I’m writing about 100 things I’ve learned the hard way about product management. You can catch up on the previous entries if you like.

Recently people all seem to be encountering the same problem. Their engineering teams are choosing to work on projects that make them look busy, but which don’t actually move things forward. What they’re usually working on is a convoluted — and arguably doomed — attempt to replatform a legacy ‘cash cow’ product.

In this article #

• Introduction
• Why are these projects doomed?
  • Lost tacit knowledge
  • Hanging around like a bad smell
• Why is this happening?
  • Remind me who this benefits, again?
  • User needs are not static
  • Look busy, senior management is coming
• What’s a better alternative?
  • The problem with inside thinking
  • Fight uncertainty with user research
• Listen to the signals

Why are these projects doomed?

Lost tacit knowledge

Replatforming a legacy product runs several risks. The first one is that you may not have the benefit of the tacit knowledge of its original developers. Tacit or implicit knowledge is difficult to articulate, and so is more difficult to transfer to others by means of writing it down or verbalizing it. This can include personal wisdom, experience, insight, and intuition. This is why it’s difficult to be told how to learn a musical instrument — you have to physically experience it for yourself.

Implicit in a legacy code base are are a bunch of business logic workarounds and hacks. These have accumulated over the years to make the product better fit the reality of how people need it to work. Chances are that the reasoning behind each of these little tweaks and fixes is lost to history, is probably not documented, and the original developers may no longer be around to provide context.

As soon as the current team attempts to rewrite the product on a new platform, they run the risk of unwittingly losing all this implicit business logic. They will progressively realise this as they find themselves having to re-implement all the missing little behavioural fixes.

I was chatting to consultant Tim Meadowcroft about this topic recently on The Pig Wrestlers. To try to avoid this problem, he habitually documents his failed experiments in code comments:

“Some of my routines have got large chunks of code to tell people, ‘You might think this would be faster if you did it like this. Please. I tried it. I tried this, I tried that. I’ve tried that. Here’s seven ways I tried. The one I’ve left with, it happens to be the fastest. On a chip that comes out five years from now, one of those other methods might be better, but at the time it wasn’t. And here’s my reasoning why.’”

Tim Meadowcroft

Hanging around like a bad smell

Another significant risk is that the legacy product will probably linger on until the rewritten product does 100% of what the legacy product does. From painful experience, this will take far longer than anticipated and may never actually be achieved.

This then leads the to paradox of continuing to expend effort to maintain the legacy product alongside the work on the ‘new’ product, which is itself has minimal take-up as few customers will want to move to something that is perceived to do less than their current product.

Why is this happening?

Remind me who this benefits, again?

Replatforming projects are often to scratch an organisation’s own itch. The main perceived benefits of moving to newer technology are reduced maintenance overheads and a possibly optimistic goal of erasing all the product’s accumulated technical / design debt.

However, teams often make the mistake of assuming that current users will also be as delighted by the product’s face-lift as the team developing it. They won’t.

Migrating to the rewritten product will mean effort and disruption for your customers. They’ve built up muscle memory with the legacy product, so moving everything around and changing user interface behaviour will inevitably be disruptive to their workflow. And if the rewritten product (at best) does exactly what the old one did, they’re seeing no benefit for that disruption. There’s nothing new in there for potential new customers either.

User needs are not static

Replatforming also makes an implicit assumption that user needs have remained static since the original product went out to market. Chances are that what users need to do has evolved. Because they’re locked in to your product for some reason, they haven’t yet jumped ship to a competitor. So they’re increasingly having to work around the constraints of your legacy product. It’s a slow, creeping change, and the users may themselves not be aware it’s happening.

Look busy, senior management is coming

Sometimes, replatforming is a desperate attempt by an embattled engineering team to protect their future. Forever associated with a burning platform that consumes 80% of their effort to maintain, the poor developers are running to stand still. To short-sighted senior managers, they’re seen as the team that seems to be unable to deliver anything new, because the ongoing maintenance is revenue-protecting, not revenue-generating.

So they propose to deliver something big, new and shiny, and yet reassuringly familiar. Senior management buys in (“It worked before, so it should work again, right?”). And by doing so, they compound their problem because the old platform remains on fire.

What’s a better alternative?

The problem with inside thinking

Everyone recognises that something needs to be done to replace the legacy product, but nobody knows what it should look like. There will be plenty of opinions, but few of them will be backed by any hard evidence. And as we know, when it comes to opinions, the highest-paid person’s opinion will usually win. Often this will be, “repeat what worked before”. And so the death march to clone the legacy product begins.

More often than not, the companies facing this problem are not actively researching their users, possibly relying solely on feedback from existing customers via sales, pre-sales or customer support teams. This can trigger various biases, including selection bias (only talking to existing users, excluding the rest of the market segment), confirmation bias (only heeding data points that support the desired plan) and recency bias (placing undue weight on the most recent thing heard).

Fight uncertainty with user research

The elephant in the room is uncertainty. Often the inside thinking that gets people into this mess in the first place goes hand-in-hand with an aversion to admitting when they don’t know something. It’s easy to have an opinion. Unbiased evidence is much harder to find.

Organisations need to fight uncertainty with user research into both existing users and non-users in the target market segment. Establishing a healthy habit of frequent ongoing user research will discover insights, challenge assumptions and uncover new opportunities. Outside thinking relies on a willingness to accept that we don’t have all the answers, but we know how to find them.

Then with the benefit of that evidence, form a product strategy to create a new product (rather than simply a rewrite of the old one) that does as many as possible of the following:

• takes account of evolving user needs for existing customers (and provides them incentive to upgrade by solving more of their problems);
• opens up new market segments;
• defends market share against challengers ;
• takes advantage of newer technologies that may provide better capability (bigger building blocks) at lower cost than developing from scratch in-house ;
• resolves / side-steps problems such as maintenance overheads identified in the legacy product through better architecture (meeting internal needs).

Listen to the signals

A mature cash cow product is attractive to the business because it offers high margin returns for seemingly little effort. However, this is also a strong signal to start work to discover what the replacement product should be, while you still have the time to do so. Think of the cash cow product as providing the subsidy for the research and development of its replacement.

You can do this through user research and prototyping, by building it, and eventually migrating the majority of existing customers to it. Waiting until the current product is in decline and losing customers to competitors will place the company on the back foot when it inevitably happens.