This is a simple yet very helpful lesson I learnt while reading the book Inspired: How to Create Tech Products Customers Love. Most of the time, the team would wait until they have a functional product to validate with the user. And the problem is, it’s too late. You already invest a lot of time and money to the product. So why not validate it quickly and inexpensively with a prototype?

Let me quote the book here:

“The concept of minimum viable product (MVP) is one of the most important concepts in the product world. It has been around for many years. […] But I think most people would likely admit that the concept of MVP has caused considerable confusion within product teams, and I spend a lot of my time helping teams get value out of this critical concept.

The vast majority of times I meet a team that has been working hard to create an MVP I am able to convince them that they could have achieved the same learning in a fraction of the time and effort. They have spent literally months building an MVP when they could have had this same learning in days or, sometimes, even in hours. […]

While this is partly a result of the way most people have learned this concept, I think the root of the issue is that while the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support).

The MVP should be a prototype, not a product.

Building an actual product-quality deliverable to learn, even if that deliverable has minimal functionality, leads to substantial waste of time and money, which of course is the antithesis of Lean.

I find that using the more general term prototype makes this critical point clear to the product team, the company, and the prospective customers.“