MVP anyone?

We all know them. Those experienced colleagues who keep the business rolling. Who contribute, day in, day out, to the primary value stream of our company. People who know all the nuances and details of the daily work. People. Who. Get. The. Job. Done.

Often despite the IT solutions they have to work with.

There were days when they had hope that IT would help them doing their job better. This hope was fueled by a promising MVP built for them and their process. It needed some work, but it looked promising and they were excited.

Then the team that built this MVP moved on. And left them with a -to their feeling- unfinished product. Then it happened again.

Offering them another MVP is not likely to get these users excited. At least not in a positive way. How do we get these users engaged again?

For instance, Kniberg suggest delivering product increments until you have an Earliest Testable Product. (I suggest a small celebration at this stage.) Then deliver some more increments until your users have an Earliest Usable Product. (Celebrate some more.) Continue deliver valuable increments of working software and you might deliver the Earliest Lovable Product.

Engage your user throughout. Try to reach the next “Xable” Product as quickly as possible.

It is still useful to deliver small increments of working, valuable product to learn from feedback based on actual use. Maybe it would already help not to name it an “MVP”.

Background and resources on the term MVP

The term MVP has changed in meaning and usage over time. I think the term was coined by Eric Ries in his book “The Lean Startup” as “A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

According to Ash Maurya Ries’ definition got overly simplified to “the smallest thing you can build that lets you quickly make it around the build/measure/learn loop”. In his article What is a Minimum Viable Product (MVP)? he suggest to distinguish between an experiment, an offer and an MVP. An experiment is anything that closes the build-measure-learn loop. An offer is a specific experiment to test a user’s interest in a solution. Only once a user accepts an offer (preferably even pays for it) you should perform the next experiment: building an MVP; a product that actually solves a problem the user has.

In his “RAT Guide” Martin Christensen provides an extensive list of the types of experiments you can use to test your riskiest assumptions. It is a list of Riskiest Assumption Tests, or RATs.

Pichler suggests delivering several MVPs before reaching the stage of Minimal Marketable Product.

Most people are familiar with Kniberg’s MVP image:

Kniberg - MVP