The "Minimum Viable" Trap

A little while ago I wrote an article about “Adaptability Strategy”. It might have seemed a bit philosophical to some. However, not designing or planning for adaptability can have real and undesirable business implications, ranging from regret investments, architectural debt, project delays, missed business opportunities, declining employee engagement, declining profits and unhappy customers.

One example that gets organisations in trouble is the ‘Minimum Viable Product”, or MVP. MVP was conceived as part of agile delivery.

MVP makes perfect sense in the original context ...

The original definition of an MVP was a “version of a new product which allows a team to collect the maximum amount of?validated learning about customers?with the least effort.” (Eric Ries, 2009) This makes perfect sense: While, with an MVP, a team might have to rebuild the whole product entirely, they know that the next version is much more likely to hit the mark, because they have gained valuable insights. Also, the MVP wasn't a huge upfront investment. The cost of rebuilding are offset by the value gained from the learning.

While, with an MVP, a team might have to rebuild the whole product entirely, or refurbish large parts of it, they know that the next version is much more likely to hit the mark, because they have gained valuable insights.

... and then it mutated ...

When managers use "MVP" today, is often seems to be in the context of delivering a business outcome at minimum cost, be that to save a troubled project or to stay within constrained budgets. They already know that the organisation will be highly dependent on this capability, probably even at considerable scale, from day one. And yet, the term "MVP" keeps popping up in that context - it's fashionable and implies a more agile, lower risk approach.

"It's a trap!" (Admiral Ackbar, 1983)

Don’t get me wrong – it is good form to start with a first iteration that focuses on your highest priority business requirements, then follow it up with more versions that make it better and shinier. The shorter your delivery iterations are, the less you run into the issues of long-running waterfall projects, which are the reason why agile was invented in the first place. However, the product you are delivering in this context will only be viable when it also meets the high priority non-functional requirements which are based on a sound holistic enterprise architecture assessment. These include cyber security, for example - and fortunately most people understand that part nowadays. These also include architectural features that underpin the characteristics of adaptability and extensibility, ensuring that the capability can grow in line with its strategic future direction.

Examples of these include sourcing, hosting, integration, and data management choices.

If pulling the whole solution down and redoing it entirely in the short to medium term is not a viable option in your business context, it needs to be built such that it can evolve towards its strategic future state without major refurbishment.

This is not about building (or paying for) the perfect strategic architecture for day 1. It is about acknowledging that there is not likely a viable scenario in the short to medium term where you can pull out the whole solution and redo it again. That means it needs to be built such that it can evolve towards the strategic architecture without premature major refurbishment.

What happens if you get caught in the Minimum Viable Trap?

When available solutions don’t meet business needs as they evolve (at accelerating pace), any number of issues might arise, including (and not limited to):

• The business operates ineffectively or inefficiently (or fails to meet legal or regulatory compliance).
• Employee engagement declines, as people get frustrated being hamstrung by their tools. You'll lose good people.
• Attempts are made to rectify the problem while saving the prior investment. These are usually expensive and often ineffective.
• Non-integrated supplementary tools and services are developed or procured as point solutions, introducing architecture, cyber and business risk. Skunkworks thrive.
• Eventually the major refurbishment or replacement will be unavoidable. That usually doesn’t happen before the organisation has experienced considerable pain, be that losing money, talent, market share or lawsuits.

Maybe we should rebrand this mutation of MVP to “Minimum Sustainable Deployment”. Labelling it correctly might prevent some organisations from stepping into the minimum viable trap in the first place.