Optimize Change: Re-platforming and how to do it effectively

John Zilch is the Chief Product Offer at Zentitle and founder of Breakthrough Ventures where he provides world-class PM expertise to high-growth companies. He has over a decade of experience steering product strategies at industry giants like Intuit, Virgin Pulse, and SugarCRM. John is also a profession of product at Bentley University and Providence College’s MBA program. Check out his book “The Quality Level” on the art and science of crafting exceptional products.

Looking to take a giant step forward in your career? John is offering four virtual Product Management 3-hour workshops in May on strategy, discovery, productizing, and how to product launch. Use discount code SKIPLEVEL and get 20% off each class. Visit www.pmlevelup.com for more info.

Some takeaways from our conversation:

1. Companies try to re-platform (1) when the tech stack or codebase is decaying and the engineering team wants to get out of it, (2) integration of software after acquisitions or (3)

2. Re-platforming comes with many risks and opportunity costs including the amount of time and effort to re-platform vs. value-added to customers and the business.

3. <Before deciding to re-platform vs. making improvements to the current system, ask whether it is worth it. If this investment kicks off tomorrow, how long until you are able to create value for clients? Will customers leave for something else in the several years you’re going to spend rebuilding your core platform? What is the business risk?

4. If re-platforming has to be done, be creative and consider a hybrid approach, or phasing your way into it. Is there an opportunity to rethink the front end without changing the data layer? Move to a different service layer in isolation?
   
   

Can you tell us a bit about your product experience?

I actually started my career in project management but upon joining my first software company - Intuit - I learned of this cross-functional, impactful role called Product Management. That was 12 years ago and since then, I’ve been fortunate to work at some amazing software companies on really interesting products and with really talented teams. In 2022, I started at SugarCRM and led a complete strategy pivot for my product line that was quite successful.  This year I set out to do this at scale and help more companies through my advisory firm, Breakthrough Ventures. I’m currently advising a company build out a new product line on top of their core offering and it’s just so much fun.  I’m blessed to be able to do what I do.

Can you talk a bit about re-platforming? What is it, what is it not, and why is it important?

Of the several tech companies I’ve worked at since starting in product management, each one has attempted to re-platform. By re-platform, I mean build a brand new product - along with tech infrastructure - to migrate its customer base to. I think it’s dangerous and I want to share what I’ve learned because it’ll help product and engineering teams make sound decisions. As a spoiler, I’d recommend companies maintain a position of not re-platforming and try to talk themselves into it. Not the other way around.

How do you define the strategic goals of a re-platforming effort?

That’s a really great question. I feel the goals can vary. Most often, it’s due to a decaying technology stack or codebase that the Engineering team wants to get out of. They’ll want to build something new and correct some mistakes and use newer technology.  

I’ve also seen cases where companies acquire a few companies and ask “Wouldn’t it be cool if all of these services we own lived on the same platform?”. It sounds really good on paper but can be very difficult to pull off.

Lastly, it might not be tech debt the team is trying to get out from under, but product debt. Years of feature factory work has created a monster of a product with too many bells and whistles and the team wants to move to something simpler. The inherent danger in releasing too many features, of course, is that a few users begin to use these features and now you have to deal with retiring or migrating that feature to the new platform.

How do you foster collaboration between product and engineering teams during a re-platforming initiative?

Well, I’d say the most collaboration has to start with the first question “Should we do this?”. It’s really tempting to jump into this project. I’d provide three cautions though.

1. It will not be as easy as you think. There will be many nuances of the old platform that you’ll look past in planning out the new one.  Sometimes, those are just small bandaids the team has placed over the old platform. While that may sound like a house of cards that is fragile and shouldn’t be messed with, I think that’s the point. Many hours have gone into shaping that product, maybe even hardening it over time. So, as you move to something new, you’re essentially starting from scratch.

2. You are creating a competitor to yourself. The cool kids may say you’re “disrupting yourself” but I’d argue there are ways to do that without undergoing a full re-platform. It’s really vital that you understand you will be taking on a lot of the work a competitor would be taking on. Of course, you’ll have an advantage of experience and a customer base to lean on, but you will be still facing a lot of the same barriers to entry a competitor would.

