MVPs: You’re doing it wrong.
Sorry for the sensationalist title, but this is important and I wanted to get your attention. There’s a serious epidemic affecting software companies — the Minimum Viable Product (MVP). Don’t worry though — there’s a cure, and it’s only 1,255 words long (Keep reading!)
Coined by Eric Ries in Lean Startup, The MVP is described as:
“[The] Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”
To be clear, the MVP is a great tool when utilized correctly. The problem is, it is rarely utilized correctly. But that faulty execution is actually a symptom of a deeper problem, a fundamental misunderstanding of what an MVP is, and what problem it actually solves.
So, I want take this opportunity to debunk the three most common misconceptions about MVPs that undermine this vital tool.
If I seem like a judgmental know-it-all — I can only offer this in my defense: I once held many of these misconceptions myself and learned they were wrong the hard way. Of course, I could also be a judgmental know-it-all.
MISCONCEPTION #1: Do as little as possible
I met a consultant from the payments industry who told me a common mistake new payments startups make:
“New payment startups always try to minimize fraud. That’s silly. If you want to minimize fraud, shut down your startup. I guarantee the incidence of fraud will drop to 0.”
(Ed note: This quote is from memory, so it may not be 100% accurate)
He wasn’t saying you shouldn’t care about reducing fraud, but minimizing it shouldn’t be your primary goal.
The same is true for MVPs. The least amount of work you can do is nothing. And sometimes that’s exactly how much work you should do — for example, if you can validate your idea some other way (e.g. customer interviews, researching a competitors product etc.)
But if you’ve decided an MVP is needed, don’t optimize for speed to market or building as little as possible. Instead, optimize for validation. Ask yourself the following question: What do I need to build in order to validate my distinct approach to solving problem x?
But careful — this is a loaded question. It implies that your product is novel in some way, that is has a distinct point of view, that you’re doing something that hasn’t been done before. It could be something novel in your user-experience, or in your messaging, or in your technology. But it has to be something. Because if there’s nothing distinct about your approach…don’t build an MVP! It is the wrong tool because there’s nothing new to validate.
Let me hammer this home with an example.
Let’s say I have an amazing idea for new product: an internet-enabled smart salt shaker. And let’s say I decide to build an MVP to validate my product.
Well, first I need to establish my distinct point of view, my unique approach to solving a problem. That’s easy: an internet enabled salt shaker would solve the age-old problem of under or over-seasoning food by dispensing the perfect amount of salt using a crowd-sourced database of salt proportions for every conceivable meal.
So, what to build? Let’s look at my options:
- Build as little as possible — nothing. In this particular case, this is probably the right call. But for the sake of this example, lets assume I’m dead-set on validating this product with an MVP.
- Build as little as possible — while still building something. I could build a non internet enabled salt shaker, but that wouldn’t really help me validate my distinct point of view. I wouldn’t learn anything new, and I’m better off just going out and buying one.
- Build a bit more. I could create an app that tells me exactly how much salt to add to various dishes. Granted, there’s no actual device here but this would help me validate that under and over-seasoning is a real problem worth solving with technology.
- Build the whole thing. A hardware prototype of my smart salt shaker. This is definitely the most expensive option, but it would also conclusively validate or invalidate my approach.
Assuming I was dead-set on building an MVP, I’d pick #3. It certainly isn’t the least amount of work, but it would give me reasonable confidence about whether this idea is worth pursuing (spoiler: it’s not).
(If you’re wondering why I picked this example, this Halloween I dressed up as the Co-Founder of a terrible internet of things startup, Salt.ly)
MISCONCEPTION #2: PIVOT! PIVOT! PIVOT!
Don’t be Ross.
When your product or feature is first released to the market, it is very exciting. But in that excitement, people can become impulsive and anxious — especially if the initial market reaction is different than anticipated. And the result of this anxiety is often the dreaded pivot. That is, to change course, sometimes drastically, or to give up on the original idea altogether.
Don’t do it. Step back and take a breath. If the only acceptable answer was to succeed on the first try, then this was never really an MVP. An MVP is a tool to validate or invalidate an approach; therefore, it inherently implies uncertainty and therefore risk. So don’t be surprised when …you’re surprised. That was the whole point.
Take the feedback you receive seriously, but don’t let it discourage you — and definitely don’t let others use it to discourage you. The issues you’re seeing may have nothing to do with your idea but some element of your execution. Maybe the copy was bad. Maybe the feature wasn’t discoverable. Maybe a million things.
Getting something to market quickly earns you the right for a few more kicks at the can. You bought yourself the time and agency to iterate and refine, so don’t panic and pivot…..pivot….pivot.
MISCONCEPTION #3: “We Released our MVP”
No you didn’t. An MVP isn’t a singular event. It’s a continuous process. It’s a mindset that should pervade everything you do, and every decision you make.
Even worse than panicking and pivoting is simply moving on: “We released our MVP quickly so we could move on to the next project.” I find this kind-of thinking heart-breaking because it misses the whole point of the MVP.
Your first release isn’t the finish line, it’s the starting gun. It’s your first opportunity to start to validate your approach. And so the idea of using your speed-to-market as an excuse to move onto the next thing is almost offensive.
An MVP isn’t some shortcut or life-hack to ship features faster. In the end, following an MVP approach might take longer because you spend more cycles iterating on your approach until you’ve nailed it. So, the benefit isn’t speed at all, the benefit is building products people want to use that solve actual problems.
Summing it all up
I think the misconceptions I’ve (hopefully) debunked and the problems they create are the reason why people have created variations of the MVP like the “Minimum Lovable Product” (MLP) or the “Minimum Marketable Product” (MMP). However, I believe these are just crutches that ultimately keep us from facing some of the underlying problems with the way we design, build and ship software.
So let’s embrace the MVP once more — not as a tool for speed, but as a way to help us create meaningful products.
