When setting out to design and market a new product or system of any kind, our first inclination is likely to make the first release of that product or system the most functionally rich and complete that it can be. There is, however, a growing acceptance that releasing a minimum viable product (MVP) to early adopters is a far more efficient way to develop a new product or system and one that will ultimately lead to a much better deliverable.
The concept of a minimum viable product, which has been popularized by Silicon Valley entrepreneurs Steve Blank, and Eric Ries, is a design and development process in which a new product, such as an app, is developed and initially released with only sufficient functionality to satisfy the needs of the early adopters. Further features and functionality are only added to the product after consideration has been given to the feedback that has been received from those early adopters.
A minimum viable product is a product that has sufficient value to make people want to use it and that has been sufficiently developed so that early adopters can see the future of the product. The aim of MVP is to provide a feedback loop that can be used to guide the future direction of the product development.
Developing a product using the MVP model has distinct advantages over the traditional, all-in-one-go, approach. Here are the main reasons why an MVP produces better apps.
A system spec can only be, at best, a guess of what users will do with an app, how they will interact with it and what functionality they will need from the app. An MVP takes much of the guess work out of product development and allows time for the feedback of users to drive the development of the product.
If you attempt to develop a fully completed app based only on system spec, it is virtually guaranteed that you will develop functionality that users don’t use, or functionality that doesn’t quite meet their expectations. It is far more cost effective, therefore, to develop an app that has all the basic minimum functionality and then let the user feedback be what dictates the future development of the product.
The Pareto (80/20) principle is never truer than it is in software development. 80% of the most important requirements of an app are likely to be cared for by just 20% of the functionality. The MVP focuses early development time on getting the essential 20% right, so that 80% of essential user needs will be met with the first release.
The MVP development model allows developers to focus on the development of core functionality first, followed by the development of additional functionality. This is a much more efficient way of developing a product than attempting to develop many aspects of functionality simultaneously. It allows the focussed use of resources on fewer aspects of the app, which ensures that each element of an app is completed to the highest specification.
Evolution has created some of the most complex and efficient systems on the earth, so why not let a product evolve too? What begins as an MVP can evolve naturally, through end user feedback, and refinement via subsequent development iterations.
The 30 Day MVP model does not doggedly insist that any product can be delivered as an MVP in 30 days. Instead, it recognizes, and leverages, the realization that the 30-day constraint (when applied with carefully crafted and optimized facilitation, design, planning, development and usability testing techniques) can sharpen focus and improve project and development process efficiency.
Greater focus: A 30 days development constraint can further sharpen focus by forcing prioritization and squeezing out all but the essential aspects of the app idea.
More efficient project structure: In contrast to conventional agile MVP processes, the Aezion approach defines and validates the entire multi-sprint MVP deliverable at the outset during week 1. This process eliminates the uncertainty often associated with open-ended agile processes, and provides the dev team with a highly actionable solution definition that can be implemented sequentially by one team or in parallel by multiple sub-teams to meet the desired timeline.
We concede that our 30-Day MVP Model is unusual and is not suited to everyone and every software project; but if our approach resonates with you or whets your appetite, please schedule an appointment to discuss your app requirements.
Enter your information to subscribe to the Aezion blog digest.