Setting Expectations when Building an MVP

The phrase Minimum Viable Product (MVP) gets thrown around a lot in technology. Everyone seems to have a different definition of ‘minimum’, ‘viable’, and ‘product’ which leads to confusion and misaligned expectations. I’ve seen founders spend hundreds on their MVP and others spend hundreds of thousands. Some spend days, others spend months. Before building an MVP, it helps to get on the same page.

First, what is the purpose of an MVP? At its core, an MVP is a strategy to test the initial assumptions surrounding a new technology idea or concept. Instead of building something complicated, time-intensive, and expensive, a well-designed minimum viable product allows learning and iteration to happen much faster.

When explaining an MVP to founders, I find it best to break up the phrase and define key terms in my own words. These aren’t perfect but they capture the essence of an MVP.

Minimum Viable: The smallest investment (time, energy, money, etc) needed to successfully test an assumption.

Product: A coherent experience that solves a clear problem for a group of users.

Minimum Viable Product: A coherent experience, built with the smallest investment needed to successfully test key assumptions for a group of users.

In theory, it’s simple. In practice, most MVPs veer off course. To drive the point home, how about a definition for what is not an MVP as well. An MVP is not: a perfect experience, built by any means necessary, to test all assumptions, for many groups… and makes a profit. The non-MVP is worth calling out because it’s the closest to what most first-time founders expect from an MVP. At the earliest stages, adherence to something simple is an important part of survival. Complexity kills ideas and limits a founding team’s two greatest strengths, speed and focus.

Why do we struggle to embrace a true MVP? For most of our lives, we have been buying goods and services that others created. We have been marketed to since birth. Every day, we are surrounded by thousands of fully formed products. Overexposure skews our understanding of what constitutes “good enough”.

Tim Collins, a well known business leader, has a popular concept, “Fire bullets, then cannonballs.” The following excerpt comes directly from his website, summarizing the idea of bullets vs cannonballs, “Picture yourself at sea, a hostile ship bearing down on you. You have a limited amount of gunpowder. You take all your gunpowder and use it to fire a big cannonball. The cannonball flies out over the ocean…and misses the target, off by 40 degrees. You turn to your stockpile and discover that you’re out of gunpowder. You die. But suppose instead that when you see the ship bearing down, you take a little bit of gunpowder and fire a bullet. It misses by 40 degrees. You make another bullet and fire. It misses by 30 degrees. You make a third bullet and fire, missing by only 10 degrees. The next bullet hits—ping!—the hull of the oncoming ship. Now, you take all the remaining gunpowder and fire a big cannonball along the same line of sight, which sinks the enemy ship. You live.”

Instead of taking big shots and missing them, use small attempts to test, calibrate, and adapt. In Collins’ world, an MVP is a bullet. It may take a few attempts to find the right path forward. Using fewer resources to test early assumptions leaves more resources available to make larger investments as confidence increases. It’s the same reason players in poker don’t go all-in on the first hand. Small, calculated bets allow us to gather information and evidence to build better solutions.

Great solutions solve a real problem. Instead of focusing on delivering a product, push to deliver value. An MVP is a means to validate the value you suspect a solution might provide. Below is a common illustration that outlines two ways to think about iterating. The first is progressive. Each step gets closer to the goal, but the only viable product is at the end-state. The second example is iterative. At each step, there is a complete product. It’s different from the end-state, but it’s never without some utility.

While the previous illustration captures the essence of an MVP, the following is my preferred analogy. Notice the progression from step to step. Consider the similarities between each stage. Unlike the skateboard to car progression, each step below is roughly the same value. The scale and complexity is different, but the essence is very much the same.

Building off the cupcake illustration, the extent to which quality matters is regularly called into question when discussing an MVP. Doing less doesn’t require lowering your standard. A helpful phrase I like to remember is, “Do less but better.” The next illustration captures the nuance of balancing quality and effort. The pyramids below represent minimally viable effort, but the pyramid on the left directs all energy on increasing usable features. The pyramid on the right presents a more distributed approach, leaving room to still delight users.

Remember, the purpose of an MVP is learning. The faster you can validate what users want, the more confidence you’ll have that you are heading in the right direction.

Subscribe
Get notified as soon as new content becomes available. Stay in the loop.