Retire a legacy product II: getting internal buy-in

When developing a product, we can iterate and pivot. However, discontinuing a product that hundreds of B2B customers are actively using is different. Once you’ve announced the news, there’s no turning back. You’ll have to press on, with whatever resistance and unforeseeable challenges. All your internal stakeholders know that. They’ll personally have to deal with the aftermath themselves. Thus getting internal buy-in for product EoL (End of Life) isn’t plain sailing.

This is the second 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.

Buy-in doesn’t mean you’ll have strong backing from the start. It means having a minimum viable crowd who kicks it off, while you continuously gain more buy-in.

Buy-in doesn’t mean you go straight up to the top of the rank and get the boss to top-down on everyone either. Smart people don’t need a directive approach. They need a purpose and follow through with the tasks themselves.

We probably all know the Double Diamond design model. The main idea is to first discover issues as broadly as possible (divergent thinking), then focus on the most critical ones (convergent thinking). Then open up to a wide range of solutions, and finally act upon the most suitable one. Here I’ve adapted it into a stakeholder buy-in version.

• Status quo: Speak to as many individuals as you need to have a realistic picture of internal concerns.
• Major concern: Categorise all feedback and address the most critical one with the key people.
• Emphasis: As the new solution gains more attention, communicate benefits and propositions to everyone.
• Buy-in: Nail an internal agreement. Anticipate further concerns.

Status quo

Start by establishing a baseline. All concerns and arguments against sunsetting the legacy or promoting the alternative solution should be uncovered first. Be brutally honest with yourself:

• Is any core product capability missing?
• Data migration issue?
• Are collaterals all in place?
• Concerns regarding existing contracts?
• Fear of customer resistance?

You’ll highly likely hear a great deal of complaints. That’s when you know you’ve done it right. In my case, I’ve spoken to every role that is involved in implementing the new solution, i.e. Sales, Service and Consulting, Devs. It took me 10–12 individual meetings to say that I understood the internal concerns. Depending on the organisation, it may take more or less. But the number doesn’t matter. The outcome is a confident evaluation of the status quo. Be realistic, you can still cease the operation if the product or the organisation isn’t ready. Otherwise, crack on.

PS, regarding product capabilities, there shouldn’t be any feature complaint that utterly surprises you, cuz ideally you’ve gathered enough first-hand feedback directly from customers and have planned or implemented solutions. If not, it’s time to review your interview strategy.

Major concern

You shouldn’t address all the problems of everyone. Unless you’re a chef making a salad that is sweet and savoury, spicy and mild, with and without meat(?) at the same time. As the Product Manager, just map all the feedback and focus on the end goal, for example:

Noise: “The new solution is different from the legacy.”

Profitable businesses don’t build a new solution just to look the same as the previous one, not even iPhone.

Education: “These features are missing.”

If they aren’t missing, rather it’s the stakeholder who can’t navigate, it’s a case of product education. Discontinuing a product means taking away the stability of both the customers and internal colleagues who support them. They won’t hop on product learning jolly and cheery. Give it time, but make it clear that they must catch up.

To-do: Customers don’t need those additional functionalities in the new solution.

Good to know. I’ll work on user settings.

Another way to map second-hand customer feedback is to examine which type of customers are they from.

Customers who started off with the new solution have no comparison to make. They likely focus purely on the functionalities. The hard evidence of anything’s really missing or not.

Customers who are asked to move from the legacy to the new are going through emotional and financial journeys. They have exceptionally high expectations of the new solution. Most of the negative feedback comes from them. And they drive and continue to drive your stakeholders’ resistance.

Now you have massive collective intelligence. Do the homework, and gather another meeting with the key people to address major concerns. You can already involve Senior Leadership if you feel ready. You will not convince any group 100%. In the German parliament, the winning party doesn’t even have a majority vote. So make a start once you’ve addressed the key concerns from the key people.

Emphasis

At this stage, everyone knows you’re serious about retiring the legacy. You’ll notice that many have accepted the eventuality and begun to dig into the new solution. Detailed questions about functionality will fly in from everyone, everywhere, DM, email, unannounced calls, etc. Don’t treat this as a chore, treat it as your opportunity to emphasise the product proposition, improve your collaterals, and resolve concerns as they come.

Bonus for ambitious PMs, particularly during this phase, LOOK AFTER YOURSELF (sorry for shouting). You’ll have encouraged a couple of nervous Consultants and answered a couple of aggressive Support questions per day. Some likely think you’re delusional and blinded by “some vision”. The only truth that matters is you believe in where the product and the business are going. In 2 years time, you’ll only remember the result.

Buy-in

It’s time to agree upon a definitive EoL date with Senior Leadership. This means Product Marketing can start drafting communication guidelines, and Sales can begin to use it to reach out to customers. Water will be under the bridge and the train will leave the station.

Safe to say that it’s unfair to expect Senior Leadership to have an overview of product readiness or technical feasibilities. But in the case I’m facing, the legacy represents everything against our strategy and vision. Good riddance to be. They know it. I just need to prove that it should be now.

Urgency: There’s a good percentage of legacy contracts will end in recent years. In our line of business, contract renewal discussions should start soon. If we let those contracts renew as it is, we are stuck with the legacy for the tenure of the new contracts.

Scarcity: Currently, our Devs spend approximately 8 hours a week to keep the legacy running — without building anything new, only maintaining. As the velocity of the technical debt accumulates, the figure will easily go up 2 hours per year. So we are better off cutting the losses early.

With Senior Leadership, you could have used all the principles, data, and testimonials from King Charles and Taylor Swift, but still didn’t achieve an agreement right away. Sometimes it’s better for them to keep options open than to make a decision. Just gather their concern and try again.

Try again: When you try again, show powerful materials based on what’s most valuable or critical for them, which is not always the same as what you or what the people have perceived. When they comment on or challenge your plan, they show you their concerns. Make sure you have your head screwed on, don’t defend, expand the conversation a little, until you understand the root cause of their concerns. Just like carrying out a customer interview, isn’t it?

Final words.

As much as an organisation should work towards one direction, tunnel visions and echo chambers do exist. Stakeholders will contradict each other and even go back on their words. Remember the job is not to fully convince everybody, but to be enough to get the ball rolling.

Every stakeholder is different. Sales will give you less push-back if they see the revenue potential; Service and Consulting will support you more if the customer transition is easy; Devs will relax more if the scope is clearly defined, etc. Knowing what they want is important. Speaking their language is valuable.

As the Product Manager, you shouldn’t anticipate any flowers at the end. You’ll be lucky you survived the strong current against you. Look into mental well-being exercises. Slow down for one day if you’re tired.