Hey PMs
I was first introduced to the term MVP way back in 2009 when Eric Reis was a guest speaker at my MBA class. Since then term had stuck with me and have used it well as I moved into a startup and later into product management.
Eric is largely considered the founder of the term MVP. He had employed these techniques in his startup in the early 2000s. Many startups started applying the term in their quest to build the right product.
What is MVP?
MVP stands for Minimum Viable Product. Everyone knows that.
What is less known is the original intent and how it should be used. The original intent of MVP during the early Lean startups movement was a bit narrow. Up until then, product development was costly. You would build something only to find out later that there was no customer demand or the solution was not usable.
So Eric and a few others proposed that we should first test our idea with our target prospects or users before proceeding to build the product.
MVP then had an experimental hint to it. If the hypothesis of the experiment is true, you then proceed with building your product….and your startup. Or you pivot.
For an excellent example, read about Zappos MVP.
In essence, the late Tony Hsieh the founder of Zappos had a hypothesis that people will buy shoes online. It was a behavior change back in 1997 and he was not sure if that hypothesis is true. Selling shoes online at least back then was not easy. You had to have a great eCommerce site, SEO, payment, fulfilment, logistics, supply chain and so on. All of these are super important. But what if no one buys online. All that investment would been a waste. This is exactly what happened with Webvan in the late 90s. Webvan assumed people want to buy groceries online. Very few did.
Tony on the other hand wanted to test the hypothesis. So he created a web site and posted photos of shoes, which he took with his camera at stores like Macy’s. If someone ordered, he would buy the shoe in the store and ship it.
This is an example of creating a low cost experiment to test the hypothesis. Remember, he was only testing if people will buy shoes online. He was not testing pricing, fulfillment, shipping, returns etc. All that would come later.
This was an MVP.
Dropbox founder Drew Houston wanted to test if there is demand for his new file sharing software. So he created a fake product video and posted on a landing page. Once he got enough sign ups, he had evidence that people want file sharing. Again, an MVP.
There are many other methods to experiment. In the book, The Right It, Alberto Savoia talks about a speech to text product by IBM many years ago. In order to test if they should build this product, they created a fake experiment and asked users to speak into a mic. The computer would then spew out the text. Except, in the experiment, someone was typing as the user was speaking in another room. Deceiving, yes. But cheaper than building the full product. Turns out, while the tech was cool, no one wanted to use it. It could not be used for confidential documents. IBM scrapped the idea then.
“The goal of an MVP is to test fundamental business hypotheses (or leap-of-faith assumptions) and to help entrepreneurs begin the learning process as quickly as possible.”
– Eric Ries, The Lean Startup
The letter P in MVP is a cause of confusion. Some people think it is the first version of the product. Some say it’s a product you build for people to try. That’s not exactly true.
It can be a landing page, or a fake experiment. And maybe in some cases you do want a low cost product e.g. an AI recommender system.
MVP as the name implies is the bare minimum functionality or service needed for the sole purposes of validating the idea. For example, if you are testing an idea for a software application, then considerations like high security, performance, or integration with other applications may not be relevant (in most cases), let alone documentation or marketing collateral. Not that they are not important, in fact they will be critical in the final product. But they may not necessarily be relevant for validation purposes. In fact, if you are embarrassed by the MVP, then you are in the ball park (Credit : Quote from Reid Hoffman).
Customers will not be happy with just the MVP. The problem is that after building the MVP, the product is not built upon and languishes while the team moves on to the next MVP. Now you have a bunch of MVPs but not a set of products that your customers love. An MVP hangover.
Version 1.0 on the other hand is a full product albeit with an initial scope. Version 1.0 is likely going to an existing market who already have a need or to existing customers. Building the supporting needs for a total product will be important – including performance, security, release management, marketing, support, documentation, support readiness etc. Ever for version 1.0.
We tend to now use the word MVP to get something started, whereas realistically we should be saying that is Version 1.0. That would also set the tone that there would be subsequent versions in order to build a complete product.
It is important to know the distinction of MVP vs Version 1.0.
Products that have an unknown outcome should go through the MVP process. If you are building something that you know your customers want and will use, then the term MVP is not correct. That would be version 1.0.
In fact, there is a new term R.A.T which we use in our coaching at UC Berkeley. It’s called the Riskiest Assumption Test. At any given moment, you have multiple risks for your product or startup and one of them is the riskiest. You test that risk before proceeding to next steps of the build.
For example, the biggest risk initially is does anyone have a need for your product. So you test the demand using a set of low cost experiments. The next risk is - will the product work. And so on.
If you want more details on the types of risks, check out this article here.
Is MVP just for startups? Not necessarily.
If you are an established company and trying to venture a new solution or a new market, you may have to go through the MVP process. A startup should definitely go through this process and tests their assumptions. It will save a lot of heartburn.
Bottom line, MVP implies that we need to first validate the product or service with the market prior to further investment.
I like the RAT idea.
It's more or less how I plan my biggest initiatives. If the initiative is risky, I split the work up into actionable chunks and start with the riskiest. Can we get from here to there and solve X? If so, we can go to Y (the next riskiest point), then to Z, then...
I've never formulated it in such an elegant acronym, but this framework has helped me loads. Too easy to get bogged down on details early on instead of focusing on the stuff that will truly make or break your project (or start up).