Editor's note: This is part of a series named TRIVIALITIES by Andrés Calviño, Head of Organizational Capabilities at Techie Talent.
"MVP" is one of those terms that has become so unavoidable, so essential, almost mandatory in the vocabulary of anyone pretending to work in software development. It makes your speech fancy. Combine it with terms like "agile" or "business value" in one sentence, and you automatically convert yourself into an illustrated eminence, an erudite. It is a must-use term for any Product Manager, Project Manager, Delivery Manager, Engineer Manager, Whatever-building-like-thing Manager role you have.
In agile development teams, we now strive to define MVPs, plan MVPs, build MVPs, and release MVPs. "User Stories" is too technical and specific, "Features" is kind of vague and yet too concrete, "Requirements" is too conceptual, and "Product" is too synthetic and generic. "MVP" is like it has it all: Minimum Viable Product. There you go...
Coined in 2001, the term was massively popularized by Eric Ries' best-seller book "The Lean Startup." He defines a Minimum Viable Product as the least amount of work we need to do to learn the next most important thing. The simplicity of the definition is as astonishing as the inconsistency that is verified over and over again in the use of the term in practice.
I understand it like this: the smallest experiment we can run to demonstrate our hypothesis about the generated "value." Fancy, too, ugh? There is a powerful effect on these specific words I dared to use to rephrase Ries' definition.
--> Conceptualizing Ries' "least amount of work" as an experiment reinforces the idea that we are not building a complete, finalized thing. It is a work in progress, a step in a road, a rung in a ladder.
--> The experiment has to be cheap and small enough (save time, save money, short effort, deliver soon)
--> It must be a runnable experiment, meaning end users must use it. We have to validate that the value we thought we created is real.
--> The purpose is "to learn," meaning that users will teach us what's important to them, and that shapes our perception of value.
It is not about the value of delivering as it is about delivering value. The former is meaningless without the latter.
