The Minimum Viable Replacement Framework: A new approach to replacing old systems
What I learned from burning through $20M of FedEx's money, and how you can avoid your initiative from turning into an exploding watermelon
Are you engaged in a digital transformation initiative, working to retire systems as part of a merger and integration project, or sunsetting a legacy product?
If so, then take a moment to learn about a new concept, the Minimum Viable Replacement before you potentially waste thousands of hours and millions of dollars pursuing the wrong strategy for retiring and replacing existing systems.
I developed the concept after three incredibly painful years of stumbling through a multimillion integration and retirement project of a product used by hundreds of thousands of users around the globe.
New to agile, we embraced the MVP gospel being preached by our consultants, only to discover that retirement and replacement projects are the absolute opposite of an MVP, and require an entirely different approach.
Minimum Viable Replacement to the rescue
The Minimum Viable Replacement framework addresses two key challenges that plague people who attempt to retire legacy systems and migrate their existing customers onto new products or platforms:
It stops the confusion caused by trying to apply the Minimum Viable Product (MVP) concept to retiring systems. Conflating the retirement of an entire system with an MVP is the same as conflating a brick with a finished house or a bike with a car — or a slice of a pie with the whole pie. There are similarities between the two, but good luck convincing your car, home, and pie owners to trade them for a brick, bicycle, or slice of pie.
It provides a framework for architects, UXers, product, and project managers, to tackle the difficult problem of replacing systems that serve all sizes of customers in multiple geographies across multiple markets.
What is it good for?
In the world of agile, everyone talks about MVPs, the smallest set of capabilities required to meet a segment of your customers’ needs. The concept popularized by Eric Reis in the book Lean Startup is great for companies entering an entirely new market where they lack existing products and customers.
An MVP is simply a validated hypothesis that explains that a certain minimum level of functionality is enough to meet a specific market segment need.
The key to a successful MVP is to solve a specific market segment challenge first, instead of trying to solve multiple needs across multiple markets:
The problem: Replacing an existing system is the exact opposite of an MVP
If you’re trying to retire a legacy platform — instead of having the luxury of just solving very specific customer segment needs — you need to solve the needs for every customer segment using your software!
Imagine your company started 20 years ago serving a few small customers in one specific market segment and one country. Now you’re serving multiple different industry segments, across multiple countries.
To top it off, about 100 (or .01%) of your customers drive the majority of your revenue from a scalability and functionality standpoint.
Instead of trying to solve the needs of just one small segment, you now have to deliver 20 years worth of software development for thousands of customers across multiple countries and segments to retire the system — the exact opposite of an MVP. The classic agile product-development concept of building a skateboard, bike, car analogy of product development completely falls apart. Since the majority of your customers are already paying you for a car, they aren’t about to trade down for a skateboard.
As you’re trying to replace your old systems, customer, regulatory, and competitive demands are forcing you to enhance the existing systems as you’re trying to replace them. Consequently, delivering an MVR is typically more complex, costly and risky than launching an MVP. You can destroy your company if not done right.
Comparison between MVP & MVR
MVP Focus= Acquire New Customers
MVR Focus= Avoid Breakage 1st, Acquire new customers 2nd
The Solution: Use the Minimum Viable Replacement Framework
Embracing an MVR won’t make the process easy or guarantee success, but it points you in the right direction. Simply put, an MVR is the total of all the MVPs required to migrate existing customers to the new system with minimum breakage and retire the old version.
Replacing or enhancing all of the existing features/capabilities required to retain your existing customers.
Providing the capabilities, support structures and inducements required to migrate all of your customers to the new platform, plus any additional work required to retire the system. Migrating customers to the new platform can take many times as long, and cost much more than the new platform.
Replacing and retiring systems requires different approaches
When you’re dealing with an MVR, you already know there’s a market. The question is, does your new product meet and exceed the value delivered by the old product? This requires different approaches.
If the goal is to retire a system, focus on your extreme/edge case first
Especially if you’re in the B2B market, you can’t
Retiring systems takes longer and costs more than you expect
Typically, most companies underestimate just how complex it is to support their largest customers, and just how little concern they have for your desires to retire your systems. This leads to massively underestimating both the amount of work and time required to get their largest customers to transition.
Questions to kickstart your Minimum Viable Replacement
The challenge organizations face when they’re attempting to modernize and/or retre existing systems, they don’t know what questions to ask and where the risks are. Instead they discover them late in the process, when their project timelines and costs explode, and the value sinks.
To help you avoid that fate I’ve created:
The Watermelon Preventer: In just a few minutes, you can quickly identify key risks and communicate them to your leadership, or as a leader, identify issues before they blow up your company and career.
Risk Mitigation Guides: It’s a list of the 60+ questions I wish I had ahve known to ask and guidance on how to address the challenges they highlight.
Sign up and get access to all the tools and insights you to successfully modernize and replace your existing systems.
Good luck!
Replacing existing systems is incredibly difficult, given the many complexities and competing demands. While I could write many more words about the many challenges, tips, and tricks I’ve learned over the years, that would result in a book. In the meantime, I hope this article has been helpful to you.