What is an MVP?
This is a question we often get when talking to our partners and their clients. Most people coming to an agency focused on development simply aren’t familiar with the concepts that occupy our every day. This is natural, and we need to be prepared to answer these sorts of questions with jargon-free, explicit language.
Minimum viable product (MVP) is a term that developers (and many designers) have heard time and again. It is a concept that is in common usage in startups of all sorts, but particularly in technology-based companies. Developers working in the “agile” and “lean” methodologies often leverage the minimum viable product concept when building websites, applications, and software, among many other products.
The folks over at The Atom Group wrote a very concise definition in their blog on this topic. They landed on “let’s just get something out there.” The “something” in this case being the MVP, and “out there” being into the world to start getting feedback.
There is a certain elegance in that simple definition, but here at RocketBuild we tend to define the concept of the MVP a bit more specifically for our partners and clients.
“A minimum viable product is the set of predefined features necessary to gain user feedback about a technology solution.”
This definition is based on the assumption that we are working in an agile methodology and that all parties are open to the idea of iterating on a technology over time. From our perspective as application developers, this means that there could be a number of MVPs developed before a product is ready for launch, as the use cases evolve and the definition of viability is refined. It all depends on the complexity of the final product, as determined in the product roadmap. It is important to embrace this philosophy of “ongoing iteration” as it allows us to build quickly, test regularly, improve the product, test again, and then begin a new iteration.
The Build-Measure-Learn Loop
At the inception of a project, we have ideas. After some planning we move forward to build a prototype. This leads to the first MVP of the product, which we can measure by collecting data from user testing. Once we analyze the data, chances are that we will learn a good number of things that we didn’t know before. Hopefully we are surprised, both by how well the MVP performed, but also by how many great new ideas came out of the testing and feedback. Then, we take our favorite ideas and add them as features for the next MVP… beginning the cycle again.
Do Less, Test More
The build-measure-learn loop illustrates the importance and value of the MVP as an efficient and cost effective method for learning. Designers, developers and product managers need to embrace the concept of rapid and repeated iteration for two reasons:
First, building an MVP allows the development team to get to the point of testing earlier, which leads to new ideas. When an application development team can gain feedback rapidly and repeatedly on features, it leads to more thoughtful problem solving and better outcomes.
Second, the costs associated with building a software product can be reduced by building in short, dedicated sprints. Sprints are planned bursts of design and development activity focused on building or iterating on an MVP. Each sprint is followed by some form of testing and analysis, either formal or informal, before engaging in the next sprint. This process allows for the diffusion of development costs over time, as well as a reduction in wasted time since good ideas are identified and tested quickly, while bad ones can be eliminated before too much time is sunk into them.
These concepts can be (and have been!) applied to everything from building cars to designing clothing. They have taken the software development industry by storm over the past decade, and are slowly seeing growth in the web development sphere as well. An application or website is never done. In the best of circumstances it will just continue to evolve and improve, hopefully based on testing, analysis, and iteration.
