I see a lot of people confused by the concept of an “MVP”, a concept made popular by Eric Ries’s book The Lean Startup.

Many seem to think that an MVP is just a beta or alpha release of a product or feature. And this leads to people saying things like “I don’t like the concept of a Minimum Viable Product. I prefer aiming for a Minimal Lovable Product.” But this is completely misunderstanding the purpose and meaning of an MVP, which is to begin the process of learning as quickly as possible. If you wait until your product is lovable, you’ve probably wasted months, or longer, of time you could have been learning. The risk is that you may build a lovable product nobody wants to use!

In his book, Ries illustrates an MVP with the example of Zappos cofounder Nick Swinmurn. At the time, the idea of selling shoes on the Internet was new, and it wasn’t at all a sure bet. Shoes are very personal, and conventional wisdom was that you had to try on a pair (or 6) of shoes, for fit, color, and other charactaristics. So rather than building a “beta” version of zappos.com, Swinmurn went to a shoe store and took photos of some of their stock, and posted them on a simple web site. If and when someone placed an order for a pair of shoes, and not before, did Swinmurn go to the shoe store and buy the shoes—at retail price—then ship them to the cusomter, at a loss.

How can we apply the MVP mindset to DevOps?

Probably the simplest way is to systematize before automating. Remember: humans are Turing complete, so use human labor to validate an idea before you spend time automating it. This is the core concept I employ in my free Lean CD bootcamp, which aims to teach you how to do Continuous Deployment without automation first.