Learn how you can Unlock Limitless Customer Lifetime Value with CleverTap’s All-in-One Customer Engagement Platform.
Is a minimum viable product a fancy way of saying prototype? Or is it a proof of concept?
A proof of concept determines if the technical challenge can be solved and usually comes before the minimum viable product (MVP). Building on that proof of the prototype(s) is a necessary stepping stone as you iterate towards the MVP.
But technically, a minimum viable product should prove two concepts.
Continue reading for the core tenets of the minimum viable product methodology or jump to our full infographic below. We include examples from companies who have built immense value after first proving the business model through building their MVPs.
A minimum viable product is the most rudimentary form factor or feature set that early adopters will use and contribute feedback to during the product development phase.
One caveat here is that the MVP should solve the core problem the value proposition aims to address while demonstrating value to customers.
So an MVP is like a beta test?
Yes, and no. While you should get your MVP into the hands of real, paying customers and test how they use and navigate the app, a formal beta test usually comes once the lessons from the MVP have been implemented and the app is slightly more sophisticated.
We could argue semantics until we’re blue in the face, but let’s instead dig into why you should build an MVP for your company.
Why not the maximum viable product?
The foundation of an entirely new product idea is the hypothesis of how the world should be. As Patrick Collison, founder and CEO of Stripe, puts it, “You’re trying to figure out in the early days of starting a product: are we wrong or is the world wrong?”1
It’s important to put your world-changing hypotheses to the test with the smallest amount of money, time, and features required to make a standalone product.
Here are the main benefits of building an MVP:
Let’s imagine you set out to build a new mobile app, which took months to design and thousands of dollars to develop. It was almost ready to launch but was further delayed to get all the bells and whistles built.
You finally get the product into the hands of users and quickly determine nobody uses the bells or whistles.
This is where the minimum viable product could have saved time and money. Build the basic foundation of the product to prove it works for customers and they are willing to pay for it. Once you are validated in your endeavor, other features can be rolled out — the figurative bells and whistles, if you will.
There are many reasons to get the product into the hands of real users as fast as possible. The previous section is one such reason but another is to gain what we have coined an edge case education.
Once the product is in the “wild” there’s no telling how people will choose to employ it in their lives. In some cases, the product will be used for a different end goal than you initially intended and these edge cases can be a great educational tool.
Bumble, for example, noticed many users were finding the product helpful for networking and meeting potential business partners. This observation led them to develop Bumble Bizz, a platform to connect professionals.
Perhaps you discover a more intuitive way for users to interface the product, or an entirely new market that you had not anticipated — the minimum viable product can facilitate this customer discovery process.
It’s science.
Well, it’s the fourth step of the scientific method — test your hypothesis. The minimum viable product will allow you to quickly answer Patrick Collison’s question: “Are we wrong or is the world wrong?”
If the customer persona you envisioned using the product is willing to pay for your solution and use it in its intended way, then your hypothesis of the world is correct.
If your product is met with disinterest and your target market is unwilling to pay for the product, it’s time to consider pivoting strategies. These lessons for pivoting are clarified by the methodologies of building your MVP.
The methodologies behind building an MVP are meant to be quite simple and straightforward. In fact, Eric Ries’ Lean Startup concept breaks it down into three main categories: build, measure, and learn. 2
It’s essential to build the bare minimum and measure the actual performance. There is no better stress test for a product than actual usage, or lack thereof. If the MVP is not finding success in the hands of users, it can be natural for the creator to make excuses for its failure.
If your MVP addresses the core problem and you continue to measure overwhelmingly negative results, the lesson is clear: Move on to solve a different problem or the same problem in a different way.
Let’s dig into these methodologies individually.
The product development process can be like navigating a ship in stormy conditions: You must trust the guiding instrument and hold your bearing. Similarly, product managers are faced with zealous brainstorm sessions around additional features and ideas that change the course and ultimate destination.
Don’t let this happen. It’s important to take a step back during the development of your MVP and ask objectively, “Are we still solving the core problem or has our solution become muddled with irrelevant features?”
Don’t lose sight of the end goal. Michael Seibel, CEO of Y Combinator, advocates for building your MVP quickly. This makes it easier to stay on task and focused on the problem at hand.3
Going with your gut can only get you so far. Once the actual performance measurements are analyzed, that gut check can feel like an actual punch to the stomach.
The first decision to make regarding this step is understanding what your key performance indicators are.
What does success look like for your company? For many businesses, it will be revenue growth and retention rate, while for others it is simply daily active users compared to monthly active users.
If you’re wondering what metrics and KPIs you should be tracking for your app, download our whitepaper: Metrics That Matter for Growth.
One caveat to this point is that you should rely more heavily on feedback from paying customers and less on feedback from friends and family.
When users spend their hard-earned money on your minimum viable product it’s because you are solving a big enough problem to justify their risk of investment. These are real users willing to pay for your solution because they face actual problems, unlike those who may support your app out of friendship – but do not actually face the same problems.
Analyze who uses your product, how they use it, why they use it, and how much the problem is worth to them to remove it.
It’s possible that your intended audience is not actually who benefits from the product most. It’s also possible that the product is being put to use in a vastly different way than anticipated and may even be solving an otherwise unrecognized problem. Your first MVP will probably not be your last.
How are these principles being practiced in the real world? Let’s dig into some examples of minimum viable products that evolved into valuable product-driven businesses.
It’s not just the first-time founders who are building and testing minimum viable products. The team behind Cruise Automation is comprised of multiple members of the founding team for Twitch.
Kyle Vogt, co-founder and CTO of Cruise, learned a lot from their minimum viable self-driving car. To save on engineering time and cost, the team decided to retrofit an Audi S4 to prove their self-driving technology. As the product developed, Vogt realized that retrofitting their system on every make and model variation would be near impossible to perfect.4
The minimum viable product from Cruise was validated by automaker GM who acquired the technology company for more than $1 billion.5 This allows the team to focus on perfecting the technology while GM handles the automobile manufacturing process.
The founders of Airbnb were short on rent money and had an idea to make accommodations for an oversold conference with all hotels booked in their city. Their idea was to host guests in their apartment on air beds.6
This truly bare-bones minimum viable product was enough to signal that their solution aligned with a common problem. Airbnb’s short-term rental MVP worked well enough for customers to pay for it and provide valuable insights into future features.
Kevin Systrom developed and raised funding for his mobile app Burbn. The idea was to enable people to check-in and share their experiences at various locations with friends.
The app was not an instant success and in fact, many people found it confusing to use. The Burbn team decided to pivot and focus on a single feature: photo-sharing. We all know how this story turns out — Instagram was born.
This story highlights how easy it can be to build complexity into your product before it’s really necessary but it also shows how real-world usage can shatter all preconceived expectations about your value proposition. Kevin Systrom’s advises entrepreneurs and product managers to keep it simple.7
Although all of these examples resulted in minimum viable product validation, many more examples exist where the MVP was proven unsuccessful and the company moved on to a new strategy.
This is also a perfect chance to touch on a common misconception around minimum viable products: are they for companies at every stage?
A common scenario is that the MVP is created during the early days of the business but as the brand evolves, the company decides their product should be shipped perfectly – all the time.
This is a mistake.
We are not advocating you start offering your customers air mattresses, but when new products (or even features) are being developed, you should approach problem solving with the MVP mentality.
Release a very basic version of the product or feature to a select group of existing users to test. Once you receive feedback from them, you can refine and iterate before releasing the first official version to the public.
In short, MVPs are for startups, MVP methodologies are for everyone.
How can we ensure the MVP development encompasses only the necessary functionality to address the problem? Let’s apply what we’ve learned about building minimum viable products themselves to a process for creating them.
President Dwight D. Eisenhower had a framework for decision making that has become known as — you guessed it — The Eisenhower Matrix.
Using the Eisenhower Matrix for building your MVP can be a great way to prioritize features and make sure nothing important is overlooked. The axes compare the importance and urgency of each feature.
The most important and urgent features to be built are the core problem-solving functionalities. The important, although less urgent, features should be considered for future implementations. Features of less importance, although urgent, should be fulfilled by a third-party’s product when possible. And finally, the less important, less urgent features should be eliminated to prevent feature creep.
As you can see, the framework for minimum viable products should be minimal itself. Each and every MVP created will uncover new and exciting discoveries about products and the customers they serve.
If you want even more insight into users during your MVP testing, consider using a all-in-one customer engagement platform like CleverTap for customer segmentation insights, daily and monthly active usage data, and more. Check out our resources and Talk to Us to see how intelligent the CleverTap platform really is.
See how today’s top brands use CleverTap to drive long-term growth and retention
