DON’T FORGET THE “V” IN MVP
“*As a business strategist with a track record of building technology businesses from start to exit, I’m frequently asked questions about these and a range of related topics. I’ve written these articles because I like to operate At Scale. So when I advise startups 1:1, I often turn that into a blog or LinkedIn post. I work to help answer your questions in the simplest ways possible. These articles are for educational purposes only. If you have any questions you’d like me to answer, please send them to me using my contact form.”
What is a “minimal viable product” (MVP)? Over the years, I’ve found myself talking to lots of tech founders about their MVPs. It seems clear that the original message of the lean startup has become distorted, and many entrepreneurs — and intrapreneurs — have forgotten about the all-important “V” in a minimal viable product.
“V” is for “viable,” not “version.”
So often, I see new product launches starting with a very limited version of a product – likely under the mistaken impression that as long as you build something — anything at all –, it can be called an MVP. But MVP stands for a minimum viable product, and there’s no value in delivering a new version of anything if it isn’t viable – meaning that it doesn’t provide a solution for the customer need that was identified.
Table of Contents
A Minimal Viable Product Math Lesson
A Minimal Viable Product is More Than Just Development Work
A Minimal Viable Product Math Lesson
Why is achieving MVP so elusive? Sometimes, it’s because the team hasn’t really identified a customer need at all. Instead, they have fallen in love with technology and found a way to apply it to a “job to be done.” However, it just might not be a job that many people need to be done, at least not if it costs money to get it done. This is a classic case of invention being the mother of necessity rather than the other way around.
In these situations, the teams are building for an “imaginary customer” – a customer they’ve created in their minds who they’ve convinced themselves exists through confirmation bias. The launched product isn’t likely viable because the need they are addressing isn’t tied to a viable customer.
For example, while I was Chief Corporate Strategy Officer at UserTesting, I met with many small startups trying to get into the user experience space. One was offering prototype testing but only for existing digital products. During the course of discussing their MVP, it became clear that it was only relevant to companies that (1) already had mobile apps, (2) had thousands of daily or weekly users, and (3) were constantly iterating on their designs. This reduced the “target audience” for the MVP down to very large companies with mobile app businesses. And it wasn’t clear that those companies were going to try a new startup offering instead of what they were already doing to test their iterative designs (such as, say, A/B testing). The startup had designed a product for a customer that they probably couldn’t sell into and that had other existing options that were “good enough.” MVP math lessons #1.
Better Than “Good Enough” ≠ “Viable”
Even more often, teams deliver Minimum Version Products instead of Minimum Viable Products simply because they either don’t understand what their differentiation is or, even worse; they don’t have one identified at all. If there’s nothing to set a product apart from those of other businesses, then there is little reason why it would be different from its competitors and provide a competitive advantage. And this is exactly what an MVP is supposed to do.
Take another example. I recently talked to a company that built a “targeted marketing solution” that required their customers to mass email their target audience! There was nothing “targeted” about the mass email approach. They had identified a customer need – a targeted marketing solution that would help their customer be seen through all the generic marketing noise. But their alleged differentiation didn’t exist, which meant that the MVP was just another single-feature email marketing tool without differentiation. This product was their minimum version product – but it wasn’t a viable one. MVP math lesson #2.
“Differentiated” includes something “different” (or, in math speak, Differentiated ⊃ Different)
The above two examples illustrate that, for your “MP” to be “Viable,” it must be differentiated, and ‘better than good enough” isn’t good enough. Lots of teams confuse better with different. The minimum product you launch might be faster than what’s currently on the market, or easier to use, or even cheaper. But it’s hard to make something so much better that a customer will stop doing what they are used to doing. Inertia is real.
I can’t recall all the products that I did not switch to because, while they were likely a little better than what I was currently using to solve my need, the amount I perceived them to be better wasn’t worth the switching costs for me. I’m a bit of a tech geek. I consider myself an “early adopter” in terms of Geoffrey Moore’s classic book Crossing the Chasm. Suppose someone like me is rejecting countless products even though they may be faster, simpler, or cheaper than what I’ve already got. In that case, you can bet that the majority of users aren’t going to see those products as solving a critical need of theirs—the final MVP math lesson.
Better ≠ Different
A Minimal Viable Product is More Than Just Development Work
It’s easy to understand why something that was intended to become an MVP ended up being only an MP.
So often, the MVP is the brainchild of the technical genius. That person wants to turn their new technical idea into a product and often doesn’t have experience in reaching out to customers and designing a discussion with those customers to really understand their needs. This represents a gap between the development team and customer research. Product development happens – but in the wrong direction.
But just as often, the idea for an MVP comes from someone else – perhaps a product person, perhaps the CEO, perhaps someone on the customer-facing side. But between idea and reality, a significant failure in translation and project management occurs.
Some teams manage to only deliver minimum version products because, while they want to create something better – something viable – they aren’t provided with the resources to do it. It’s not just an engineering effort. As I just mentioned, the team needs someone experienced in research to talk to customers and understand their needs. They need someone experienced in project management to work with leaders to define how to get to “viable” and how to add the work to a roadmap. They need someone from product marketing to help articulate the differentiation from other solutions so that the final product can be positioned properly. For an early-stage startup, all of these functions are likely going to have to be carried out by one person – perhaps the CEO! Regardless of who it is, if they don’t invest the time to do these things well, the engineering effort alone may not achieve the “V” in a minimal viable product.
Relying Too Much on “Minimum”
In larger companies, I have seen a different reason for not achieving a real minimal viable product. Technical teams pride themselves on “sprints” and “lean” methodologies. And while iterating is important, some teams confuse products with iterations. You can iterate your way to an MVP, but you can’t launch a pre-MVP iteration.
According to Eric Ries, the creator of the Lean Startup Methodology, an MVP should do three things:
Get into the market as quickly as possible.
Allow for testing with real users before committing to full development.
Enable collection of feedback on the product from the target consumer group.
A viable MVP should have enough value to achieve initial adoption and provide enough benefit to keep early adopters on board. Suppose you get into the market quickly so that you can test with real users, but you don’t get any real users because you put something in the market that wasn’t ready yet. In that case, you’ve misinterpreted the learnings from the lean startup methodology.
The biggest problem with delivering a Minimum Version Product rather than a Minimum Viable Product is that the “build – measure – learn” loop of the Lean Startup method isn’t going to offer any lessons for your business. If you don’t find any customers that use your product, then it could mean that you were wrong about the need or that you just didn’t build a full MVP. And the problem is that you just won’t know which one it is.
Five Quick Do’s and Don’ts
Do gather appropriate feedback. Everyone says to do this because it’s so important. Talk to your target customers, not your friends or your family. You need to reach real people who don’t know you and aren’t going to feel bad telling you your idea sucks. Talk to 10 – 20 of them for a B2B product and many, many more for a B2C product.
Don’t talk to your target customers about the wrong thing. Don’t ask them what new product they want. Product ideation is your job – you are the innovator, not your customer. But do ask your target customer what problems they have that they hate to deal with. Like really hate to deal with. Talk about their problems so that you can provide solutions for them.
Do treat your MVP efforts like a cross-functional project involving user research, project management, development, and product marketing.
Don’t get caught up with “releasing quickly.” Work fast but build something that actually adds value to your target customer. Releasing a minimum version product won’t help you gain adoption from real users, and your time, money, and energy will have been wasted.
Don’t start with the “minimum” in MVP. Instead, focus first on the “viable” and then pare it down to the “minimum.” Otherwise, you’ll be testing just an MP and won’t learn anything from your test.
Remember that the “V” in a minimal viable product stands for viable.