Minimal Viable Products (MVPs) have become the sole defacto way of building software. If you are not taking an MVP approach, you may get strange looks nowadays.
It has been proven time and time again as an effective way to quickly test a market hypothesis or build a proof of concept to test the technical feasibility of a solution. But what happens when you are not building a new solution and instead you are modernizing or replacing an existing one?
If you are using an MVP approach in this scenario, you will be in for a rude awakening in the form of wasted time, money, and unhappy customers.
Don’t worry… there is a better way. The Minimal Viable Replacement (MVR).
What is a Minimal Viable Replacement (MVR)?
A Minimal Viable Replacement (MVR) is an approach, popularized by Kevin Mireles, to replace a legacy solution that has an existing base of users or customers.
These modernization or replacement projects are often labeled with the overused term, Digital Transformation. No matter what you call it, they all have one thing in common.
Complexity.
With an MVR, you already know a market exists for your solution. The question becomes, can your new solution meet and exceed the value delivered by your old product?
The approach focuses on decomposing the needs of the new system(s) into a clearly defined roadmap. This roadmap focuses on delivering valuable chunks of functionality into the hands of real users as soon as possible with minimal impact on their existing work.
Essentially, an MVR is the culmination of all the MVPs required to migrate existing customers to your new solution with minimal loss of existing customers.
Why the MVP doesn’t work when replacing an existing solution
By now, we have all seen this age-old MVP metaphor.
The goal of an MVP is to provide end-to-end value in an incremental fashion. In this example, the desired outcome is to get from point A to point B, and the first iteration of the solution, the skateboard, accomplishes that right off the bat.
The problem is, your existing customers are not willing to trade down to a skateboard when they are currently driving a car with a leather interior, air conditioning, and Bluetooth. Oh, and a few of those other important features like seat belts, airbags, and brakes…
To make this real, picture handing your existing customers a skateboard and asking them to test it out riding down the highway. That is a sure recipe for disaster and guaranteed loss of revenue.
The major differences between an MVP and an MVR
| MVP | MVR |
|---|---|
Primary goal: validate a market or product hypothesis | Primary goal: migrate existing customers to the new modern system with minimal churn allowing for more agility |
No existing customers | Existing customer base |
Focused on attracting new customers | More focused on retaining existing customers than attracting new ones |
Competing against other companies or existing behaviors | Competing against your existing solution |
Deeper research required to vet the viability of the solution | Minimal research required as the solution has already been proven to have market fit |
Focused on a very small set of target customers and use cases to prove out the product’s value proposition | Focused on identifying the most valuable and sometimes extreme use cases for your most valuable customer segments among the many existing customer segments |
Focused on new functionality | Focused on improving existing functionality first, and typically new capabilities second |
Targeted few specific workflows | Many existing workflows exist with existing users typically creating their own a-typical process within your system |
Leverage new technology | Have to account for existing legacy technology |
Ability to create new processes with a greenfield project | Must account for existing organizational norms, process, and culture |
Why an MVR is unique
The typical approach for an MVP leverages the 80/20 rule, which in essence states that 20% of the functionality will serve 80% of the needs of your users. So therefore you should focus on that 20%.
With an MVR it is not that simple…
With an MVR, you have multiple customer segments you must satisfy in order to successfully replace a legacy solution. On top of that, those customers represent different value to your business, typically in the form of revenue or profitability.
Surprise, surprise – your larger, higher value customers typically require more extensive and complex functionality compared to 90% of your typical users.
This is why in an MVR you must consider the edge cases of your most valuable customers.
On top of having to consider edge cases (usually a ‘no no’ with MVPs), there are also two core psychological phenomena at play in an MVR.
Endowment effect: People are more likely to retain an object they own rather than acquire a similar object (either in value or appearance). In essence, people feel a sense of ownership over the systems and technology they currently use and are not typically gung-ho about giving it up.
Loss aversion: People value losses more than they value potential gains. Not just by a little either. They tend to value it by 2 to 4 times more. Anything less than that is likely to be perceived as incredibly negative. In essence, a bird in the hand is worth two in the bush.
We are ultimately creatures of habit, which makes an MVR unique.
A metaphor fitting for an MVR
Picture a 100-story condo. Let’s say you built the first 99 floors in a relatively standard fashion with 12-foot ceilings, standard bathrooms, and fixtures. They each pay $2K a month in rent.
Then you get to the last floor. The penthouse.
This is just one tenant, but they pay $30K per month.
They also have different requirements such as a swimming pool, 30-foot ceilings, and a helipad. If you didn’t account for this upfront, your architecture and design likely won’t support it.
So how do you approach an MVR to ensure you aren’t doing more harm than good?
The MVR approach
The goal of an MVR should be to meet and exceed the value delivered by your old solution without losing your existing customers in the process.
The approach focuses on decomposing the needs of the new system(s) into a clearly defined roadmap that focuses on delivering valuable chunks of functionality into the hands of users as soon as possible with minimal impact on their existing work. The roadmap should show them they don’t have to fear a loss of functionality because you have clearly communicated and mapped out when the functionality will be delivered.
There are 3 standard approaches to the MVR when considering how to develop your roadmap and define key milestones.
Functional Approach: If there is little overlap in functionality between end-user segments, you can structure your roadmap based on the specific functional needs of those different customer segments.
- Identify, define, and prioritize your different customer segments based on required functionality and value to your business
- Identify the edge cases your highest value customers must have to switch
- Align on if you are building the replacement solution for a new customer segment you are targeting in the market, and identify if this shift in strategy will result in churn of existing customer segments.
- Identify instances of customers using your solution in unintended ways (note: these are opportunity areas to build functionality to make these workarounds easier)
- Determine all the downstream applications and organizations using your systems inside and outside of the company
- Understand how users and organizations are using your solution and its data.
- Identify any regulatory or compliance-related requirements
- Determine if the new solution can start as an extension of the legacy one and sold as an add-on to start. Then, integrate the core functionality as part of your replacement strategy.
- Identify if there are any underserved customer segments that are not currently using your solution and would be happy with a true MVP
- Define your roadmap by breaking up the project into mini MVPs defined by functionality and customer segment served
Summary
At the end of the day, it is not a question of if you will need to replace legacy solutions. It is a matter of when.
While legacy solutions, processes, and technical debt have a knack for slowing down progress, you can’t let them hold you hostage.
Leverage an MVR approach to enable agility and innovation in your organization so you can continue to deliver value for your customers and your business.
