“We need to retire the old system by X date, so what’s the MVP we can deliver by that date to replace it?”
“What?” you ask, alarm bells going off in your head.
“You know, the 20% of the capabilities that meet 80% of the customers’ needs. We can always enhance the system later. We’re agile, and we can’t let better get in the way of good enough, plus there’s a bunch of stuff that’s only being used by a single customer, so they’ll just have to deal with it, plus the new Web version will be much easier to use.”
And so begins yet another digital destruction, er digital transformation, initiative. As someone who’s witnessed multiple multimillion dollar agile release trainwrecks, I’m going to introduce you to the concept of Minimum Viable Replacement, a new framework to help you replatform and retire systems.
Minimum Viable Product vs Minimum Viable Replacement
Most companies are not startups, and instead spend most of their time enhancing and replacing existing systems to take advantage of new technologies and address competitive threats, not developing entirely new capabilities for entirely new markets, therefore MVP is absolutely the wrong approach for replacing legacy systems.
If your company has been around for a decade or longer, then you need to be thinking in terms of Minimum Viable Replacement 90% of the time!
Think about it, your company has grown from a small company into a much larger company over decades, with multiple products serving customers of different sizes and business units across multiple geographies and markets, each with their own specific requirements.
If you’re in the B2B space, your largest customers drive the majority of the revenue, and therefore get special features and customizations just for them, so rather than thinking about your largest customers as a segment, you really need to think of each of your ginormous customers as a key segment that will be very costly to walk away from.
And over those years, your software and other systems have been modified time and time again in order to meet the specific demands of your largest customers, fight off competitive threats, enter new markets, etc. Oh, and many of the people who made those changes have been synergized, retired, transferred, died, so no one even knows what all the systems do, and for whom they do it.
On top of that you will encounter the Paper Clip problem, where creative users, have figured out how to get your system to work in all sorts of ways it was never designed for.
And finally, even as you’re trying to replace your old systems, customer, regulatory and competitive demands are still forcing you to enhance the existing systems, even as you are trying to replace them.
As a result delivering a minimum viable replacement is typically exponentially more complex, costly and risky than launching an MVP, as you can destroy your company if not done right.
An MVR = multiple MVPs
For the purposes of this article, a Minimum Viable Product is simply a validated hypothesis 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 segment’s challenges first, instead of trying to solve multiple needs across multiple markets.
A minimum viable replacement is usually the exact opposite. Instead of having to solve the needs of a very specific customer segment, you need to solve the needs for every customer segment.
An MVR is the sum total of all the MVPs required to transition existing customers and retire existing systems. So not only do you have to potentially replace all of the existing capabilities in order to keep your existing customers happy, you have to get your users to migrate to the new systems.
Especially in the B2B space, where software applications are generally integrated into larger processes and ecosystems, getting customers to migrate often takes much longer, and is much harder than even replacing the core capabilities.
In addition, especially if you are in the B2B market, you cannot underestimate the importance of designing for the extreme use cases. Why? Because those edge use cases are often critical for your largest customers.
A good way to envision this is to think about a 100-story condo. The “regular” folk live on the first 99 floors with 12 foot ceilings, fairly standard bathrooms, etc. and pay $10K in rent annually. The 1% live on the 100th floor with their own swimming pool, heli pad, 40-foot ceilings, and all sorts of other crazy things, and pay $1M annually. If you design for the first 99 floors initially, and then get to the last floor, only to discover that 40-foot ceilings and a helipad are critical requirements, what’s the probability your design and architecture will support these “crazy” use cases.
Each of your largest customers, especially if you have done a lot of customizations, may need to be treated as its own segment with an associated MVP in order to successfully meet their needs.
In fact, you may decide to have two entirely separate approaches. Standard architecture and design for the 99% and entirely custom solutions for the 1%, but that leverage shared services whenever possible.
Typically, most companies underestimate just how much complexity they’ve taken on to support their largest customers, and just how little concern the largest have for your desires to retire your systems, which leads to massively underestimating both the amount of work required to replace the legacy capabilities required, but also how many years it will take to get their largest customers to transition.
Unfortunately, the MVP approach almost guarantees that companies will fall into this trap, since it focuses on what’s the least we can do to declare victory based on a paradigm that has ABSOLUTELY nothing to do with retiring legacy systems
As long as you embrace the fact that it takes years to replace decades of development, not months or days, and that the road to retirement will be much longer than anyone anticipated, then you can plan for the unexpected, and take advantage of opportunities as you implement new components.
After having been through multiple replatforming initiatives, i.e. from DOS to Windows, Windows to Web, Web to mobile, Mainframe to cloud, etc. here are just a few questions you’ll want to ask as you plot your replacement strategy are:;
- How much revenue comes from the top 1% of our customers?
- Do we understand the edge use cases, e.g. how the system is used to close the books at the end of the year, or when there is a regulatory audit?
- Who are our top customers, and what types of customizations have we done for them?
- How deeply integrated are our systems integrated into their systems? And how difficult will it be for them to adopt our new systems?
- What are all the downstream applications and organizations using our systems, inside and outside our company?
- How are these individuals and organizations using our systems and the data they produce?
- Can we segment our customer base by capability requirement? If so then can we Identify MVR requirements for each segment?
- Are there new underserved segments that don’t currently use our existing product because they can’t afford it, implementation complexity or because it’s not available on X platform, e.g. mobile, that would be happy that would be happy with a true MVP?
- Is the new product an extension of the old and should be initially sold as an add on or is it a true replacement? Sometimes you can start by offering an enhancement which can be sold as an add on and then later integrate core replacement functionality.
- Is it better to piss off your existing user base or potential users? Oftentimes, we build functionality for a specific niche or customer and have to make hard choices about whether it’s worth supporting existing customers vs. serving a broader set of new customers. Just be prepared for the blowback as what makes sense on paper to you may not make sense to the VP of sales or service dealing with irate customers or trying to hit their quarterly targets.
Kevin Mireles 
fantastic article ..definitely an AAHA moment for me