Strategy
Startup Lean Coffee

Minimum Viable Products

Published on
June 23, 2020

At May’s Startup Lean Coffee, we focused on validated learning and Minimum Viable Products. You can download the raw notes here.

Minimum Viable Products

I've spoken with hundreds of startup founders who all shared very similar stories that went something like this: They've been building their Minimum Viable Product, or MVP, for 3 - 6 or even 12 months, they're late and running out of capital, but they're almost ready to launch. They're usually talking to me because they are losing confidence in their development team to get their product to market; and they want to know if I can help.

Is this a lost cause? The answer, of course, depends on many factors, including how much financial and emotional runway the team has left. It also dependents whether they are building the right product for the market that they aspire to serve.

It is generally accepted that most startups will fail; but it's very hard to measure startup failure rates with any confidence. According to Cambridge Associates, roughly 60% of venture-backed startups will fail to provide a return to investors. Then there are the companies that never get far enough to raise venture capital. And venture capital is only one way to finance a startup. What about startups that are bootstrapped, financed by grants or other non-dilutive means, or funded by individual or strategic investors? The fact is that not every idea will be rewarded by the market; in fact, most will not.

How might these founders take off when they are almost at the end of their runway? Or better, how might they have avoided coming to me under these circumstances in the first place? The answer starts with defining "Minimum Viable Product" and understanding why and how to build them.

Why Build an MVP?

Before defining MVP, let's make sure we understand why it makes sense to first build a Minimum Viable product before building a full product.

Every new product idea is based on a set of "leap of faith" assumptions. These are the fundamental assumptions upon which the product is based; if these assumptions are incorrect, the product will fail. As founders, we need to have absolute confidence in our vision while, at the same time, having a kind of clinical detachment from the assumptions on which our vision is based. We build MVPs in order to validate and refine these assumptions as early as possible, before we spend a lot of time and money designing and developing a full product.

We begin by validating that we are addressing a need that is worth addressing. What leap of faith assumptions are we making about the market need for our product? Who are our customers? Will enough of them use our product? Will they value it enough to pay for it?

Some of these questions can only be answered in the context of our envisioned solution. How well will our solution meet the market need compared to alternatives? How much is it worth to our target customers?

Such market and solution validation questions can often be tested through targeted customer surveys and interviews. The shortcoming of these techniques is that people tend to lie. Not on purpose. It's just much easier for most people to say that they like or would use or buy a product than it is for them to actually make a commitment by paying for it and using it.

We can overcome these shortcomings by asking our early target customers to make increasing commitments, like signing up to be on a waiting list for early access to the product, which can be done using techniques like landing page experiments, or pre-ordering the product, which can be enabled by crowd funding platforms such as Indiegogo and Kickstarter.

Both landing page experiments and pre-selling products require a significant amount of product definition. At some point, we will have defined enough of our product to be able to explain it to our target customers in great detail, including developing non-functional prototypes of our product using tools like Figma for software products or 3D printing for physical products.

What is an MVP?

At what point have we learned enough about our market and the solution that we envision providing to the market to build a Minimum Viable Product?

"The minimum viable product is that version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort."

— Eric Ries, The Lean Startup

Does an MVP have to include functioning product features? The short answer is often no.

If the leap of faith assumptions include major technical or production challenges, then it might make sense to validate the technical or production feasibility, as well as details like cost, timing, and skill set needed to overcome those challenges. Such challenges might include a particularly novel use of AI or a new manufacturing technique.

But if the leap of faith assumptions do not include major technical or production challenges, then why put the effort (and time and money) into designing and developing functioning product features? A vast number of market and product assumptions can be validated without building a functioning product. Even very unique user experiences can often be validated using no-code platforms like Bubble.

MVPs are not launched, market-ready products; they are a series of carefully designed experiments that validate the leap of faith assumptions on which our product is based.

How to Validate an MVP?

Start by prioritizing our leap of faith assumptions based on our best guess at how they might impact our eventual success. This is a triage exercise. Some of our assumptions will relate to our target market; others will relate to our product definition.

Then validate our assumptions based on those priorities. This validated learning is often conducted using iterative Build-Measure-Learn cycles. As we learn, our product definition becomes more clear, eventually resulting in a functioning, market-ready product, and finally achieving product-market fit. The faster we can learn, the better chance we have of finding product market fit before running out of runway.

GV shared their take on the Build-Measure-Learn cycle in this article describing what they call Research Sprints. The ideal Build-Measure-Learn cycle is supposed to look something like this:

The GV Research Sprint
The GV Research Sprint

The pitfall that founders often find themselves in is they try to build too much, too soon, before they have sufficiently validated their assumptions. As they build, they find themselves with too little runway left to experiment, leaving themselves with one-and-only one build cycle, and no measure or learn cycles, in which to achieve product market fit. They have one shot to succeed; they need to be correct about all of their leap of faith assumptions and they have to execute well the first time around. Their Build-Measure-Learn cycle looks something like this:

The GV Research Sprint
The GV Research Sprint

This was the situation that those founders I mentioned earlier found themselves in. If instead, they had chosen to start with non-functional prototypes or throw-away proofs of concept, and as they progressed through validated learning milestones, increased the stakes of each experiment, they would have learned much faster and maximized their chances of achieving product-market fit before running out of runway.  Their Build-Measure-Learn cycle would have looked something like this:

The GV Research Sprint
The GV Research Sprint

And even if they had concluded that their vision wasn’t such a great idea after all, at least they would have avoided a lot of wasted time and money building a vision based on incorrect assumptions.

For an in-depth discussion about how to build an MVP by incorporating these lean product management, UX/UI design, and engineering practices into an integrated methodology, take a look at Lean UX: Designing Great Products with Agile Teams.

About Startup Lean Coffee

These topics and more were discussed at a recent Startup Lean Coffee event that I organize every month.

Startup Lean Coffee is a monthly gathering of founders, early employees, advisors, investors, and anyone involved or interested in joining the startup world in any capacity. Our sole purpose is to help each other improve by sharing questions and experiences. All you need to bring is your attention, curiosity, and willingness to share.

We follow a Lean Coffee meeting format: a lightly facilitated meeting where participants democratically build an agenda, discuss each topic for a fixed time, and vote to continue discussion or move on to the next topic after the initial time runs out.

Startup Lean Coffee is graciously hosted by Betaworks Studios. Participation is free; but space is limited (even when we meet virtually). We usually meet on the 4th Friday of each month.

Sign up here to be notified about future Startup Lean Coffee events.

I provide advisory and consulting services that accelerate your growth by streamlining strategy, marketing, sales, design, engineering, and operations.