Minimum Viable Product, or MVP, is a way of launching a product without having to build every detail. Instead, the smallest (minimum) version of the product that will still work (viable) is built and launched, to provide the basis for future iteration and development. Customer feedback, business metrics and customer usage data are used to refine, improve or redesign, and extend the product, and the MVP approach can be used for new features as well as new products.
In this post, we’ll get under the hood of how MVPs work and what they’re for, but first, we’ll establish exactly what we’re talking about.
MVP 101: What it is (and what it isn’t)
MVP means Minimum Viable Product. It means the most basic possible version of your product, that still delivers the core value to early adopters. (That’s an important point.) MVPs come in several flavors, which we’ll get into more below. Suffice to say, some MVPs are little more than proof of concept, others use the same production techniques and distribution channels as the ideal product version. What they all have in common is that they represent, not what your product could do with, but what it can’t do without.
To illustrate the idea, let’s suppose it’s the way-back-when and you’re demonstrating a word processing program to potential business customers. It would be good if it had advanced editing features, event tracking, and the ability for multiple distributed users to work on a document at the same time. But those are nice-to-haves, at least in the world of forty years ago. What do you need? It’s got to let you type a useable page of text. Otherwise, it’s no good. Those ‘otherwise it’s no good’ features are the ones your MVP needs to have.
Consider the MoSCoW method:
Must-haves go in your MVP. Everything else follows.
Why MVP?
MVPs exist to show potential partners, investors and customers that your product really exists and works, and to let them experience some of its value for themselves.
Why don’t we just build a great, full-featured product instead of an MVP that will require iteration and work to bring it up to the required standard? Partly, because we’re not sure what’s the best way to do it. There’s also the question that we don’t know what the required standard is. But it’s also important to note that often, there just isn’t the time or budget anyway.
All these points play into each other. To build a perfect product by planning alone is probably impossible; if it were possible at all it would be horrifically expensive, and by the time you’d finished doing it, your competition would have outstripped you with a lighter, faster, albeit less perfect product.
The Ford company is a good example of this. In 1908, Ford began producing the Model T. It wasn’t Ford’s first car, but it was a lot of other people’s first car. And it looked like it. Nicknamed the ‘Tin Lizzie,’ the Model T was primitive… by the standards of 1908. It had wooden wheels and didn’t get electric headlights until 1915. Early models were plagued by what, if it were software, we’d call bugs. But it sold, in unprecedented numbers.
Model Ts were used for off-label purposes like running bandsaws and plowing fields. They were stuck back together with whatever was on hand, induced to run on gasoline, kerosene, ethanol. And they changed radically between 1908 and 1927, when the last one rolled off the production line. Other carmakers had better cars, more perfect, more ready to go. But they couldn’t produce them fast enough to keep up with Ford.
That’s partly because of the famous Ford factory system, but it’s partly because Ford went to market with the car he had and tinkered afterward. It went, and people could afford it. Other features — colored paint famously included — were optional.
Compare the Edsel, another Ford product, this time from the fully-mature Ford corporation of the 1950s. Ford began work on the Edsel, named for Henry Ford’s son, in 1955 for release in 1958.
The Edsel was designed by asking focus groups, survey respondents, and experts what they wanted in a car, and then adding as much of the result as possible. The process consumed three years, and when the Edsel came out in 1958 it proved impossible to sell. It was the perfect car, with all the right features, except the ones it needed to appeal to its customer base. And with three years and $250 million (in 1950s dollars!) sunk into development and tooling, it went out of production in 1960.
The point? The Model T was an MVP. It’s crucial to note that Ford didn’t sell a great set of wheels with no seats or engine. MVP doesn’t mean a basic, crummy version of your idea, it means a minimalist version:
Let’s turn to software: Check out all the software HubSpot has to offer:
Their current website is a paragon of modern design and layout, millions of businesses depend on their products, and they have a big team of developers working away to add features that will help the business continue to grow.
Rewind to 2005, though, and…
Maybe they should have waited to launch until they really had it all figured out, but probably not. However, a basic, almost nascent version of what HubSpot offers is already here.
Types of MVP
MVPs can be done multiple ways. The most common ways to approach the problem MVPs solve can be divided into high-fidelity and low-fidelity methods.
Low-fidelity MVPs
Low-fidelity MVPs don’t closely resemble the plan for the finished product. They can be rougher, much simpler, incomplete or even totally nonfunctional.
Low-fidelity MVPs are used to:
- Learn the practical value of the product
- Gain a better understanding of customer problems
- Find out how valuable your product is for customers
- Explore whether the problem is worth solving
- Check which approach to solving the problem would be most valuable for the customer
Low-fidelity MVP options include nonfunctional approaches like product designs and mockups that can sometimes fulfill the MVP role, without actually meeting its definition. It can also mean dummy versions of real user flows.
A classic low-fidelity MVP is Dropbox’s YouTube video:
Dropbox’s go-to-market strategy called for growing a user base of small-scale free or low-cost users. With short sales cycles, low per-client value and no paying customers yet they went with an MVP requiring no working product at all: a video, showing users the benefits of the tool. That made sense, too, for a solution to a problem most prospects didn’t even realize they had, because terrible file transfer experience was universal and thus an unchangeable fact of life.
High-fidelity MVPs
High-fidelity MVPs are relatively similar to what will eventually be released. They’re used to:
- Find out how much customers are willing to pay for the product
- Acquire and onboard early adopters, and strengthen the product’s market position
- Define, test and optimize marketing strategy
- Test value proposition, calls to action, communication channels and sales processes
- Identify, test and optimize growth strategies
There are other approaches to the MVP problem. One is sometimes referred to as the ‘piecemeal MVP’ — MVPs built from existing tools and software.
Piecemeal MVPs
Some startups built their first-version MVP entirely on no-code solutions and existing platforms. Then they demo the solution, acquire funding and hire a developer to build it from scratch, properly.
In other cases, the company might actually be up and running when it exhausts the possibilities of available tools and resources. This was the case with Groupon, whose founders never envisaged making a profit from the company. A WordPress website, a few PDFs sent by email, was enough for Groupon to build their business to the point that when they started developing new technology, they had a readymade market for it.
The original Groupon website is a good example of a Piecemeal MVP (Source)
Concierge MVPs
Another approach, almost opposite in method and concept, is concierge MVPs, where the company provides its value as a service to its customers — before it’s finished building V1 of its product. This usually means a small group of customers, often already paying, and a team of professionals delivering services that will be automated — once we build the tools.
Obviously, piecemeal MVPs make a lot more sense if you’re building a consumer-focused company where expectations might not be that high and customer value is relatively low. The concierge approach makes more sense if you’re pursuing a small number of very large business clients.
Crucial MVP Metrics
Whichever approach you wind up going with, you need to both define success, and measure it. The crucial metrics for MVP success can be considered in two groups: business, and behavioral. Business metrics concern the health and growth of your business, while behavioral metrics are more about your customers’ behavior.
Business metrics
Recommending business metrics for MVPs is complicated by the fact that while many businesses are the same age as their product, not all are. If you’re a relatively mature business launching an entirely new product, your needs are different to those of an early-stage startup.
It’s also important to consider whether you’re charging for your product yet or not. If you aren’t, MRR probably doesn’t tell you much. If you are, and you’re bootstrapping, it might be the most important number in your world, at least for a couple of years.
In many cases, it makes sense to take Dave McLure’s famous ‘pirate metrics’ (Acquisition, Activation, Revenue, Retention, Referral: AARRR!) as your starting point.
Behavioral metrics
Behavioral metrics like usage time, logins per month and time in app per login tell you things about how your customers are using your product. So do metrics from the place where business and behavior meet, like conversion to paid accounts from free trial (where relevant).
These metrics are more important if your product isn’t yet generating revenue, because they can help with validation and planning. So can early-adopter programs that let users sign up to paid accounts before the crowd, so they can beta-test your product and you can try them out as a customer base.
Takeaways
- MVP means Minimum Viable Product: the smallest amount of work to validate your idea
- It should be minimal, not basic: crucial functionality needs to be there even if it’s clunky
- Using MVPs lets you test, validate and iterate before you sink time and money into a feature or product no one wants
