MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The MVP should have the core features which allow it to be deployed to some real customers in order to get initial feedback, but not more.

The MVP is used in the context of the “build-measure-learn” feedback loop. From the Lean Startup site: “The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible. Once the MVP is established, a startup can work on tuning the engine. This will involve measurement and learning and must include actionable metrics that can demonstrate cause and effect question.”

Now the question is: What is the right way to build the MVP? Of course we should adopt some form of incremental development, in which the MVP should be concluded after a few initial iterations. Then, the next iterations should be used to add new features based on the conclusions of the “build-measure-learn” feedback loop. Thus it is very important to plan the incremental development process so that it will fit the progress of the feedback loop.

Incremental Software Development

Any approach that divides the software development process in small iterations can be called “incremental.” However, there are several possible ways to build a product incrementally. This was very well illustrated by John Mayo-Smith in his article “Two Ways to Build a Pyramid”.

In this metaphor, the traditional way to build a pyramid is to start with the base and then, with each increment, add a new level on top of the previous one. This is certainly an incremental process, but only after the last iteration we obtain a real pyramid. During all other steps of the process we may have at most an “under-construction” pyramid.

An alternative approach is to start with a small pyramid and then use each additional iteration to increase its size. In this case after each step we have a full pyramid, which keeps growing in size incrementally.

Of course, if we want to build a MVP as part of the “build-measure-learn” feedback loop, the second approach is the right one. The second approach allows us to have the MVP (small pyramid) very fast, and then have a deployable product with new features (bigger pyramid) after each iteration.

In summary

The Minimum Viable Product should have enough features to collect feedback that will drive the implementation of additional functionality through the “build-measure-learn” loop. The MVP should be built using an incremental approach, which should be planned to have a deployable version after each iteration.

What do you think? Have you used similar approaches at your company? Please share your experience using the comments below.