How to Get 3 out of 3 on Your MVP
Our craft has embraced the concept of Minimum Viable Product, or MVP for quite some time. We just tend to get it a little wrong by focusing on just one of the three letters in the title. Here’s how you get more of the “V” and “P” into your MVP.
Popularized by Eric Ries’ excellent book The Lean Startup, Minimum Viable Product is a ridiculously powerful tool in the process of finding and proving new business models.
As with most powerful tools, it also comes with a caveat emptor that it’s only useful when applied properly — and in the wrong hands can even be harmful.
The biggest threat lies in the sequencing of the letters. MVP starts with the most appealing, yet dangerous one: “M”. Too many drift off at that point and never make it to the latter two.
The danger with the “M” and the word “minimal” it stands for, is the promise of taking the easy way out or doing the bare minimum of work, which completely neglects the balance required by the concept. Too often people take the word alone to mean “however we can get there with the least investment” or justify any random cutting of scope with “we’re just going to MVP it”.
To balance things out, let’s take a moment to consider what the other two really mean.
V is for Viable
Some people have tried to fix the MVP problem by tweaking this word. Among others, MLP, or “Minimum Lovable Product”, has been thrown around as a solution.
I don’t fully agree with this. First off, it addresses the wrong problem. The word “viable” was never at the heart of the issue.
Second, I don’t really think “lovable” is better than “viable”. It takes the second component even further from the actual intent: the end-to-end viability of solving a single isolated customer problem.
P is for Product
The most overlooked part of MVP is definitely the product-part. A product should be something that’s monetizable, scalable and replicable. If there’s no 💸💰 involved, it’s most definitely not a product. If there’s no built-in path to replicability or scalability, also not a product.
This doesn’t mean that MVPs should be monetizable, scalable and replicable in itself, but there absolutely needs to be an existing strong hypothesis on what the path from the MVP is to these and why the MVP proves the path is realistic.
Bringing it All Together
When we have a balanced MVP where all parts are equal, it should reflect these characteristics.
Depth Before Breadth
A great MVP solves a narrow problem really well instead of multiple problems kinda-sorta ok. This is where the “minimum” part gets to truly shine: narrow your target audience of the MVP ridiculously small and go full blast at that target. Or as Basecamp (then 37signals) put it in Getting Real, “Half, not half-assed”.
My favorite example of this is RapGenius. It started out from the really narrow niche of explaining hiphop lyrics to lame white kids like me using a clever annotation engine.
Then they expanded to annotating lyrics in general.
Finally, they’ve been working on expanding their technology as the #1 annotation engine for the Internet.
Whether they are successful or not, their path shows really well how going narrow-and-deep can work in building a business.
If you’re trying to be something for everyone from out the gate, you end up being nothing to no one. Be everything for someone instead.
Focus on What You’re Proving
A common problem with start-ups is trying too hard to prove already proven things, like the ability to push people to the top of the funnel with marketing tactics, to think up a swanky UI, or to build a fancy website. Those are the easy part.
To do an MVP, you need to have a crystal clear view on the unknown you’re trying to prove, whether it’s a new business model or a new type of feature on an application. Everything else should be secondary.
You shouldn’t be trying to make revenue or especially profit. You should be trying to prove that when applied at scale, the thing you’re hypothesizing will lead to 💵.
Money Talks
Although money as a KPI of an MVP is wrong, it’s by far the best indicator of viability.
Words and attention prove absolutely nothing. If customers aren’t voting with their wallets, they aren’t telling you anything. Anybody can get positive comments, Facebook likes or other vanity metrics that cost nothing to the person giving them.
If you’re really building a product and have a hypothesis of the scalability based on desirability, you’ve proven nothing until someone parts way with their hard-earned cash.
Cut the Right Corners
While I already made the case of “minimum” being the most dangerous word, it can also be the most powerful one. When you truly understand what matters and what doesn’t in the hypothesis you’re trying to prove, you can get really aggressive in cutting corners.
If it really proves your point end-to-end, the technical part of your product can really just be a single page on the web that has a unsexy form that submits an email lead to your inbox. What happens after this can be a horribly tedious manual process that in itself is not scalable what-so-ever.
The key here is that while you’re proving you have something you can productize, it doesn’t mean you should spend time on the things you know you can make happen with the suitable investment.
The online UI that the web form is representing can easily be formulated into an elaborate application.
The tedious manual back office process can easily be replaced with the all the automation you can swing at it.
Sure, if your product happens to be the most elaborate web UI the world has ever seen, or a back office process fine-tuned beyond anyone’s imagination, then focus on that. Though I’d be willing to bet that if you think one of those is your product, you actually have no product.
MVP is Just Step #1
The only thing worse than poorly executed MVPs are orphaned MVPs that have no follow-up.
If you’re MVPing a business model, you need to be able to make conclusions from it:
- If it soars, pour gasoline on it.
- If it’s lukewarm, try to see if you can isolate a nucleus of potential from it and revisit the core of your idea.
- If you find yourself yelling into the void, consider pulling the plug.
The worst thing you can do is trying to pour gasoline on a fire pit that isn’t in flames. Either you’re just wasting gas on cold lumps of coal, or you’ll douse whatever little kindling you had going on there.
The “gasoline” here naturally is any scaling activities, like marketing efforts, expanding to different geos / segments or in general, assuming that doing more of a failing thing will equate to success. Hint: that absolutely never happens.
Disclaimer: yes, critical mass is a real thing, but still requires a baseline desirability to apply. Don’t fall into the trap of justifying your failed MVP by not getting enough attention for it.
Follow Through
If you’re applying MVP to a product feature, whatever you do, don’t ship and forget. This is truly wasting the value of an MVP: learning.
The whole point of doing things at an exaggeratedly narrow scope is proving a point. The value is not the feature itself, but the insight you draw from it.
This is a similar fallacy as the “Agile = speed” issue I wrote about earlier: if you’re using MVP as a way to trick yourself into shipping features faster, you will either find your application buried in tech debt or with half-baked features cobbled together in a very unpleasant way.
An MVP should always be followed by multiple future iterations where the learnings from the MVP and later iterations are rigorously applied.
If you’re not doing that, you’re not building MVPs. You’re just trying to get by with minimal work.
And that’s just lazy.
Like What you Read?
- Join my Email Gang on TinyLetter! One weekly email, no spam, no ads.
- Please join the discussion in the comments below!
- Read more about why I’m writing these posts:
