When an MVP paves the road to hell

We all love the acronym MVP, or rather what’s behind it. Minimum viable product is the bare minimum you have to deliver to address the customer’s most pressing need. Customers love it because they get what they want in the shortest time, or at least everyone thinks so. Developers love it because it fits into a sprint or can at least be planned in smaller pieces. Architects love it because it avoids big designs and needless decisions that imply changes we might never need. An MVP is a good servant but a bad master. It can easily turn into a one-way street straight to hell. The problem is what happens when you misuse it. This article looks at how to avoid some of those pitfalls.

A quick MVP thought experiment taken to absurdity. A customer needs to get from A to B. You’d like to design a car. That’s complicated, though, and does the customer need it? A motorcycle? Too complicated. A bicycle? They’ll always be going downhill. No need for a bicycle, so how about a scooter? They’ll always travel in winter. How about a sled, or skis? Skis would be simpler and cheaper. Perhaps we can simplify it further. What if we put a plastic bag stuffed with straw under their backside? That’s enough, and voilà, an MVP. The customer has first-degree frostbite and occasionally falls flat on their face, but the MVP served its purpose.

An MVP like that has two downsides. What’s an MVP to the customer may be a nightmare for developers who have to maintain and extend it. Put several MVPs into production alongside one another and maintaining them can feel like crossing a minefield. An MVP is often a stopgap. Worse still, it often stays forever. Nobody invests another crown in it. It serves its purpose, but nobody ever brings it up to the standard it needs. An MVP is half-finished work whose consequences will catch up with you sooner or later.

If you don’t intend to build on the MVP or shut it down entirely, you’re better off skipping it. The worst case is having a pile of MVPs stuck in the product like skeletons in a closet, just waiting to tumble out at the worst time, preferably all together because they’re connected. I like the idea Martin Fowler describes in Sacrificial Architecture. It applies to MVPs at the architecture level. Every architecture reflects the time when it was created and should have an expiration date. After that, we should feel free to throw away that part of the system and rewrite it for current requirements. MVPs can be done well, but it takes discipline. Remember that when you use one.

1. Avoid making MVPs your only way of working. Aim for a minimal solution and keep MVP from becoming an excuse to dodge acceptance criteria and sneak through poor-quality work.
2. Plan to evolve your MVP. That may mean replacing it entirely or shutting it down. Allow for either.
3. Avoid building one MVP on top of another, because you risk the butterfly effect.