Retire a legacy product I: jobs, people, complexity, and desired outcome

This is the first post of a series where I’ll discuss 4 bits and pieces of retiring a legacy product:

• I — What does it mean, esp. in a B2B setting (Jobs, involved people, complexity level, desired outcome)
• II — Internal buy-in (From individuals to mid-managers to leadership back to individuals)
• III — Accounts and contracts (Handling various contracts, collaborate with stakeholders)
• IV — The transition period (Customer care, product collaterals, continuous buy-in)

Since Q4 2023, I’ve been drafting and pushing forward a plan to sunset an ancient legacy solution from our product suite — a 16-year-old B2B software. There are hundreds of B2B customers using it; half of our organisation knows the solution like the back of their hands; the replacement solution is the stepson whom most don’t look straight in the eyes. Never said it was easy, but it’s going forward.

Removing a legacy product doesn’t sound sexy. It doesn’t get as much attention as building an AI that runs a workflow which can pop cash out of a fax machine. It's often treated as a cost-reduction exercise:

Delete the code. Eliminate support efforts. Move on.

In fact, in B2B, it can be a gift for profitability:

• If there’s a new solution as a replacement
• If the replacement offers additional functionalities
• If there are further non-ACV (Annual Contract Value) potentials

Different levels of complexity when retiring a product

Imagine Instagram getting rid of a video format

Vs.

SAP stopping a service, or,

Devs keeping legacy running on a life sustaining machine

Vs.

big boss unplugs a beloved but unprofitable feature, or,

A B2C App new UI that takes 3 mins to get used to

Vs.

a B2B tool changes the colour of a button, the entire customer base needs to be retrained…

First face the fact that removing a product means differently across organisations, and creates different levels of complexity. Some entail purely technical work. Some can trigger internal turbulence.

Low — Eliminate and communicate

Products are different, but these 3 fundamental tasks we all have to go through:

• Remove the tech dependencies, clean up the code and database, update the infrastructure, etc.
• PMM (Product Marketing Manager) drafts a communication guideline. All customers are informed before the EoL (End of Life) date.
• Lead users through the transition — back up data, try out alternatives, delete accounts, etc.

I’ve spoken with heaps of PMs who have experienced this “green state”. It happens commonly in common companies.

Mid — Introduce alternative

When retiring a product brings the introduction of a new one, the level of complexity increases.

In the case I’m facing, we’ve been developing a new solution to a stable and scalable level. This solution solves all the problems the legacy can do, and offers add-on values, e.g. a mobile App and BI. It’s not based out of thin air that the new licence should cost more.

To sell the new licence, Sales must come in, believe in it, and have the ammos to follow through. Detailed internal buy-in will be discussed in a later post, but to summarise:

• Learn the deal structure: to win the buy-in of people who own the P&L, it would be a terrible idea to not understand how current deals are structured. There’s a pricing calculator for every SaaS. Understand what drives ACV and what else is there, e.g. volume/usage/service/content, etc.
• Know the current contract situation: to call for a Sales meeting, to say that you’d like to end some contracts, you better know what types of contracts exist and how long each of them is running. PMs don’t usually have access to Salesforce. Ask for a data export and do some homework.
• Demonstrate the revenue potential: lay out all attractive product benefits. Be factual and honest. Small improvements won’t make either Sales or customers move a finger. Only show the real beef.
• Run the enablement errands: talk to PMM and Legal, get the customer communication guide; agree on a clear and written EoL date with senior leadership; produce a target customer list. These all help Sales convert customers effectively. “No, Product Managers are not Project Managers”, some might say. You either want it to happen or not. Focus on the outcome.
• Accumulated trust: ideally there’s already a mutually respectful and trustworthy relationship between you and Sales colleagues. If not, perhaps work on that trust first.

High — Migrate data

It begins to get incredibly hairy when customer data must be transferred to the new solution. I’ve never heard of any company that builds a new solution which looks exactly the same as the previous one.

