Instructors Cole Mercer and Evan Kimbrell show how nail down your business hypothesis and define the minimum criteria for success. They introduce the tools and techniques you need to build email-based MVPs, shadow buttons, "coming soon" messaging, piecemeal MVPs that use existing tools, and even concierge MVPs, where you solve the customer's problem without coding anything. They also show how to evaluate the results of your testing and iterate on the design—building better products as you go.
Skill Level Beginner
- Hey guys welcome back to the course and welcome to the new section. We're going to talk in this section about MVPs. First off we're going to talk about MVPs, what they mean in definition and how the lean startup framework wants us to think about them. Then when we're done talking about the theory we'll talk about how do MVPs get used in actuality by product managers. Now MVP if you don't know this, stands for minimum viable product. The term is originally coined in a book called The Lean Startup Framework written by Eric Ries and for the most part it's extremely popular.
Startups nowadays often follow this religiously. And even big companies have taken a lot of the core concepts and integrated it into their work flow. Alright, let's look the actual definition of MVP as the book as says it. Pull it up on the screen, you guys can read it. (jeopardy music) Alright and we're back. That was ridiculous and I'm sorry for how long that definition is.
I don't know why it's so bloated. MVP just means the smallest amount of a proposed product that you can build, push out there and then get real feedback from users about whether or not they are actually interested in it. MVPs are primarily designed to test hypotheses and test assumptions that you have. Now if you want to be more accurate you would call an MVP an MVP experiment because actually an MVP is a process not necessarily a thing.
And that process is very much like science experiment. You'll start with things like assumptions, hypothesis, a minimum criteria for success and then you'll go about testing your hypothesis in a very scientific, measured way. MVP experiments rely heavily on a concept called validated learning. And they draw the distinction between learning and validated learning. Validated learning is anything you learn from a customer that's done in a test environment. And a way that you know for a fact you're not biasing you're customer and studying them in an environment where they have no undue pressure and they act naturally.
Learning on the other hand is just pretty much anything else you do that's not designed like an experiment. Not done well and you can't trust the results you get from it. Think of MVPs in the metaphor of walking in a park and you're on a path and you reach a fork in the road except the fork is three different ways you can go and you don't know where to go. Why are you doing this? Why do people hike in general? Probably 'cause they love trees. Now in this metaphor you have to pick which path to go down and I'll give you a little bit more information.
Right at that intersection there's a town. And this town has people and these people presumably know which path is the right one to take. So how do you decide? Well, most people would say someone in the town but actually with an MVP experiment you don't want to ask the townspeople, why because even if they swear that they know which path it is, we don't know for 100% certainty that they have any idea what they're talking about. Can you really trust those towns people with their quaint way of life? No you can't because it's entirely subjective and qualitative.
So the only way to actually tell for sure is to walk down each individual path until you can see enough of the path to know if it's the right direction. With an MVP experiment it is the art of walking down those paths, putting in the minimum amount of effort to get to the point where you can say, oh wrong path. If you were going to build a website that sold shoes online and you weren't sure if people wanted to buy your shoes online what would you do? Would you go all in, build out a fancy website.
Hire some people to program it. Buy some inventory, this is the equivalent of just sprinting down one path. Or would you try to do the absolute minimum just to figure out first whether or not this is the right path. And whether or not people want to buy your shoes online. That's actually a classic example of the MVP. If you guys are familiar with Zappos, the way that they started was exactly what I'm talking about. They wanted to know if people would buy shoes online and this is back in the day when buying shoes online was kind of crazy. So what they did is they made a very basic website.
They didn't buy any inventory whatsoever. They walked across the street to a shoe store. Took photos of the shoes and then when people bought them they physically walked over, bought the shoes and then shipped them. Once that had happened enough they knew this is the right path. They knew that this was validated. Now a common misconception with MVPs is that an MVP is some sort of prototype. And when I say MVP it means, you know, a really basic version of what you're trying to build. And that's just not the case. MVPs are about idea validation at the end of the day. And what it takes to get to that point, well, that's your MVP.
In most situations you can actually get away with not building much of anything. Just anything you can use to figure out whether or not people are interested in what you're about to build. The other core reason we make MVPs is that we use them as a way to mitigate risk. If you had the option of building a big fancy platform that created forms or just using a google form or a basic platform to validate your idea before hand, why wouldn't you go with the faster, cheaper, easier option? By picking that simpler version, by walking only part way down the path we save an enormous amount of resources.
Time resources, money resources, and things like opportunity cost. Last thing I'll say about MVPs and the actual lean framework is that there's a very strong focus on speed. And that's where the mantra of fail fast comes from. If you can fail fast and build your MVP experiments. Run them quickly, then you can run more MVP experiments in the same amount of time and collect exponentially more data which means that you're more likely to find a product or find a feature that fits, works, and is successful.
Alright guys, maybe that sounds familiar to you. Maybe it doesn't, that is the academic way of explaining MVPs. In the next lecture we're going to talk more about the relationship between product managers and MVPs. MVPs are different depending on who you are as a product manager and what company you are working for. Alright, see you guys in the next lecture.