Making a Distinction Between MVPs and Prototypes

The terms Minimum Viable Product (MVP) and prototype are often used interchangeably in most of the technical literature and blogs. While working with startups, I have observed much confusion caused by this. I believe it is worthwhile to make a distinction between the two. In this post, I highlight the different strategies for determining whether to build an MVP or a prototype. It is a conscious decision that needs to be made during the concept phase.

What are they?

Prototype is a model of a product built to test or demonstrate the feasibility of a concept.

Minimum Viable Product (MVP), while also serving the purpose of maximising validated learning for the least amount of effort, is built with the most basic set of features that allow the product to be functional and deployed into production in order to accelerate time to market for new product introduction. It is more than a proof of concept.

The original term MVP was defined by Frank Robinson, and popularised by Steve Blank, and Eric Ries (for web applications) as a key concept in Lean Startup Methodology. However, the two concepts are not differentiated.

How are they different?

An MVP is the first version of software fit for release to customers. It has enough functionality to be considered useful and to kick off the build-measure-learn feedback loop. The purpose is to maximise learning from early customer feedback with the least amount of implementation effort. The design and implementation process requires some rigour and discipline with a high level long term product strategy in mind, in order to set out a good foundation for future development.

A prototype on the other hand is built as quickly as possible to prove or disprove the viability of a planned solution. The focus of a prototype design is its presentation and usually not fit for deployment into production. It might not even be software. Paper and Power Point prototypes are popular methods for getting a feel for the usability and features of a product.

Prototypes are designed for a small audience and should be thrown away. However, it is frequently the case that successful prototypes are built upon; a tactic that leads to unnecessary long-term pain. Using prototype as a foundation for production software will incur a large amount of technical debt (a concept introduced by Ward Cunningham), as there isn't the time and resources available to build good code and practices before delivery. If it is subsequently used as the basis for ongoing product development, organisations will have to "pay interest" in the form of slower development progress, or "pay principle" in the form of rewriting the poorly designed code.

An MVP is usually released to a sizable user group (e.g. a trial or the standard user group) in order to collect user feedback and market data. You let these customers loose on your MVP before implementing the complete set of functionality, so that the feedback from customers can guide future product development. A prototype is more for the purpose of demonstrating a product idea and therefore, is not usually released to any target market customers to be used.

The term MVP has been a particularly popular concept in the context of startups. Even those who have popularised the term have sometimes referred to it as prototype MVP and state that the letter 'P' in the acronym is misleading. In my view, videos, mock-ups and presentations are not MVPs. Apart from serving the same purposes of testing product hypothesis with minimal effort and accelerating learning, MVPs should also deliver tangible initial customer value. Prototypes only demonstrate promised value.

How to choose between them?

When deciding whether to build a prototype or an MVP, it is a good idea to consider the following questions:

1. What is the vision of the product?


2. What are the target user groups and what needs does the product address for them? This question determines what are the product hypothesises that you are testing i.e. the goal of the prototype or MVP.


3. What is the competitive landscape and what are the product differentiators? Or if it is a technical solution for the internal business, what problems does the software solve?

Whether you decide an MVP or a prototype is the right thing to build first, ideally the design should clearly reflect the product vision in some form and the key market differentiators (i.e. what problems the product is attempting to solve).

To determine what to build, the questions to ask are:

1. What is the purpose of the prototype or MVP, i.e. what are the riskiest assumptions that require validation?


2. Who are the users/audience you want to collect feedback from?


3. What is the funding strategy? What are the available budget and resources, and timeframe targets?

Depending on what hypothesis is to be validated, a prototype is often sufficient and no development might be required. It is of course perfectly valid to build a simple prototype first before developing an MVP.

Steve Blank who started the lean movement gave a good example on this point in his post "An MVP is not a Cheaper Product, It's about Smart Learning." Blank recommended to the team they rent the hardware and process the data by hand - an approach that took significantly less time and initial investment then their original plan of implementing the hardware and software solution with a minimum set of features. In this post, Steve referred to the solution to test the hypothesis as an MVP. The recommendation he gave to the team was to put together a demonstrable proof of concept - an MVP based on his definition but a prototype if we differentiate prototypes from MVPs. It is precisely due to the confusion within engineering teams (who are inclined to build an MVP when a prototype might suffice) and novice technology entrepreneurs (who might confuse brochureware for production-worthy software), I believe it is valuable to make the distinction between the two.

Assuming you agree with my definition of MVP being the first iteration of production worthy software, deciding to build an MVP requires commitment and I would advise going through the preliminary analysis with the view to establish a viable business case before proceeding.

The purpose of a business case is to qualitatively and quantitatively rationalise an investment. Apart from stating the business objective, it estimates the expected benefits and costs in measurable terms e.g. Return on Investment (ROI), pay back period, initial investment (including internal and external) and projected cash flow. Also, it outlines the critical success factors and identifies the key risks, issues and dependencies. A business case is a living artefact that evolves throughout the implementation of the product and is used to validate if the overall project is on track at key stage gates.

So why would a team decide to implement an MVP instead of building a prototype first? It could be that the business case and product concept are sound, and there is enough funding and minimal risks. If this is the case and the priority is to launch a functional lean product to gather more extensive user feedback, MVP would be the right thing to build.

What to watch out for?

The biggest challenge (as demonstrated in Steve Blank's post mentioned above) is to clearly define exactly what concept is to be validated and what is the most effective way to validate it. Once the goal is clear, the other challenges are scoping and design.

In building an MVP, the objective is to achieve the optimum balance between maximising investment return/learning and minimising risks. From a scoping perspective, to minimise risks, it is absolutely necessary to do some high level market data gathering and user requirement analysis. From a technical perspective, it is difficult to get the balance right to not only quickly elicit market response, but also lay out a good quality foundation for future work. However, taking too long to build a perfect MVP may cause you to miss the market window. Accept and understand that incurring some level of technical debt at the early stage is inevitable and a quick feedback loop would allow accelerated learning. When the uncertainties and risks early on during the project are high, knowledge acquisition is of the highest priority. The objective of gaining knowledge in order to build the right thing needs be delicately balanced with building it fast and building it right.

The Concept Phase is a critical time for any project whether it is in a startup environment or an established business, when many challenging decisions are to be made. An experienced team understands the trade-offs, risks and rewards, and makes their decisions consciously and strategically.