Minimum Viable Product vs Prototype

What’s the difference between a minimum viable product and a prototype?

No, it’s not the start of a lousy tech joke. It’s a genuine question that I think is worth answering.

Many people use the two terms interchangeably, and I have seen how this can sometimes impact the core product development.

A Minimum Viable Product

So, let’s start with a minimum viable product (MVP). What is an MVP?

An MVP is an early version of a product that contains just enough features that provide value to the first group of customers.

This initial version can be used to gather feedback which will inform the further development of the product.

Eric Ries helped to popularise the term in his hugely successful book The Lean Startup in 2011. The term MVP predates this book, being coined by Frank Robinson ten years before this.

An MVP seeks to reduce wasting effort on developing features that customers do not want, or work the way they want. This approach goes hand in hand with an iterative development model, where the MVP can be built upon rapidly, seeking continued feedback along the way.

An MVP proves that a market exists for the product, and defines a minimal set of features that early adopters are willing to purchase.

A Prototype

So, how does this differ from a prototype?

A prototype is an early sample or demonstration version of a proof of concept. It is a term used in numerous industries for physical and digital products alike.

This prototyping process, also known as materialisation, makes something that was previously theoretical more real.

A prototype in the software world could be used to demonstrate a product idea or feature. It does not have to be an entire product. Some parts of the prototype may be fully functional. Others may only appear to be working, used to illustrate ideas and how things could fit together.

I have used prototypes many times with great success.

One good use of a prototype could be to demonstrate or work on a particular feature outside of the main application. The prototype approach allows for rapid development and can be used to gather immediate feedback before spending significant effort developing the final version within the product itself.

So, what is the difference, and which should I use?

They can be confused, as they do share many traits. It is important not to confuse the two development approaches.

Both approaches result in developing something smaller than the final more complete product.

Both approaches allow for rapid feedback.

They are fundamentally different though.

An MVP is something of value to customers, is something they are prepared to purchase.

With an MVP, while the feature set may be relatively small, that feature set still has to work. Customers are paying, so expect a certain level of quality. An MVP is a solid foundation upon which development can continue.

A prototype may be part of a feature or just one of many interlinked elements. It serves to gather feedback but in a controlled way.

Usually, development teams or product representatives will demonstrate prototypes themselves. They aren’t something to be deployed across a group of customers.

The learning gathered from a prototype can be used to inform the product roadmap. The prototype code itself though, given the demonstration nature is unlikely to be of a quality that could be included as-is in the product.

I recommend you consider both as tools available to you.

I would massively recommend an MVP to test the market.

Once you have a set of customers, don’t be afraid to use prototyping outside of the main product codebase as a way to gather learnings.

Don’t try to do this in the main product, as that’s where risk starts to get introduced, and the product can be seen to be unreliable.

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Related Posts