Minimum Viable What?

Minimum Viable Product (MVP) is a term that gets tossed around a lot in the software world. What does it really mean? If we only look at the definition of the words individually, it looks like this:

• Minimum: noun – “the least or smallest amount or quantity possible, attainable, or required.”
• Viable: adjective – “capable of working successfully; feasible.”
• Product: noun – “an article that is manufactured or refined for sale.”

I was an engineer in a project once where the Project Manager stated that we needed to work towards the “Minimum Viable Product”. It was as if there was some golden MVP that we could achieve, and if only we could create it – then we would have happy customers and make the sale! The PM was looking for a state where we achieve the least amount required, which is feasible, and which has been created. That fits with the definition of minimum – viable – product. So what’s wrong with that?

The problem with this frame of view is that it is static, and does not take into account the continual changes that truly occur in software. This is especially true with Agile development frameworks, which demand frequent releases of software and allow for inevitable change. If there is no golden MVP, then what is the point of the term? Does it lose its value and its just another business acronym to throw around, to make someone feel smart?

In the world of software applications and through innovation, customer feedback, performance improvements, and bug fixes, software products are always in a state of change. This is true both pre-sale and while the product is being sold (SaaS, virtualized function applications, downloadable and installable, etc.)

MVP as a concept has value, but only when placed in proper context and within the evolution of the software product. I think its better to consider the word viable with the botanical definition, i.e. “able to germinate”, where the definition of germinate is “come into existence and develop.” With this, we have a constantly evolving MVP that fits with the true state of software and software development. MVP, then, falls into something that an Agile Product Owner is conceptualizing, considering the priorities today and what will bring the most value today to the customer.

MVP is a learning tool. A Minimum Viable Product can be created and tested with customers to gain feedback and confirm that we are learning and evolving in the right direction, bringing value and business success. With this approach, a MVP could be almost anything: a video or document explaining the product that is envisioned, beta software, production software, and so on.

Minimum Viable Product has to do with priority, value, evolution, current state, domain expertise, and making the right informed decisions. It is a tool that can be used to define and share a state of the software, which can be used to gather customer feedback and work towards improvements, and the next MVP!

---

If you want to read more about this concept of MVP and many examples, refer to Eric Ries’ book The Lean Startup. Here’s a few interesting quotes from the book:

• “The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with the minimum amount of effort and the least amount of development. The [MVP] lacks many features that may prove essential later on.” (pg. 77)
• “A minimum viable product …helps entrepreneurs start the process of learning as quickly as possible……the goal of the MVP is to begin the process of learning, not end it.” (pg. 93)
• “MVPs require the courage to put one’s assumptions to the test…..We must be willing to set aside our traditional professional standards to start the process of validated learning as soon as possible.” (pg. 109)
• “Remember that the rationale for building low-quality MVPs is that developing any features beyond what early adopters require is a form of waste.” (pg. 170)
• “…the Build-Measure-Learn feedback loop is a continuous process. We don’t stop after one minimum viable product but use what we have learned to get to work immediately on the next iteration.” (pg 228)