Minimal Viable Product (MVP) is a common term these days. In an Agile development world, the idea is to build the fewest features possible before you solicit customer feedback. Don’t spend money and time building things customers may not want.
Build less. Validate more. Then build what you know (have evidence for) will sell.
MVP is a great idea…in concept.
The problem with MVPs is when they are not allowed to be MVPs: when they become milestones in the development cycle.
This is the case for many established companies that have adopted Lean or Agile. While Product and Engineering teams have embraced sprints, backlogs, and iterative development, product roadmaps are still made the old-fashioned way: by decree.
Execs still sets the agenda. Product and Engineering execute.
This creates tension. The MVP is a tool to find product-market fit. You do not know exactly what customers want, nor how long it will take to deliver it.
Roadmaps made by decree have timelines and deadlines. Being successful is about being on time. Looking good to your boss is about being on time.
In this environment, the MVP acts as an Alpha version. It is the first public mile marker on a course that has already been determined.
The beta version is akin to the Alpha plus one round of customer feedback. The Generally Available release comes shortly after that. Schedules have been set.
Timelines have to be met. (If you are on a tight timeline, your MVP might even be your GA release.)
This causes a lot of familiar problems. Little time for meaningful feedback. Reference customers are scarce. Pricing and packaging are mere guesses. The Sales team is trained on a value proposition of what the execs think, not what the customers’ think.
Does this mean that the MVP is dead?
But it does mean that we need to redefine it.
Marty Cagan, in his book Inspired: How to Create Tech Products People Love, takes note of the perverse world we live in. He has seen how the MVP has become bastardized. So he proposes a new term: Minimum Viable Prototype.
He uses newly defined MVP as an alternative (I will call it MVPrototype), and a way to get back to the true roots of what the MVProduct was: a means of discovery.
A prototype by definition is not a finished product, just like the Minimum Viable Product was never meant to be. That point is simply more obvious when you use the word, “prototype.”
Others might use the word, “experiment” which can mean the same thing, but “prototype” is truer to the original purpose of the MVProduct.
MVPrototypes is not a new concept. A lot of the lean startup books talk about quick and dirty prototypes, but they never formalize prototyping as a step in the process. MVProduct was always the focus.
A big benefit of MVPrototypes is that they relieve the stress of coding a product. Prototypes can be smoke and mirrors. In fact, they should be LoFi magic tricks. As long as they convey enough detail to elicit accurate customer feedback, they work.
You can iterate much faster with Prototypes too. Instead of coding for months to build an MVProduct, an MVPrototype can be done in days.
Now I am not poohpoohing MVProducts. In the lean startup context, they make a lot of sense. Customers do not buy prototypes, they buy products. The best feedback comes from someone actually using the software product.
But products are expensive to build, so introducing prototypes for faster iteration cycles has real benefits (even to a startup).
I know that if I were to redo my startup experience, I would rely heavily on prototyping.
I also love the idea of reclaiming the true purpose of the MVP in existing companies. Customer validation is too important to ignore. A lot of companies are coming around to this fact, but introducing the MVPrototype could make the transition faster.