[Part 1] The problems with MVPs in legacy replacement

So, you’re a product manager, and following your success in launching a new product last year, you’ve been promoted to product manager of your organization's flagship product ‘20-Year-Old-Monolith-Beast’, just as the organization embarks on a much-needed modernization initiative. There’s a bit of a smell around the transformation, and many of your stakeholders are pushing for an MVP (minimum viable product). They’ve heard that’s the best practice so what should be the MVP for this? You’re struggling to find one that makes sense, and so now you’re thinking you might not be up to the job. Don’t stress! It’s not you, it’s the MVP. It’s not up to the job. Let’s unpack why MVP is not the right tool for legacy modernization.

Firstly, let me state that overall I think an MVP is a really good idea. It’s a great way of doing the thing it was intended for, to test a market hypothesis with minimum resources. The problem is that people keep using ‘MVP’ in the context of legacy modernization. You’re not testing the market here; you already know the market. In fact, you should have real-world data on how the market feels about your product. However you are, at some level, trying to make some organizational changes and an MVP is not going to cut it. I’d like to explore a few reasons why it’s not going to work and propose some alternatives. Let’s buckle in for a bumpy ride!

First a little context, here’s one of the best depictions of what an MVP is:


You’ve inevitably seen some version of this, and it’s a great way of doing an MVP. Each iteration of the product is still a valuable ‘thing’ in itself, and it’s just the leanest way of answering a customer’s need so that you can learn how your market is going to respond. This view, and its demonstrable successes, was a breath of fresh air into software development in general, not just for startups.

I would suggest that its emerging popularity in legacy modernization projects is tied to the rate of failure for these types of projects. The ‘MVP’ has assumed the aura of a ‘silver bullet’, a way to prove that this is not going to be just another failed legacy migration project or just a way to get a more palatable budget over the line. It’s become a victim of its own success, often reduced to shorthand for R0.1 with a minimal feature set that is never further built upon just to say they delivered ‘something’. Think output over outcome. The reason why it just never seems to deliver on the faith that was put into it as an approach is that it’s not the right framing for this kind of problem. Let’s delve a little deeper.

MVP’s success as a tool was born in the world of greenfield development. Kind of like this:



Remember the skateboard in the original illustration? That can kind of be a nice way to enjoy it and still get from point A to point B - as long as you’re not in a hurry.

Your existing system, the legacy you’re looking to modernize, however, looks more like completely overloaded station wagon, with three screaming kids in the back seat, in the middle lane of traffic, travelling at 80 km/hr, and you’re trying to get from Sydney to Brisbane by midday tomorrow, desperately hoping your old clunker doesn’t break down on the journey! A skateboard is really not a viable alternative for your very visible needs.



There are a couple of good reasons why:

1. MVPs exist to test an overall hypothesis — you don’t need to do this. If the decision has been made to go through the disruption of replacing an enterprise system, there’s generally a good reason why you have that system/process to begin with (mostly based around the business grinding to a halt if you don’t). If that’s not a good enough reason to not try and find an MVP then I give you…
2. People. Irrational people. In this enterprise legacy replacement context an MVP will only be met with challenges, disappointment and rejection. To understand why we’ll take a wander through behavioural economics and arrive back at a solution through consumer psychology and change management.

Let’s look at this idea of hypothesis testing first.
 

The major hypothesis is tested: what did you learn?

​Maybe if you can’t get an MVP out of your head (or your stakeholders), you can think instead that your existing system/process and all the tools, workarounds, and shadow IT that people have put in place to get their job done is the MVP. Your main goal now is to learn from it.

Most people are familiar with this circle, popularized by Eric Reiss in his Lean Startup book.



The loop, in general, is still completely appropriate, but the way it’s typically stated BUILD, MEASURE, LEARN is not. You’ve already ‘BUILT’ so start at LEARN.


Learn from all the people who are currently working with the existing systems, whether inside your organization or external customers. Leverage the existing knowledge, because in this case there is a whole bunch of it. How people use the systems, how the information flows around, and where the value is (and isn’t coming from). And make sure you go broader than your ‘direct’ user. Understanding stakeholders is at least, if not more, important. They are going to influence the acceptance of the replacement system(s) and you need to know what’s going to make them ‘buy’ it. What are their needs and fears? As a product manager you need to speak to that as well as the pains and gains of direct users.

You don’t need to experiment to understand your customer’s needs — they’re all right there in front of you — so LEARN.

In the second part of this article we look at why an MVP is not going to help you realize the value of your legacy replacement.