Why the Concept of MVP is Often Misunderstood

For anyone subscribed to the Lean Startup movement, you are no doubt well-aware of the concept of a Minimum Viable Product (MVP). It is one of the most important concepts for product people to understand. In the world of startups it’s even more important to grasp.

It was popularised in Eric Ries’ book, The Lean Startup, in 2011, but the phrase was first coined by Frank Robinson more than 10 years earlier.

The Lean Startup is seen as a Bible for many founders and product teams. I highly recommend the book, if you haven’t read it already. It is a must-read for all product people and an essential text for all startup founders.

Minimum Viable Misunderstanding

At Stratomic, we frequently discuss the MVP concept with founders preparing to raise their first round of funding. Unfortunately, the concept has been misunderstood by many. Even by those who’ve read Ries’ book.

The concept has confused some founders and product teams. They seem unable to extract value from something that is critical to the success of their early-stage business.

In the vast majority of cases I’ve seen first-hand, founders have spent tens of thousands building a minimum viable product. In the worst case, it was hundreds of thousands.

These same founders are proud of their MVP when they release it. But they quickly realise they’ve wasted months (or years) to find that they’ve missed the mark.

Rarely does an initial MVP turn into a hit; you’re playing on blind luck if you do manage to turn a hit. You end up having to spend more time, and much more money that you don’t have fixing the MVP.

When I explain they could have uncovered the same learnings in a fraction of the time and at a tiny fraction of the cost, I often get a look of doom. That’s because time and money are two things that most early-stage founders do not have much of.

So What Actually Is An MVP?

Many founders seem to trip up over the term, Minimum Viable Product. Or perhaps it has something to do with the way they’ve learnt the concept.

Many founders assume that, because the P in MVP stands for product, it must mean that the Minimum Viable Product has to be an actual product. The fact is, a Minimum Viable Product should never be a real product.

A product should be defined as something your engineers can build and release with confidence. Something that your customers can run their business on. And something that you are able to sell and support.

An MVP is a prototype, not a product.

Why does this matter?

Engineers are an expensive resource. Particularly for early-stage startups. Getting a team of engineers to build something that is of production-grade for the purposes of discovery is a waste of money. Even with minimal functionality, it is a colossal waste of time you don’t have. Your purpose at this stage of business is to find market fit and minimise the chance of commoditisation.

It is also the antithesis of both Lean and Agile thinking. So you can do much better, and learn faster, with much less.

The Importance of MVVP & MVS In The Discovery Process

A Minimum Viable Prototype is defined by a Minimum Viable Value Proposition (MVVP). The Minimum Viable Segment (MVS) is its dance partner.

When building an MVP, consider the smallest possible slice of value you can deliver to the smallest group of customers. Without this focus, you will end up in a product spin. You will build risky Minimum Viable Products for groups of people that are not well defined.

With a focus on the segment, you can build credible Minimum Viable Value Propositions. They should be aligned with satisfying customers’ important, under-served desired outcomes.

At Stratomic, we use customer research to build outcome maps around the core functional job-to-be-done. We then uncover important, unmet outcomes through outcome-driven segmentation. This allows us to build Minimum Viable Value Propositions for every important, unmet need in the segment.

This forms the basis of the Minimum Viable Prototype. This can often be achieved with an MVP that’s already built, with mere tweaks to your messaging to highlight important outcomes.

By focusing your discovery process on a mixture of prototypes and value propositions, you can uncover new market opportunities faster. What’s more, it requires a much smaller investment to get there.

Defining Prototypes & Products

So the first learning is to focus on building Minimum Viable Prototypes, not Products, for discovery purposes. These are conceptualised using Minimum Viable Value Propositions that cater to a Minimum Viable Segment. By switching from product to prototype, you can align the business and prospective customers, and prevent misunderstandings.

It’s therefore important to create a common understanding of Products and Prototypes across the business.

A prototype is used for the purposes of discovery. It is used to tackle risks up front before you build anything. The prototype enables you to learn quickly in a matter of weeks, days or perhaps even hours.

A prototype is a vehicle that aids you on your journey to discovering product-market fit.

When you combine a prototype with outcome-driven customer research, you understand the jobs customers are trying to get done. And you do this in the context of the prototype. This is not about what features they need. Instead, it’s about what they’re trying to get done, and the outcomes they desire at every stage of the job.

You achieve this by building a complete job map.

With a prototype, you can walk customers through the job. And you can rapidly iterate based on how you misunderstood the functional job in order to improve the quality of your learnings.

A product is something that your engineers produce during delivery. It is defined and built collaboratively, rather than sequentially. And it is developed with certainty. A product is something that you sell to your customers, and it is something that you can support.

A product also factors in the attraction, acquisition and retention of users and customers. A product is holistic. A prototype is not.

A product that you have delivered is what defines success or failure in your search for product-market fit.

Wrapping Up

The best product teams de-risk product investments before they build anything. These teams minimise the risk that customers won’t buy it. They also minimise the chance that users won’t understand how to use it. They maximise the feasibility of the build from an engineering and technology perspective. And they minimise the risk of there not being a viable business model.

This is all done in during the discovery process.

They define, build and deliver products collaboratively, not sequentially. The product team includes product, design, engineering and product marketing. They work side-by-side to come up with solutions that customers love, and that work for the business.

They do this with a focus on solving problems and achieving customers’ desired outcomes, not on implementing features. They are not focused on output, on delivering a solution. Instead, they are focused on ensuring the solution solves the underlying problems and inefficiencies in the job-to-be-done. It should do this in a way that achieves the customers’ important, under-served desired outcomes.

They are focused on achieving outcomes, and business results. This, fundamentally, is what building products is all about. The Minimum Viable Product (or Minimum Viable Prototype), is a vehicle that helps you to achieve business results faster and with less risk.



1 Comment

  1. You should leverage the ideas and needs of different customers together to use common code and common functionality to solve the needs of each application and surprise each customer, sometimes with things they didn’t think of but are useful to them.


Submit a Comment

Your email address will not be published. Required fields are marked *

Pin It on Pinterest

Share This