Why would anyone do that, Imgflip.com

But when migrating customer data, we risk conveying the message of “There is 1-to-1 mapping and complete feature parity.” This creates massive room for future complaints.

If you work with a highly disciplined Service and Consulting team who are at an even level of knowledge and constantly on top of things, there’s a chance for proper customer education. If not, consider the what-ifs of not offering data migration. In my case, data migration unfortunately cannot be bypassed.

To spice things up, on top of the standard software solution, your customers may run custom workflows. Imagine if Instagram refuses to let you send a voice message, so you whack Whatsapp voice message with a workflow that pumps voice messages in your Instagram. You call it workaround. I call it madness. Potato potato.

Now I’ve got to bring those custom workflows into the new solution as well.

• Still seek a standard solution: if a workflow is what customers need. Turn it into a standard solution. It takes time, but likely you’ve already prepared. In my case, all the customer interviews had already led me to invest in workflows. The tickets are even ready. All I had to do was pull them higher in the backlog.
• Categorise their workflows: ask for a data export of all the custom flows, do an easy Excel pivot, and rank them per type, e.g. event notification/assign a task/request info. This gives you a realistic picture of any factual gap in delivery.
• Cluster customers: there are customers with heaps of data and custom flows. Don’t start with them. Tier customers based on their data and complexity of flows. When you’ve migrated the easier Tiers, everyone will have accumulated enough knowledge to handle the more hairy ones.

Mayday — Convert contracts

In B2B, every contract counts. In my case, over 50% of legacy deals end in an upcoming year, which means stopping renewing those contracts and winning new licences. Never said it was easy — customers don’t like to change. “Never change a working system” can be both the success factor and blocker of many B2B businesses.

But there’s a Mayday situation where a certain percentage of legacy deals still have a good couple of years to run. To see this through before my own retirement, we need to convert them proactively. For that, Legal is invited in the room and C-level in the case of giant customer escalation.

There’s one thing missing from the green-yellow-red graph — convince customers, cuz it doesn’t add to the complexity of retiring a product, and it doesn’t change whatever you, a PM, do:

• How do you define success? Customers can hardly be convinced of such a change. 80% will feel forced onto it but churning is more painful (B2B success factor). 20% will fight until the last minute and complain about everything in the new solution.
• In B2B, we convince customers with things in parallel: product, implementation, and service. However closely we work with Service and Consulting colleagues, they play a bigger role in introducing the solution directly to the day-to-day users. What we can do is deliver all the ammo to them. More on that later in “internal buy-in”.
• Since we have weekly direct conversations with customers, any pain point usually won’t come as a surprise. As mentioned above, you’ve likely already gathered the same pains, prioritised them, and even wrote the tickets. However, it’s not a good idea for PMs to interview customers when they aren’t familiar with the new solution yet. They’d be lost in the new interface and not give valid feedback even if they wanted to. I’ve had a few of those interviews where the customers went a bit quiet. Unless it’s the onboarding experience that you seek to improve, then get in there early.

Lastly, when do you know you’re ready? Ready to retire the product and get the new solution ready?

Let’s be realistic. Customers and our stakeholders will never see our products as perfect. Neither do I. However, the goal is to get a stable and scalable version of the product out of the door and start from there, as opposed to closing the door and developing for 5 years for failure. We are not going to stop optimising it. Customers will not stop complaining about it. And it goes on.

In my case, we have started selling the new solution in parallel to the legacy for a while. It allowed me to gather incredibly valuable feedback from the first batch of customers. The rest is product management — analyse, group, prioritise, tackle. The moment I saw the most critical issues had been tackled, I started drafting this plan.

More to come on

• II — Internal buy-in (From individuals to mid-managers to leadership back to individuals)
• III — Accounts and contracts (Work with Legal, Sales, Service and Consulting)
• IV — The transition period (Customer care, product collaterals, continuous buy-in)‘

Stay tuned and let me know if you’d like to exchange experience and learnings!