The Release Train at Re-Platform 9¾ (Years Until It's Complete)

If there’s one word that sends shivers up the spine of any product person (as well as most of the rest of the organisation), it’s RE-PLATFORM. What does that mean? Well, here’s my definition:

Re-platform (verb): To spend months or years migrating software from one technology stack or infrastructure to another, at much expense, to provide a system that looks and feels functionally identical to the original.

Wait, that sounds rubbish! Why would we do that?

Why products need to be re-platformed

There are a number of reasons why you might need to re-platform your product and, in many ways, you could anticipate that the likelihood of needing to do this tends to 1 over time. This is because software is complicated, products involve trade-offs and, quite frankly, technology changes over time. I like to group the reasons into three broad categories, which intersect:

Technical reasons: Stuff written in old programming languages, or using out-of-date libraries. Legacy, on-premise solutions. Unscalable architecture. Impossible-to-maintain codebases. Security vulnerabilities. Things that make it hard to develop and deploy software at scale.

(And, sometimes, shiny new tech that the VP of Engineering is making eyes at).

Operational reasons: Stuff that is falling over all the time, leading to dissatisfied customers and stressed-out support people. Systems don’t scale well, meaning every new large customer is both a source of excitement and fear that everything will grind to a halt. Your CFO just realised you’re paying 5 times as much as you should be for cloud computing capacity.

Business reasons: You’re unable to support the functionality that your customers want, either because your system is too slow (see above) or because you’re fundamentally unable to offer them. A merger with another company means you have two of everything and need to consolidate. You want to start selling into a new jurisdiction and can’t until your platform meets certain regulatory requirements, which require everything to be reworked.

Everyone has their own re-platforming war story, where they had to spend 18 months rebuilding something without releasing any new value to customers along the way. Some companies seem to be re-platforming all the time. We can assume that, even if you haven’t had a re-platforming project yet, you’re going to have one eventually. How do we make the best of it?

In most cases, re-platforming is started WAY too late

I’m going to be punchy here and say that, in the vast majority of cases, re-platforming projects are a failure of strategic planning within an organisation. There are certainly going to be cases where this isn’t true; for example, if an important vendor goes bust. But, very often these re-platform projects are the result of constantly kicking the tech debt can down the road. And I get it… who wants to spend all their time fixing stinky tech debt when there are all these features to build?

Back to my definition, with some additional emphasis added:

Re-platform (verb): To spend months or years migrating software from one technology stack or infrastructure to another, at much expense, to provide a system that looks and feels functionally identical to the original.

Who wants to spend months building something that looks the same? Our customers need stuff and they need it now. So we keep building the stuff until the rivets start popping out of the gas pipes and, eventually (finally!) we get to the point where the pressure has built up so much that we have no choice but to get into it. And, by that point, there’s a lot of work to do.

Ultimately, the decision to re-platform is a always business decision

If we consider the three intersecting categorisations above, we could probably argue about what falls into each category, and whether something should be considered technical or operational. Actually, it doesn’t matter. The decision to re-platform, as with technical debt initiatives, is a business decision.

It starts with a narrative. It starts with evidence. Very often, product and technology leaders are completely unable to sell this kind of work to the rest of the leadership team until it’s way too late. Eventually, it becomes irresistible. If product and technology leaders did a better job of framing the technical challenges in business terms, they might be able to get started sooner. After all, it’s generally better to change the oil in your car before the engine seizes up. We need to sell this message in a timely fashion and have a defence against the inevitable pushback.

But… how do we get started? Or how do we continue?

This is where things maybe get contentious. Time and time again, I’ve seen re-platforming initiatives framed as projects. They get a team together and they produce the Gantt from hell with waterfall after waterfall. They say it’s going to take 18 months, and then we’ll be done! Everyone says, for some reason, “OK” and the work starts. It never takes 18 months, of course, but it feels good to get started. 12 months later, they’re a third of the way through, half of the developers have quit in frustration and the commercial teams are banging down the door because customers are complaining that the platform is still as broken as it was before (because we didn’t release anything yet) and hasn’t had any feature enhancements in months

But… re-platforming is a product problem, not a project to be executed.

It’s very tempting to treat re-platforming as a big-bang project that will eventually release value, but our customers don’t care about our technology. This forces us to accept a couple of uncomfortable truths:

Making life easy for developers is desirable, but not the most important factor

It might feel more efficient to get all the database work done in one fell swoop (that takes 3 months), or to get different teams to look after their own areas, but that’s waterfall thinking. We need to challenge our developers to work with us to identify vertical slices, not horizontal so that we can deliver value incrementally. There may be resistance to this, but I am convinced that this is the better approach in the vast majority of cases.

We might accept some duplication and inefficiency in the meantime

Many companies treat re-platforming initiatives as big-bang projects with a specific cut-off point. Come the 17th of July, we’ll pull the big lever and everything will be up and running on the new stack, and we’ll immediately turn off the old one. This puts incredible pressure on the tech and product teams, in many cases for features that barely anyone uses. Instead of that, we must consider swapping out bits at a time, even if we have to have two systems running in parallel for a time. We can release value incrementally, and turn the old stuff off when it’s all done.

We’re supposed to be good at prioritising

Product managers live and breathe prioritisation. So, rather than accepting an 18-month software migration that ends up looking exactly the same as we started, we should do our jobs and prioritise customer and business value. There are going to be parts of the system that are creaking the most, or used the most, or things that will break sooner. Let’s fix those things first, and quickly. But, we don’t have to fix everything at once!

And, regarding that “looks exactly the same” thing. There’s generally no reason that we can’t unlock some customer value along the way. If there are important use cases or enhancements that can be delivered during work on particular parts of the platform, we should consider putting those in! They have to be legitimately important, but if we’ve just sped up data access for widget X by a factor of 100, we might consider showcasing that straight away rather than waiting another 12 months.

But we’re already 12 months in!

If you’re already mired in your 18-month project (and, most likely, starting to plan the next one) then this might all sound like pie-in-the-sky thinking. And, sure, if you’re too far down the rabbit hole then it might actually be easier to just finish off as quickly as you can so that you can forget about it and move on with your lives. But… I remain convinced that, in a surprisingly large number of cases, it is possible to hit the next stage gate or milestone and think differently about what your next increment will look like. You may make the decision that it’s not feasible but don’t default to that position. Investigate it and make a decision based on facts.

Oh, and by the way, even if you do get the job done, absolutely don’t forget about it and move on with your lives. You’ve done the hard work once, but the new stuff is going to start to rot soon too. All technology does! If you don’t want to be caught in the same trap 12 months from now when the next thing breaks, have constant conversations with your Engineering counterparts, make sure you have a narrative to sell to the leadership team, and make sure you intercept it early next time.

---

Other stuff

Here are some other bits and pieces I’ve either done myself or seen around the web. I’m trying to get better at remembering useful things I see, so I can share them with you!

• I did a podcast episode with Julie Starr! Julie’s a renowned coaching and mentoring thought leader who has written numerous books on both subjects. I was really keen to speak to her about the differences between coaching and mentoring, how to measure the impact, and whether you need to be a functional expert to succeed. Check the episode out here.

• I also spoke to Gabrielle Bufrem. Gabi is a product leadership coach and advisor who comes well-recommended by Marty Cagan and loves talking about improving product teams and the importance of a really good product strategy. We went deep into all of that, and you can check the episode out here.

  • You can also check out my episode with Marty Cagan here, which we recorded shortly after Empowered came out.

• My friend Saeed Khan and I are looking to put together a cohort course on Maven for B2B Product Managers. We believe that B2B Product Managers often struggle to rationalise the best-in-class product management advice, and want to help people survive and thrive in B2B organisations. We’re assessing interest right now so, if it does sound interesting, please fill in our survey!

  • You can also listen to my recent-ish chat with Saeed right here.

• I recently contributed to the Airfocus “The Impact of AI On Product Management” report, although they only used one quote 😅. It’s an interesting report though, so go check it out.

• I saw this interesting report from SaaS Capital about SaaS retention benchmarks - it’s really important for PMs and product leaders to have an understanding of this stuff, rather than just shipping features, so I recommend having a read.

• You still have time to contribute to the Product Management Salary Survey by Product Academy, to help us foster a sense of transparency and enable us to have good discussions about pay.

Thanks for reading! Please drop me a line if you have any comments or would like me to cover anything in future newsletters. If you find this remotely useful, I’d love you to share it with your friends.