MVP is an abbreviation of Minimal Viable Product, a simple yet powerful concept that quickly validates if you are moving in the right direction in terms of making a product that people love.
Only three letters that have a very important meaning to successful entrepreneurs. MVP is the simplest version of a product that will be created and made available to users to validate an idea and collect essential data to validate the direction of the business.
This concept emerged in Silicon Valley, a region that is home to many startups and technology companies and gained momentum after the publication of The Lean Startup book by author Eric Ries.
Think big, start small, learn fast. Tweet This
Think big, start small, learn fast – this is the minimum viable product proposition. So, in other words, MVP represents a new way to create and evolve products, delivering only the minimum feasible, to validate the idea with users as quickly as possible and improve the product with the feedback received.
By delivering the minimum viable, it is possible to bring the product to market faster, minimize the expense of time and resources, and evolve the product based on the actual feedback from its users.
The MVP concept has been responsible to the success story of thousands of entrepreneurs who have launched great products and great businesses. Some successful examples are Apple with the iPhone, Facebook, Spotify, Airbnb, Easy Taxi, and many other companies that started small, with their creators working that way, and won the world over time.
But, how do you decide the MVP?
How to find the balance between the minimum and the product?
Where and how did the concept of MVP come about?
How MVP works
And what does it mean to validate the MVP?
Check out some MVP examples
When to Pivot?
Most common errors when building an MVP
MVP Canvas: an essential tool
Important points when filling up the MVP Canvas
Validate the business assumptions
Build, measure, learn
MVP and key metrics
Is your MVP plan ready?
The minimum viable product is the way that agile teams and startups create, validate and evolve their products and businesses. MVP is the first step to delight users and customers with the ideal product to suit their needs, albeit in a simpler version.
Although the final product, after all the evolutions and increments, is something much more complex. But launching this minimum product to the market will be essential to know if the path is correct or if it is necessary to change (pivot) the direction.
The minimum viable product is the way that agile teams and startups create, validate and evolve their products and businesses. Tweet This.
But it’s important to note: to offer the minimum viable, you have to put many features aside for later. So, the first step is to understand and prioritize what constitutes this minimum viable product without compromising the quality of what will be delivered to the user.
You can (and should) dream of a successful super-product, full of features, but you must be realistic. As long as it doesn’t exist, it’s all just a business hypothesis, and MVP is the fastest way to validate that hypothesis and the value proposition of your idea.
This is almost like playing with a seesaw, as it is necessary to find the ideal balance, without weighing either side.
The simpler the MVP, that is, the smaller it is, the smaller the product. On the other hand, the bigger the product, that is, the more features it has, the more time and effort it demands, probably creating beyond the minimum viable to validate something.
It is difficult to define the MVP. As in a child’s game, the seesaw will swing from side to side. Sometimes the MVP goes a bit beyond what is necessary; other times, the MVP will be slightly below the minimum acceptable. But this seesaw
has two sides, and if one is missing, it won’t be an MVP.
Imagine doing experiments without a product. You find a way to validate (or un-validate) a business model even before building an MVP. This is excellent! You are validating something, fast.
However, if there is no product, the term should not have the P for product. This is an experiment. An MV, a viable minimum to validate something. You are still not in the seesaw. When you come to this game, then you must add the P for Product.
Now imagine the MVP when there is no minimum. For whatever reason, a big list of requirements and features is created for the product. A list that is not minimalistic, with several things to build. Again, this is not an MVP, but a complete product. Someone has made a plan to build a product and they are not following the MVP way.
But what is the minimum viable? How to align and plan the creation of MVP? By following the Lean Inception workshop agenda, through its step-by-step and finalising with the MVP Canvas, you will be able to align, understand, and create the minimum viable product.
It is essential to know how to balance the MVP seesaw and then invest in the creation and evolution of a product or service.
The concept of MVP is originally linked to ideas popularised by the Toyota production system, the origin of Lean manufacturing. Steve Blank, a serial Silicon Valley entrepreneur, created a methodology based on customer development.
This was the beginning of the Lean Startup movement, which peaked with Eric Ries and the launch of his book. But even before the work became popular, the term was in use for several years before the movement’s rise, especially among Silicon Valley startups, entrepreneurs, and investors.
For example, the expression minimum viable product first appeared in 2000 in an article by Willian Junk entitled, in free translation, The Dynamic Balance Between Cost, Schedule, Resources, and Quality in Software Development Projects.
If you work with MVP, it means that you are open to validating hypotheses, failing, and learning quickly. Tweet This.
In this context, less is more, which means you don’t waste time, money and effort creating the wrong product.
You validate your idea, your assumptions, your hypothesis. You work with the MVP to build a successful path.
The final product can contemplate more than one commercial objective, serve several types of users and have many features. But an MVP must validate one hypothesis, test one idea and verify that it meets what is expected by a few customers in the simplest way possible.
M is for minimal, so the MVP should cover only a small aspect of the business for a specific segment of users, with only one or a few features.
For example, the image below depicts the creation of a product made through MVP. Each small box is a validated MVP through user feedback, business interest, and technical possibilities.
The product starts out simple, then it will grow and have more features (represented in the image by the stacked boxes). This happens from validated MVP to validated MVP. That is, each additional feature must pass the validation: Do not add anything that has not been validated to the product.
Validating is the act of proving that something really works effectively. The validation of an idea or a hypothesis through an MVP consists of providing evidence that the MVP usage data corroborates the hypothesis, demonstrating that it is worth pursuing the evolution of the product, the business, from the initial idea.
The product is built gradually, with validated features added to the existing consolidated product. Working with MVP, the continuous and incremental delivery provides greater product value over time, whereas the traditional build process does not provide any value until the end, when the entire project is ready.
We can create a metaphor to illustrate the example: an MVP to cross a river. A simple solution to crossing a small river is to place a wooden beam connecting the banks. And that’s a great example of MVP! In addition to allowing the crossing, it is a simple way to validate the site for the construction of the bridge. Place some wooden beams in different places in the small river and then check which one is the most used for the crossing.
MVP promotes an incremental approach where only a small part of the general assumptions is addressed at the same time. Each of the hypotheses is designed, created and prepared to be added to the product, to generate useful data for decision making, learning and validation.
In essence, a great idea (or a big business hypothesis) is sequenced into a series of smaller, simpler, and therefore easier to understand and carry out validations.
As a result, the simplest solution to validate the hypothesis are build faster and made available to the end user in the product. For example: If you add a simple bridge at this location, how many pedestrians would use it per week?
In this case, the end user (or whoever validates the MVP) provides data to validate the product increment. Early validation is essential for two reasons: 1. Corrections and changes can be made early in the project, rather than appearing only when it is more elaborate, thus reducing product risk, and 2. The amount and the complexity of the data to be analyzed is small.
Product creators and the end user have early access to something functional and usable. Therefore, decisions about next steps and product increments are based on the product itself, rather than being hypotheses about other hypotheses. And this work pattern allows the construction of very elaborate products, with small, but well founded steps.
You may not know it, but you probably use some digital product that are famous MVP examples, such as iPhone, Facebook, Easy Taxi, Dropbox, and Zappos.
And it is very important to know these stories because, when explaining what MVP is to people who are not in the areas of entrepreneurship or technology, it is much easier when you have an example of this size up your sleeve. Plus, you can and should be inspired by these great businesses that started with simple MVP.
MVP example: iPhone
MVP example for startups
With Facebook it was the same! What started as a simple website, which only served for a few university colleagues to share their photos, has grown to become the social network used by millions of people around the world.
I am happy to share a nice startup story about a successful Brazilian business: EasyTaxi. Before creating the application, the startup validated the hypothesis that there was a demand to call a taxi via a website.
The founders of EasyTaxi did this through a very simple web form where the person entered the information to order the taxi, and then the founders, after receiving an email with the form contents, would call a taxi cooperative on the person’s behalf. Little by little, the business turned into an incredible success story.
MVP example for service
As you already know, the main objective of an MVP is to avoid the risk of building products or services that nobody wants.
I work with digital products, so the vast majority of MVPs that I implemented, or helped teams and companies implement (through Lean Inception), were MVPs for digital products. But I also get a lot of feedback from Lean Inception book readers on minimum viable for services.
One example that I found fascinating was the use of MVP as an assessment service for the decontamination of large industries. This idea came from a fiscal agent responsible for the inspection, evaluation and decontamination plan of large industries. The agent was the wife of a person in digital products who had bought my book. She read it and began to apply the MVP concept in her area of expertise.
Before reading the book and understanding the minimum viable product concept, the agent evaluated the large industry and presented a decontamination plan. Something like: “in up to a year, the company must meet all the points below or it will be fined 100,000 USD per month”:
- Add filters in the XPTO standard on the two hundred machines that dump liquid waste into the river;
- Add another hundred vents;
- Send all employees to trainings on environmental stewardship of groundwater and rivers.
Using the concept that we are exploring here, and that is an essential section of my book, the agent created an MVP plan, the minimum viable, to validate whether the industry was going to make a move towards reducing pollution.
Something like: “You must implement the following actions within two months, otherwise you will receive a progressive fine, starting with 10,000 USD per month (increasing 10,000 per month to the value of 100,000 USD per month)”:
- Add standard XPTO filters to five of the two hundred machines that dump liquid waste into the river;
- Add five more vents;
- Send 5% of employees to trainings on environmental care of groundwater and rivers.
The result: For most companies, problems were resolved faster and fines were lower. For a few companies, the fine of USD 100,000 began to arrive earlier and other bodies and agents began to act more quickly, since this company was already on the list of those that did not respond any longer to certain changes.
More MVP Success Stories (Dropbox and Zappos)
And since there is no shortage of examples, I will present two more to further familiarize you with the advantages of working with MVP. Take a look at Dropbox and Zappos.
The founders of Dropbox were software engineers who were dealing with the challenge of integrating a variety of computing platforms and operating systems, such as Windows, Macintosh, Linux, etc. With my experience as a developer, I can say that in the 2000s this was not an easy task. Although today it is simpler, at that time cloud computing was just beginning.
But, if the hypothesis were to be validated, it would be one of Dropbox’s biggest competitive advantages: their product would work flawlessly on each and every platform!
In addition to product development efforts, the founders needed feedback from potential users, they needed to know if they would use and pay for such a product. They believed in the idea and knew it was innovative, but it was necessary to confirm to investors that this challenge would really be useful for users who did not understand the “behind the scenes” of platforms and applications.
So, the Dropbox founders needed to validate their basic premise. If Dropbox could deliver an amazing user experience, would people give the product a try? Would they pay for it? The founders were able to validate that the answer to these questions: Yes, users were willing to pay for it.
They found that file syncing was a problem that most people didn’t know they had. And after trying the solution, you can’t imagine how you ever lived without it… it is imperative to have the same file saved and available on any device, on any operating system and platform.
But the most surprising thing is that they demonstrated it long before the product was in use. They had a video demonstrating how Dropbox worked. A simple three-minute video that was created and posted on Digg, a platform known at the time for its technological content.
As soon as the content was published, the list of subscribers to receive the product in its beta version (the Early Adopters version, before the official launch) exploded: they went from 5,000 to 75,000 overnight.
This level of interest validated the hypothesis that the Dropbox founders needed to be sure before proceeding with a full rollout. People were very interested in their incredible product idea and, equally important, this validation attracted the interest of Silicon Valley investors.
Zappos is another excellent example from Silicon Valley, and I remember that story from the years I lived there.
The name Zappos, comes from shoes in Spanish, zapatos. The Zappos founder had an idea and wanted to test it out before spending time and money (or rather, before asking for an amount of venture capital).
He really liked sneakers and used to buy some nice ones through catalogs since he couldn’t find all of them in the nearby shoe store. Then he got the idea: “What if I create an online shoe sales website?” – remember this was in 1999.
So, he created zappos.com, a very simple website, with just a few photos of shoes with description and a simple payment method (by credit card). But it started without a shoe inventory or more elaborate e-commerce solution on site.
He was taking pictures of sneakers in a shoe store near his apartment. Then he uploaded it to the website (same price as the store). Once there was a sale, he would buy it and send it to the customer. Simple like that!
And with this minimal but viable product, many users started buying sneakers online and validated that it was an incredible idea. The company attracted venture capitalists and top talent and, a few years after its launch of MVP, it was sold for a very good sum to Amazon.com.
Do not spend time, money and resources building the wrong solution, the wrong product. MVP provides you learning, insights about your market and your users. As soon as you realise you’re going the wrong way, as soon as you realize your hypotheses aren’t confirmed, it’s time to pivot.
Pivot is not about giving up. Pivot is to adjust the direction of your product. According to the author of Lean StartUp, Eric Ries, to pivot is to change the strategy without changing the vision. Eric Ries shares that you can pivot your business in 10 different ways:
- Zoom-in pivot: A single feature of your product becomes the whole product.
- Zoom-out pivot: Your current product becomes a single feature of a bigger product.
- Customer segment pivot: Your product is repositioned towards a different type of customer.
- Customer need pivot: Your product is adjusted based on a greater understanding of or new revelations about your customer’s needs.
- Platform pivot: Your product is delivered on a different platform.
- Business architecture pivot: You adjust your product and your business from high-margin, low-volume to low-margin, high-volume. Or the other way around.
- Value capture pivot: Your product changes how to charge your customers.
- Engine growth pivot: Your growth strategy changes in order to achieve faster or more profitable growth.
- Channel pivot: You change how and where you sell your product.
- Technology pivot: You change the technology that your product is built upon.
And since an MVP alone does not guarantee success, it is important to avoid mistakes that are very common when creating it.
Error 1: one-sided thinking
The most common mistake when creating an MVP is thinking one-sided. For example: think only about the technological challenge, or only what would delight the user, or only what validates your business.
These three perspectives are essential to creating the MVP: technology (feasible), user experience (usable), and business (valuable).
MVP stands at the intersection between the valuable, the usable and the feasible, representing, respectively, the interest of the business, the acceptance (and admiration) of the users and what is possible to build. Tweet This.
- Valuable: Entrepreneurs think about the commercial value of a product. Typically, these people have a business vision and think of MVPs as an incremental step-by-step to product creation. In this context, entrepreneurs influence the MVP so that, even if it is minimal, it already achieves the expected return on investment (or, at least, shows that it is going in a good direction for the business).
- Usable: Each and every one of the features must be designed according to the needs, desires and dreams of the users. Something Usable is based on an explicit understanding of people, their tasks, and the environments in which they live.
- Feasible: The proposed solution to serve the business and users only makes sense if it is feasible, if there is technology and knowledge to build it. There is no point in defining an MVP if you don’t know how to build it.
Error 2: looking for the perfect MVP
Another mistake when using MVP is trying to create something perfect. But don’t forget that MVP is not perfect!
Perfect, from Latin, means “done to the end.” And MVP is not the complete product, it is not finished, with all its possible features. It is the minimum, the minimum viable that the user can use. The feasible to provide business information on the direction of your product.
MVP is not perfect, but it is the minimum viable to generate business insights on the direction of your product. Tweet This.
MVP is done. Done is far better than perfect, especially in the context of a culture of innovation, uncertainty, and rapid learning. Check out the iPhone and Easy Taxi examples, which started out as incomplete products, far from perfect.
Error 3: MVP without the “Wow” factor
MVP isn’t perfect, but it should be awesome. It must have the “Wow” factor. This characteristic is what differentiates your product in the market, what conquers your users and transforms them into avid product promoters. Which literally makes people say “wow!”
Think of the iPhone when it first came out. It had the “wow” factor. Its users said: “WOW! Full screen, touch screen… look how cool! ”. Think of the first people who called for a taxi through a website. They said, “WOW, just put my address, click and the cab’s is in the way!”
The “wow” factor is important to a successful product, and for an MVP, it is even more important! Let’s go back to the example of the iPhone 1, the iPhone MVP. It had no third-party apps (the app platform wasn’t even ready), no GPS integration, and the calls were worse than on competing devices.
But the iPhone 1 had the “wow” factor. People used it and gave their opinion. Its early adopters, the first people using it, were the main promoters of the product. People lined up for the launch of the iPhone 2, iPhone 3, etc. This is due to the “wow” factor, which turns users into promoters, increasing expectations and desire for the next release.
Each MVP should have these four factors: feasible, valuable, usable and wow.
The image above reiterates the importance of these four factors. MVP is a small portion of the product that contains each of these factors. Don’t think of it as a product layer (the figure on the left); for example, don’t work on what’s feasible first, then work out another factor, then another, and finally look for the “wow” factor.
Create the MVP as shown in the figure to the right, a small slice of the big picture, which looks at all four factors.
- MVP Proposal – What’s the Proposal for this MVP?
- Segmented Personas – Who is this MVP for? Can we segment and test this MVP in a smaller group?
- Journeys – What journeys are going to be improved with this MVP?
- Features – What are we building in this MVP? Which actions are going to be simplified or improved in this MVP?
- Expected result – What learning or result we are seeking in this MVP?
- Metrics to validate the business hypotheses – How can we measure the results of this MVP?
- Cost & Schedule – What is the expected cost and due date of this MVP? When can we look at the data for validating it? Is there any schedule constraint?
Focus on the proposal
The more focused the MVP is, the better. You must validate the need for a segment of people and a business hypothesis, and these are generally related. Be clear about your MVP proposal. Ask yourself until you have a clear answer: What is the purpose of this MVP?
Minimize risks with segmented personas
Who is this MVP for? Can we segment and test this MVP in a smaller group?
In answering these questions, you should think about releasing the MVP while minimizing its risks. For example, you might decide that an MVP will be restricted to a small group of people and that the same set of features will only be released to a larger group after verifying the expected result. For example, validate the hypothesis in only one neighborhood before opening it to all neighborhoods in a city.
Improve the user journey experience
What user journeys will be fulfilled or improved with this MVP?
The user journey maps the experience you provide to your users. The answer to this question clearly demonstrates what your MVP offers to the user.
When completing the Canvas MVP, the conversation about user journeys should be very focused. At this point, only the journeys of targeted people who shall use the MVP are evaluated.
If you have difficulty describing even a user journey, please reevaluate; maybe your MVP does not contemplate anything for any person (less than the minimum). If you write too many user journeys, re-evaluate too; maybe your MVP is too broad (remember that the “M” for MVP is minimum, not maximum). An MVP should not fulfill every user journey. They will be taken care of as the product evolves.
Decide the MVP features
You need to compile the list of features for the MVP. Once you have an initial list, ask the following questions about features:
- Are they really the bare minimum?
- Will they make the product viable?
- Could we create something even simpler?
- Did we forget to include something essential for MVP?
You must promote a good conversation. Make any necessary adjustments and changes. At the end, re-read the feature block and check if the following questions are answered: What are we going to build in this MVP? What actions will be simplified or improved in this MVP?
You should know how to measure results and validate the product idea: Don’t build a feature for an MVP if you don’t know how to describe what you expect as a result and how to measure the feature usage.
Try to understand your users. To do this, plan to collect MVP usage data that will help you verify the desired outcome and the desired learning.
After defining the MVP features, try to connect it with the expected results and business assumptions. The following template helps with such a statement:
We believe that (this MVP)
Will achieve (expected result).
We know that this happened based on (metrics to validate the business hypotheses). Tweet This.
The above model is an adaptation of Jeff Gothelf’s model for hypothesis-driven development. You should complete it, because if you can’t complete it, you won’t know what to expect from the MVP or you won’t know how to measure it. And in either of these two scenarios, the product will be adrift, without direction.
Learning is also an MVP outcome, an expected result. However, to learn, you must at least declare that “the expected result is learning.” So say out loud to everyone interested in the MVP: “We want to understand better, learn more about the business and the users. For that, we will collect data that will help us to verify if we are achieving the desired learning”.
On 1991, James March shared an article with his findings on the relation between the exploration of new possibilities and the exploitation of old certainties in organisational learning. His main point is that an organisation should do both consecutively: explore new possibilities while exploiting the existing ones.
Twenty years later, on 2011, Eric Ries released the Lean Start book which says that:
An organisation should keep learning and experimenting via a build-measure-learn cycle
Since the release of the Lean StartUp book, I’ve been applying the build-measure-learn cycle on many contexts and organisations. I noticed a variance on the build-measure-learn cycle depending on the organisational interest for a given initiative: exploration or exploitation. The image below shows the build-measure-learn cycle for the Exploration and the Exploitation organisational learning perspectives.
On the Exploration cycle, you should run many experiments. The more experiments, the better. It is all about exploring as many options as possible.
As per the paper, “Compared to the returns from exploitation, returns from exploration are systematically less certain, more remote in time, and organisationally more distant form the locus of action and adaption.” … “The essence of Exploration is experimentation with new alternatives. Its returns are uncertain, distant, and often negative. Thus, the distante in time and space between the locus of learning and the locus for the realisation of returns is generally greater in case of of exploration, than in case of exploitation, as is the uncertainty.”
On the Exploitation cycle, it is less about experimenting and more about validating. The idea is already proved, the data already shows some positive for moving forward. You already know the best options. Now its time to exercise them, to exploit it!
But you still need to build something small. Something for validating your exploitation results. This is the MVP. And, for deciding and aligning the MVP you should run a lean Inception workshop.
Measuring the MVP usage is a crucial task for you product and business evolution. It helps you understand how it is being used, validate your assumptions, and make data-driven decisions. Below you find some key metrics for measuring and analyzing an MVP usage.
But prior to choosing the relevant metrics for the MVP, it is important that you have filled out the following blocks of your MVP Canvas: The MVP proposal, expected results, segmented personas and journeys. These blocks will help you formulate the questions to be answered by the key metrics. A few examples: Are you trying to validate if new users discover and adopt your product, to validate if a change drives conversions, or to compare a few solutions to increase the gross margin?
For example, if your MVP proposal is to validate if new users discover and adopt your product, you may want to track metrics such as Number of new users, Traffic sources (e.g. organic, referral, paid) and CAC (client acquisition cost).
Effectively working with MVP implies you are tracking and analyzing key metrics – on the MVP Canvas this information is on the Metrics to validate the business hypotheses block. These key metrics enable you measure results, learn, and make data-driven decisions. They provide you’re the insights (learn) needed to keep moving on the build, measure, learn cycle.
It’s important to remember that validating, measuring, and analyzing the MVP usage is an ongoing process. As you learn new insights and validate you initial hypothesis, you will decide the next increment, the next thing to be validated, you’ll formulate the next questions to be answered by metrics, and then choose the next set of key metrics.
Below, I share the most common key metrics I have seen being used in many MVP canvases. I´ll try to categorize by type.
To be added … I am currently looking at many MVP canvases from many Lean Inception I have facilitated.
To answer that question, I recommend that you refer to this MVP checklist that is available at Caroli.org. Answer the questions to assess whether you are ready to launch your MVP, and from there, start validating the success of your business!
Also, on Caroli.org there is an amazing training and plenty of other content on the subject, be sure to check it out to further increase your knowledge and chances of creating and evolving a successful product!
- 3 Differences Between Design Sprint and Lean Inception You Need To Know
- Connecting the dots – Vision, OKR, Scrum, Lean Inception, Outcome and output
- Which tools did I use on the remote Lean Inception?
Did you like this content?
- See more details about the next Lean Inception Training classes
- Know more about the book Lean Inception: How to Align People and Build the Right Product