MVP versus MVR: Minimum Viable Product vs. Minimum Viable Replacement

sIn the world of agile everyone talks about minimum viable products, that smallest set of capabilities required to meet a segment of your customers’ needs.

What doesn’t get talked about is an MVR, minimum viable replacement for existing products. The MVR is much more challenging as your goal is to replace your existing technology and not just grab an underserved market segment.

And as in the case of everything else in life, the first 20% of the effort delivers 80% of the most used capabilities while the other 20% requires 80% of the effort. The challenge is that your most valuable customers generally have the most complex requirements.

And while you can segment your customers such that you can build and potentially take an MVP to market for a specific segment, for the majority you need to deliver much greater capabilities if you want them to transition. And hardest of all, for your largest and most entrenched customers, you may need to build a ton more otherwise they won’t move and/or may defect if you force them to move.

After having been through multiple replatforming initiatives, i.e. from DOS to Windows, Windows to Web, Web to mobile, some of the key questions you want to ask as you plot your replacement strategy are:;

1. Can you segment your customer base by capability requirement? If so then identify your MVR requirements for each segment.
2. Are there new underserved segments that would be happy with a true MVP?  Oftentimes there are large markets that don’t currently use your existing product because they can’t afford it, implementation complexity or because it’s not available on X platform, e.g. mobile, that you can target with a lesser-featured lower-price point product which enables you to extract value sooner than just focusing on replacing everything for your existing customers.
3. 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. Again, you can deliver and extract value sooner rather than later.
4. Are you willing to take two or three times as long to replace everything as originally estimated? No matter how long you think it will take to replace all your existing capabilities, it will almost always take much longer. So as you plan your strategy, double the transition time period as you will discover all sorts of unexpected and undocumented features and use cases. Transitioning customers always takes longer and involves a lot more pain than you expect, especially for enterprise systems where integration with existing systems is a key part of the value proposition.
5. Is it better to frustrate 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 blow back as what makes sense on paper to you may not make sense to the VP of sales or customer service dealing with irate customers or trying to hit their quarterly targets.  What you want to avoid at all costs is be held hostage by a vocal user base that is invested in a feature that prevents you from expanding your customer base, like Twitter and its 140-character limitation.
6. How much do you want to invest in replacing vs reinventing? On one hand you want to make transitioning easy and avoid critical functionality gaps, but at the same time you want to take advantage of the new and different capabilities new technologies provide. Less visible change will reduce transition challenges but may limit the benefits of the new technology and prevent you from grabbing an even larger opportunity. Again, your always going to frustrate someone, it’s just a question of whom.

So have fun as you try to figure out how to get to a minimum viable replacement. And whatever you do stop calling it an MVP.