The "Minimum Viable" trap

More than forty-five years ago Fred Brooks, known as the “father of the IBM System 360,” and no slouch, wrote:

“An omelette, promised in two minutes, may appear to be progressing nicely. But when it is not set in two minutes, the customer has two choices – wait or eat it raw.” (1)

Brooks was writing about software development in an era before Lean and before Agile, when the waterfall software development method was all there was.

Perhaps if he were writing now he might add “… or have it half-baked.” (Admittedly this strains the omelette analogy.)

Most people working in software, web development or organisational design and transformation will be familiar with the term “MVP” (Minimum Viable Product). But what does it mean?

Eric Reiss defined MVP back in 2009 as:

“…that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” (2)

He immediately followed up with the caveat that MVP:

“…is not about creating minimal products.” (3)

Tomer Sharon, speaking on UXpod, said that MVP is:

“a process that allows its creators to validate or invalidate assumptions, quickly with a subset of potential users.” (4)

In practice, however, MVP has become in many organisations an excuse for justifying delivering a sub-standard product to market (whether for internal or external customers). Despite Reiss’ caveat, it is precisely about delivering a minimal product.

This is a dangerous path to follow. Instead of being a Lean practice, the MVP becomes a justification for allowing resources to drive design decisions, demoting or removing the emphasis on user-centred design, and enabling lazy decision-making and corner-cutting.

I don’t suggest that we need to stick unfailingly to the original concept of the MVP. However, we do need to have a very clear view of what we mean when we say MVP. There are a few questions that can help clarify what path you’re on with your MVP efforts:

• Is there a shared and clearly articulated definition of what the organisation means by MVP? There should be.
• Is the term “just an MVP” used frequently in planning discussions? This is a likely alert that quality is being sacrificed for expediency.
• Is MVP in fact a justification for not doing good design? Arguably, an MVP needs at least as much focus on user research and design as a final product.
• Finally, is MVP a step on the way, as it should be, or in fact “version 1,” to be delivered as if it were the final product, with little or no vision for a future pathway?

Lean practices and the MVP provide a way to avoid the “wait or eat it raw” dilemma, to save cost and time, and to develop high-quality products and services, but only if the chefs know what it is they’re trying to cook.

References

(1) The Mythical Man-Month. Brooks, Frederick P. Jr. 1975. (2nd edition 1995)

(2) (3) Startup Lessons Learned. Reiss, Eric. 2009. http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html

(4) Sharon, Tomer. UXpod, 2016. https://uxpod.com/the-importance-of-invalidation-tomer-sharon-on-lean-user-research/