One of the most powerful and misunderstood agility-related concepts is the Minimum Viable Product or MVP. Some people think of it as the least we have to do or as a club to use in negotiations. Others think of it as a first releasable product. Others that deal in certainty avoid the MVP entirely, favoring to simply build the “ultimate” customer solutions straightaway.
People just don’t get the MVP!
I think I will rebrand the MVP as Many Varied Perspectives!
Let’s explore some of those perspectives of the minimum viable product. Let’s also look back to 2001 to understand who coined the term and why.
Eric Ries Made Minimum Viable Product a Household Term
Eric Ries gets a lot of credit for the minimum viable product though frankly, it was Frank Robinson that coined the term in 2001. According to Robinson, the term minimum viable product went viral immediately:
“When I first said ‘minimum viable product’ I never had to repeat myself. The words went viral right before my eyes.”
Eric Ries and his mentor Steve Blank did popularize the MVP and it was Eric that included it in his 2011 best-selling book, the Lean Startup.
In his book, Ries describes the Minimum Viable Product like this:
- A minimum viable product helps entrepreneurs start the process of learning as quickly as possible
- It is not necessarily the smallest product imaginable
- The goal is to test the fundamental business hypothesis
Separately, Ries said: A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
— Eric Ries
The going-in assumption for the MVP is that at the outset, we don’t know for sure what the customer needs. Those that believe with certainty that they know what the customer needs run the risk of building the wrong thing as we will explore later.
There is a reason why people don’t carry around an Apple Newton today and it is because the product did not meet customer needs. On the other hand, Apple estimates that there are over 1 billion iPhones in use today around the world. The first version of the iPhone was certainly a Minimum Viable Product and did not contain features that many would have deemed critical like copy and paste.
So the MVP is a way to invest the least amount of effort and money to get the most return. That return could come in the form of validated assumptions, demand for the product or feature feedback.
The MVP can help the development team in a number of ways:
- It validates or invalidates assumptions.
- It focuses the team on those features or aspects of the product deemed most important to the customer.
- It speeds overall development of the solution.
- It provides an opportunity to change course if needed – to “pivot” in a new direction before too much effort or money are invested.
The MVP is not a Fully Featured Product
To be clear – the Minimum Viable Product is not a fully featured product. It is not production ready. It may not have most of the critical features and some could even use smoke and mirrors to produce an MVP.
Ries describes a few different MVP approaches that are little more than smoke and mirrors. In the concierge approach, the “product” is completely manual with a person doing all the steps.
The Wizard of Oz approach described by Ries is similar:
The wizard of oz MVP gives the user a faithful representation of what the fully fledged product would act like, and you can gauge their reaction. You save a ton of product development time by using the very adaptable human.
— Eric Ries, The Lean Startup
In both of these approaches, the “product” in the MVP is not really a product; it is a view of what the product would look like. And that is sufficient for the developers to use to get that valuable customer feedback.
And that is where it breaks down for many people and the proverbial wheels come off the sedan.
Kniberg Prefers ETUL over Minimum Viable Product (MVP)
Readers of this blog know that I am a big fan of Henrik Kniberg. He is the coach I said I wanted to be when I grew up.
Kniberg is the one who posted the somewhat famous diagram of the MVP going from skateboard to the convertible. You’ve seen it. It has been posted, reposted, and shared over and over again.
It is also widely misunderstood. So much so that Kniberg wrote this article trying to explain it. If you have not read that article, it is probably worth pausing here and going to read it. I’ll wait.
Let’s assume Kniberg knows what he is talking about (he usually does) and dig a little deeper. Let’s start with Kniberg’s post explaining the skateboard to convertible and then explore some alternative views of the MVP.
In the not like this line, each step represents an output that is not very usable to the customer. Sure it is about not building in phases with interim work products like a single wheel. But it also about going into any development effort with some humility about what we know about the true customer need. We all make assumptions about those needs and what Knieberg (and Ries) say is that we need to test those assumptions because they might be wrong. And that is the true value of the Minimum Viable Product.
MVP has become so loaded that Kniberg uses a different term for this way of working in his blog. He says he likes the term “Early Testable / Usable / Lovable” over Minimum Viable Product. ETUL certainly doesn’t roll off the tongue like MVP and it is probably less clear what he meant without some explanation.
What he meant, is a version of the product that could be tested. Specifically, “the team delivers the smallest thing they can think of that will get the customer testing things and giving us feedback.”
“The team delivers the smallest thing they can think of that will get the customer testing things and giving us feedback.”
— Henrik Kniberg, https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
Others might define the MVP differently. But I really like this definition. And I think that Eric Ries would like it as well.
Some IT Groups Use the Minimum Viable Product Like a Club
One client I worked with years ago had a bad experience with the MVP. The internal IT team was building solutions for the business customers they served and they kept arguing about what was the minimum viable product.
Unlike the approach above where the MVP was used as an exploratory tool or experiment, the MVP in this case was used as part of the fixed contract that IT used to deliver the solution. The thinking is reminiscent of traditional change control processes. The IT team was trying to lock in a minimal set of features so that they could deliver those in a fixed budget and fixed timeline “contract”.
The IT team in this case wasn’t trying to learn more about the true customer need, they were trying to protect against change in the future. And they wanted to lock in a minimal solution so that they could deliver it within the fixed constraints.
In this example, both sides were trying to “win” in an adversarial, win/lose environment. The business wanted to avoid agreeing to the “MVP” as it was defined, and the IT team wanted to use the MVP to lock down the scope. And if they couldn’t “win”, both sides were comfortable as long as they could point the finger for failure at the other side.
In this case, the MVP was being used by the IT team as a club to force the business customers to accept the bare minimum. The IT team would select a subset of all the things the customer said they needed and call that the MVP. They bargained and negotiated to deliver a barebones solution that barely met (or didn’t meet) the customer’s need. They called it the minimum viable product because neither side knew better. And that led to near-certain dissatisfaction.
Most Project Managers Don’t Get MVP
To many Project Management enthusiasts, the MVP represents throw-away work. And they tell me, predictably when we cover the MVP in my training classes.
They look at the diagram from Henrik Kniberg and they say, why waste time building a skateboard and bicycle if the client needs a sedan? Just get busy and build the frickin sedan. It would be wasteful to build anything BUT the sedan. And so they miss the point that we don’t know for sure that the sedan is what the customer actually needs.
The reason they miss the point is that project managers deal in certainty. Projects are about certainty – we certainly know what we want. After all, we wrote down the customer requirements and the plan to achieve them and we got both signed off in blood.
That plan is a certain way to deliver the solution. And the solution is certainly what the customer said they needed. The project manager then fights to prevent changes to the plan. And they “win” when they can say that they delivered On Time, On Budget, and On Scope. Just stick to the plan!
What a wonderful place to live – in certainty!
The customer said they need a sedan, so they must certainly need one. Let’s get cracking on building it and not bother the customer until we are done and we can provide them with the finished sedan.
That is the fast and efficient way to build something. You save time if you don’t have to stop occasionally to show the customer what you are building. Just wait till the end and deliver the friggin sedan. Look, our customer is smiling!
Unless of course, the customer didn’t know what they needed. Or the need changed while you were off building the sedan. In that case, you will be fast at building the wrong thing. Efficient but not effective.
Certainty Should be a Warning Sign!
Certainty should be a warning sign. A big red flashing one.
I can’t believe I am saying this but customers increasingly don’t know what they want or need. And they have trouble describing what they need with any certainty. Or, they describe a solution rather than the underlying need without recognizing that there might be more creative, innovative or effective solutions to address that underlying need.
A saying that illustrates the point that Henry Ford apparently never said is “If I had asked people what they wanted, they would have said faster horses.” Similarly, I am pretty sure that Steve Jobs didn’t have anyone tell him that they wanted to carry their entire album collection around in their pockets. Nor did any customer ever tell Jobs that they needed a device to text people, take pictures of themselves, rant about their president, navigate in a strange city, track their heart rate and bing watch movies.
Consider a customer that says, “we need to implement Salesforce.com“. And if you ask why (many don’t), the customer might say something like “so that our salespeople are more effective and we are able to grow our sales revenue“.
Do you see the implied assumptions there? That salespeople could be more effective? That increased sales effectiveness could grow sales revenue? Or the biggest leap of faith, “if we implement salesforce.com we will grow our sales revenue”.
Many PMs won’t bother to ask for the why and just dive in with “we need to implement Salesforce.com”. And they provide you the plan to do it, complete with timelines and budgets. That is how they are measured – on time and on budget implementation of the project. After all, no one will ever circle back to check that the project actually resulted in sales revenue growth. Benefits realization management is something you can read about in a book but it is only being practiced effectively by fewer than one in three organizations.
You can think of the MVP as a risk reduction technique. If you are truly certain you know what the customer needs, including what outcomes they are hoping to achieve and how the solution will provide those outcomes, then sure, go off and build that solution. But most of us don’t have that sort of certainty.
I would say, the more certain you are as a project manager, the more nervous you should be.
Others Just Don’t Want to Bother the Customer
Others seem to feel that it is embarrassing or inefficient to show the customers solutions that are not final. A few years ago I had a client who was developing accounting solutions for external customers. We were training and coaching the product managers. One in particular was the product owner for a team developing a particular accounting solution for taxes.
When the concept of the MVP was described to her, she kept insisting that her customers didn’t want to see and could not use a skateboard solution. They can only use the final version, so why would we waste their time showing them an MVP?
Why indeed?
Google Used an MVP Approach for Google Home
MVPs are not just for startups or small companies. Back in 2016, I noticed something odd. It was February and Google was advertising for Google Home. I stumbled on this page about the Google Home which as you can see had very few details.
Later in November, I found this other page about Google Home. What is different? Why even bother posting the first one which had no real details?
No one at Google told me this, but, the first posting in February of 2016 was Google’s version of the skateboard. It cost them almost nothing yet it allowed them to test the market. They didn’t have a product yet – it was in development.
With that one simple and low-cost page, they could:
- See how many people visited
- How many people entered their email to show interest
- How many people who offered their email would respond to a questionnaire (e.g. Which of these features is most important in a home automation hub?)
- Get people to sign up for beta testing
- Potentially freeze out sales for competing products from Apple and Amazon
- and more
But wait you say, Google has a GABILLION dollars! Why would they bother with an MVP when they could just build the final product? If they were certain they knew what they needed, why not just get busy and build it as quickly as possible?
Ah, there you go with that certainty thing again.
Google was able to gather a lot of information about product needs before they even had a product. And it cost them nearly nothing – just the cost of putting up a single webpage. That is a super fast and inexpensive way to gather information on the business need.
But there could be even less expensive MVP approaches as Nordstrom shows us.
Nordstrom Used a Piece of Paper for the MVP
Not to be outdone by Google, the Nordstrom Innovation Lab demonstrated that the MVP could be even faster and less expensive than a flat webpage. In this great video about the flash development of an iPad tool for sunglass selection, the team uses paper prototypes of the solution to test out the idea with customers. The paper prototypes are even faster and lower cost than the Google approach.
Bottom Line – Use the MVP Approach
Hopefully, this post provided you some additional food for thought about the MVP. Perhaps this article itself is an MVP for a book on the topic? Let me know if that is a good idea in the comments below :).