“We need to retire the old systems 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.
If you’ve experienced or are currently living this nightmare scenario, then you’ll be happy to learn about the Minimum Viable Replacement concept, which I developed after three incredibly painful years of stumbling through a $10M+ integration and retirement project.
Minimum Viable Replacement to the rescue!
The Minimum Viable Replacement framework addresses two key challenges that plague people working to retire legacy systems and migrate their existing customers onto new products/ platforms.
- Stop the confusion caused by trying to apply the Minimum Viable Product concept to retiring systems. Conflating the retirement of an entire system with an MVP, is about 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 damn pie. Definitely, similarities between the two, but good luck convincing all your car, home and pie owners to trade them for a brick, bicycle or slice of pie.
- Provide a framework for architects, UXers, product and project managers, etc. to help them better tackle the wickedly hard problem of replacing systems that serve all sizes of customers in multiple geographies across multiple markets.
So whether you’re engaged in a digital transformation initiative or working to retire systems as part of a merger and integration project, take 10 minutes to read this article before you waste thousands of hours and millions of dollars pursuing the wrong strategy.
Minimum Viable Product: What is it good for?
In the world of agile everyone talks about minimum viable products, that 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 startups, and for companies entering entirely new market or product segments, where they lack existing products and customers.
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, as is illustrated below.
The problem: Replacing an existing system is the exact opposite of an MVP
If you are trying to retire a legacy platform, instead of having the luxury of just solving for the needs of a very specific customer segment, you need to solve the needs for every customer segment that is currently using your software!
So imagine, your company started out 20 years ago serving a few small customers in one specific market segment in one country. Now you’re serving multiple different industry segments, across multiple countries,etc.
To top it off, while you have thousands of customers, about 100 or .01% of your customers drive the majority of your revenue and system requirements, both from a scalability and functionality/complexity standpoint.
Instead of trying to solve the needs of just one small segment, in order to retire the system you now have to deliver the equivalent of 20 years of software development for thousands of customers across multiple countries and segments, which is the exact opposite of an MVP.
Since your goal is to retire your systems with minimal customer breakage, the classic agile product-development concept of build a skateboard, bike, car analogy of product development completely falls apart. After all, since the overwhelming majority of your customers are already paying you for a car, they aren’t about to trade down for a skateboard or a bicycle.
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.
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 the MVR concept, won’t suddenly make the process easy or guarantee success, but at least it points you in the right direction, as opposed to the wrong direction.
Simply put an MVR is the sum total of all the MVPs required to to migrate existing customers to the new system with minimum breakage and retire old version,
Successfully executing an MVR requires:
- Replacing or enhancing all of the existing features/capabilities required to retain your existing customers. Instead of a single MVP, an MVR is the sum total of all the MVPs required to meet the needs of each segment that you want to keep as 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 actually retire the system. Once you’ve developed all the replacement capabilities, getting customers to actually migrate to the new platform can take many times as long, and cost as much or more than the development of the new platform.
Replacing & retiring systems requires different approaches
Unlike an MVP where you’re trying to determine whether there is even a market for your offering, when you’re dealing with an MVR, you already know there’s a market, the question is, whether your new product can meet and exceed the value delivered by the old product, which requires different approaches.
Imagine you’re a car manufacturer. You know electric vehicles are the future, and gas-powered vehicles are going to go away, you just don’t know when, but you don’t want to wind up like Kodak, especially as you see Tesla grow from a pipsqueak into a global giant.
The faster you can make the transition from one technology to another the better, because in the interim you’re having to invest in both technologies. The question is how? What combination of technologies, product, ecosystems and inducements will be required to migrate as many customers as possible so that you can shut down your legacy systems.
Since electric cars are cars, you don’t have to prove the value of them being cars, you just need to prove that the electric technology will work as well or better than gas-powered technology in order to switch. While there are many downsides to gas-powered cars, they do a lot of things really well, we’re already comfortable with them, and we’ve built a giant support system that enables us to drive as far as we want without worry.
So instead of investing time trying to prove the value of cars, we need to prove that the new technology matches or exceeds the value of the old technology for as much of our existing customer base as possible.
If the goal is to retire a system, focus on your extreme/edge case first
Especially if you are in the B2B market, you cannot underestimate the importance of designing for the extreme use cases.
First, because of Loss aversion, the concept that shows people tend to fear a loss twice as much as they are likely to welcome an equivalent gain.
Replacing gas-powered cars with electric cars highlights the challenge of overcoming loss aversion. The challenge is that while most of us drive less than 100 miles per day 95% of the time, most of us still want a car that can we can drive 500+ miles in a day to support the one or two weeks a year we head out on long road trips. So even though the electric car is overall better, e.g. cheaper to maintain, less polluting, sexier, etc. the chances we’ll switch are low, because we fear that loss of freedom.
Second, because those edge use cases are often critical for your largest customers; the one percent who drive 40-90% of your revenue, and who drive 90% of your complexity, so if you design and architect for the 80%, there is a good chance that your solution won’t scale to support 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 $5M 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.
Retiring systems takes longer and costs more than your executives want to hear
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.
Replacing gas-powered cars with electric cars provides a similar challenge. While it’s easy to build an electric car that can travel 100 miles on a single charge, building an electric car and the supporting infrastructure to support driving 500+ miles in a single day, anywhere in America, is a much, much harder nut to crack, so if the goal is to completely eliminate gas-powered cars, the challenge is much harder than just attempting to grab a slice of the gas-powered car market.
Unfortunately, the MVP approach almost guarantees that organizations will underestimate the amount of work required to replace core technologies, since the entire concept of an MVP is about doing the least work possible, not all the work required.
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.
A few questions to kickstart your Minimum Viable Replacement strategy
Below are are just a few questions you’ll want to ask as you plot your replacement strategy:
- 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.
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, so in the meantime I hope this article has been helpful to you.