My first steps in an Agile organization were marked by the appearance of the acronym MVP. The MVP, or Minimum Viable Product, is, in fact, one of the basic practices of Agile.
Coined by Frank Robinson in 2001 (not a new concept indeed), and popularized by Eric Ries through his book Lean Startup, the MVP has become a pillar of high-performing product teams all over the world.
Why has Google been so successful for so long? Why does Apple make some of the most popular products in the world? Why has Netflix not only survived but thrived beyond their original business model? Many factors contributed, but one common strand is that they all use the MVP.
So what is the MVP? Here’s Eric Ries’s definition:
That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
As this definition makes clear, the MVP is not a product with the least possible functionality necessary for a public launch or, in my harsher definition, is not a “sloppy” product. MVP is purely a mechanism for validated learning, used to test hypotheses, and discover what will meet customers’ needs.
Unfortunately, this concept is one of the most slippery territories where a Product Manager and her team can go through: in my experience, it is one of the best ways to fail in the early stages of a product and NEVER test the right product. In the worst scenarios, I even witnessed MVPs going to the market as finished products and never iterated because considered done. (sic!) This creates the worst consumer experience possible — obviously not what we want.
My beloved: “Minimum Lovable Product”
That’s why I rather prefer the concept of Minimum Lovable Product created by Henrik Kniberg. The concept is rather simple and perfectly explained by his own picture below.
Illustration by Henrik Kniberg.
Last year I had to kick off the product roadmap creation for 2019 and I wanted to create a product event for my team to fully embrace this concept.
As usual, I wanted to align the team to the vision avoiding any top-down approach. We organized a one-day workshop (on-site this time, so you don’t need a fancy location, you’ll only need your team’s attention and commitment).
In the morning we invited a couple of other companies to talk about how they are building their product and making customers happy. Unfortunately, I cannot disclose their names since the collaboration was not public. I strongly believe that learning and opening to others can help you in finding simple ways to improve. The team really appreciated the contamination and learned, for example, that in all companies, stakeholder management is one of the hardest tasks.
Aligning a team to a new product culture
The afternoon session opened with this picture:
Picture taken during the 2019 London “Mind the Product” conference, slide by Henrik Kniberg.
Introducing the new terminology, I wanted the team to embrace a common set of language and definitions since it is the first step in creating a culture. But more importantly, since we learn 80% more when we experience something, we organized a business game called the “Snowflake Startup.”
Starting with a simple piece of paper, teams fold paper and cut out snowflakes to satisfy a fickle customer (sitting in the room with them). The acceptance criteria are tough, and not only will the customer reject poor quality snowflakes, but the customer assigns a value to each one, where more intricate snowflakes are rewarded with more money. Of course, none of the teams know the customer’s acceptance criteria upfront. Only through successive iterations of the game do they slowly learn the customer’s needs and wants. All this snowflake craziness is done in three-minute sprints: three minutes to make snowflakes, three minutes to debrief, and so on. Does it sound familiar?
The winning team, as I expected, fully exploited the MVP concept: the team leader is a very experienced product manager, and she won by far on all the teams — but as expected, every team failed in building the Minimum Lovable Product. No one in the room talked enough to the customer to understand her REAL need. But that’s the point of this exercise: to shock the audience and create the experience to learn the difference between MVP and MLP.
These are the key learnings the team surfaced during the exercise debrief:
- Product Discovery is a team activity — the teams that used the debrief time best were more successful.
- You’ve got to get out of the building to find out what customers need — the foundation of Design Thinking, and everybody in theory knows it, but…
- Delivery pressure makes people forget the big picture — the pressure of the game (like the real-world pressure of time-to-market) makes teams skip the discovery phase, setting the scene for an epic product failure.
- Teams work better when they collaborate and share their learnings — looking at the most successful team made everyone else’s progress faster.
- A good customer’s time is limited and precious — use it wisely — most teams never sat down with the customer, or even asked questions to empathize with her.
I hope this article and the literature I shared help you in using the MVP as a tool, not as a final product — and aim, instead, for the Minimum Lovable Product. As always, don’t hesitate to comment and contact me for further discussion on the methodology.