3. On that last point, if the new platform requires a customer migration, you’ll probably want to build the migration tools too. If you don’t, you’re asking your customers to dedicate their resources to making the migration. That is risky. Naturally, your customer will ask “If I am switching to something new, should I check out other vendors?”. Why invite that question?

What strategies do you use to manage risks associated with re-platforming, such as potential disruptions to existing services or data migration challenges?

There are a lot of risks. Outside of the risks I mentioned earlier, there’s another risk that you’re spending resources on achieving product parity that could be spent doing something more useful to customers in the short term. Depending on the magnitude of the offering, count on this project taking years, not months. So you have to weigh the opportunity costs. As mentioned earlier, it’s also critical to think through all of the nuances for the new platform and where you might miss something that disrupts a customer’s success.

"Will customers leave for something else in the several years you’re going to spend rebuilding your core platform? Or, will they leave you if you don’t refresh your tech stack and/or experience?"

How do you balance the need for innovation with the risks involved in making significant changes to the existing technology stack?

That’s a great question. Innovation, even in terms of simple updates, are critical to maintaining performance standards with your product. That said, is there a way to swap a part of your current platform versus a full redo?  

As an example, I was at a company that had three acquisitions with some synergies and overlapping functionality. We set out to build a new platform to support all these customers together. It made sense on paper. We basically had three customer engagement tools, each a different communication channel. We had an email product. We had a text messaging product. We had an in-app messaging product. In each tool, all built by different teams on different platforms, customers would manage audiences and campaigns and view analytics. On paper, the logical play was to combine these tools into one given the overlap. However, in reality, there were so many idiosyncrasies across the products that they became less similar as we rolled back the layers.  

On the surface, it sounded great. We’d be in a position to cross-sell different features and an opportunity to refresh the technology and the user experience. Well, that rebuild was on its fourth year when a new CPO canceled the project.  Instead, we moved our resources to fixing problem areas within the legacy products. It worked. We pleased many more customers by fixing their current offering versus trying to build a monolithic new platform for everyone. Specifically, rather than spin our wheels rebuilding the platform, we reused the data platform for our in-app messaging tool to speed up the performance for our text messaging tool. Customers loved it. It was a hybrid solution, in a sense. Improving a component of one of our products was much easier and provided value to customers in a shorter time frame.

Can you share examples of key performance indicators (KPIs) or metrics you use to evaluate the impact of the re-platforming on the product and user experience?

I’m not sure if these would qualify as active KPI’s, but I think there are three groups of metrics that teams should focus on in deciding to re-platform.  

The first is time to value. If this investment kicks off tomorrow, how long until you are able to create value for clients? What about value for your own team?  

Then, I think that has to be balanced with cost savings in the short and long term.  

Lastly, what is the business risk? Will customers leave for something else in the several years you’re going to spend rebuilding your core platform? Or, will they leave you if you don’t refresh your tech stack and/or experience?

How do you ensure a smooth transition and adoption of the new platform by both internal teams and end-users?

Very clear communication around progress and milestones. What are the phases of the product? What is being asked of each team? Of customers?  How are we managing customer communications during this time? While re-platforming may sound like a necessary technical endeavor, try to create some buzz around its benefits and get people (internal and external) excited about the future. It’s easy to put our heads down and stay focused on the work, but if you’re going to re-platform, make sure you’re keeping folks apprised of your progress and the value.

Reflecting on your past experiences, can you share any lessons learned or insights that might be valuable for our readers on re-platforming initiatives with their engineering teams?

Consider a hybrid approach, or phasing your way into it. Some of the best software implementations are done on top of an older platform versus trying to build something from the ground up. Is there an opportunity to rethink the front end without changing the data layer? Move to a different service layer in isolation? Be creative and try to do it in pieces. It requires more creativity but it might be a successful compromise to get most of what you want over time. 

Sign up for the Skiplevel newsletter to get more content like this straight to your inbox.

Want to feel more confident in your technical skills?

Become more technical in just 5 weeks, without learning to code! We also train teams! Find out more at skiplevel.co/teams and book a call with me to get started.

Skiplevel is a program that helps product managers and teams become more technical without learning how to code.

Learn more about the Skiplevel program ⟶

Connect with Irene on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.