How to Build An MVP | Startup School

[Music] All right, uh today I'd like to talk to you about how to build an MVP or a minimum viable product. So if you haven't seen this before, this is a meme that we love to talk about when trying to help founders with their MVP. It's called the midwit meme. The person who is the Jedi, these super intelligent, the founder who's doing all the best things and knows all the best things, and the idiot, the first-time founder, the founder who has no idea what's going on.

Many times these two Founders will actually come to the right decision before the founder who is really smart and is trying to work really hard and do everything right. And so, in this situation with the MVP, the best advice is to actually launch something quickly and iterate. Get a product into the hands of your customers and then learn whether it helps them or doesn't, and then iterate it, improve it over time. The wrong answer is to do 100 surveys and 600 user interviews and contact every single one of the competitors and spend, you know, a year fundraising, and hire 100 people, and, you know, all these other things that you can distract yourself with that might appear like other smart things.

But in reality, they really don't highlight the most important point about an MVP, which is you'd only really start learning about your user when you put a product in front of it. That doesn't mean that the thing you build in MVP is going to work right; it's probably not going to work. It's just the best way to start the conversation with the user and how you can solve their problems.

So, to summarize that point, the goal that you should have as an early-stage founder is you should be getting a product out into the world quickly—minimum viable product. Second, you should be talking to some initial customers and trying to figure out what you can do to make that product useful for them. You should care about how to help them accomplish their goals and you should try to figure out how can I change and iterate my product so that it actually helps them accomplish those goals.

And then rinse and repeat: talk to more users, iterate your product, talk to more users, iterate your product. More often than not, after three, four, five, six iterations, your MVP is going to be very different. You have learned so much, but by having that conversation with users and by letting them see your product evolve, you can actually make them more excited, more likely to use your product, more likely to pay for your product, and you can learn 10 times more than just talking to your co-founders or thinking about it in your head.

So the challenge today is that a lot of people are knocking MVPs. A lot of people are talking about minimum lovable products or minimum useful products and honestly, a lot of founders actually just want to build, you know, God-level products—you know, the Steve Jobs level, make the iPhone and change the world. There's this misconception that starting with something small that might not work very well is a bad idea.

There are a lot of people who worry that if you start with something small and you give it to a customer and the customer doesn't like the product, you'll never be able to talk to them again. What I will tell you is this: in most cases, the people who are interested in talking to a startup are early adopters. They're used to using products that don't work very well. And the reason why they're talking to you is not because they think your product's going to work great; it's because they have a real problem and they're open to using new software.

So you don't have to worry about losing these people. These are the kind of people who try new products all the time. These are the kinds of people, if you tell them, "Hey look, I can't promise it's going to work perfectly from day one, but if you keep working with me, we'll make it better and make it better and I'll make sure it works for you over time," these are the kinds of people who respond to that pitch.

It turns out the people who will run away after seeing your product break and never use you again, they're never going to try your product in the first place. They're not early adopters; they don't use new software. So you don't have to worry about losing those people because you never had them. You're not going to get them to get started.

Now, one of the things we have to work on at YC a lot is fear, and this is the biggest fear that founders have. It's a non-specific fear of, "Oh my God, if I give people my product and they don't like it, boom, my company dies." And it's always like hilarious because when we think about this, it's like, "Well, your company doesn't actually die, right?" Like it doesn't die tomorrow. It's not like game over. You haven't run out of money; all your co-founders are gonna quit.

Whenever we encounter these fierce scenarios, we like to dig in and kind of ask, like, "Well, what would actually happen?" Like, imagine the worst case scenario: you do talk to a customer, you do demo your product, it doesn't work, they don't want to use it; you wake up the next day, is anything that different? Can't you reach out to someone else? Can't you reach back out to that customer who you demoed to a week later when you've made the product better? Is your startup actually dead?

More often than not, when you have this fear, what you should be doing is kind of leaning into it and asking yourself, "Is this fear real? Is my company actually going to die if this scary thing happens?" And it's not bad to feel the fear, but it is bad to act on it. It is bad to spend one year building your MVP because you're afraid the first customer might not like it.

Now, there's another group of folks who think, "I know what the perfect product is and I know it's going to take a year to build; why would I build shitty versions of it?" I like to call these folks fake Steve Jobs, and it's really a massive misconception of what great product people do. A lot of people thought of Steve Jobs as the kind of person who could just imagine great products in his mind and then bring them out into the world.

But what's funny is that most of the time when people think about the products that Steve Jobs is most known for—let's say the iPod and let's say the iPhone—people don't take enough time to look at all of the different iterations of those products over time. Often when someone tells me, "Like, oh well, you know, Steve Jobs released an amazing phone the first time," I say, "Well, do you remember that the iPhone started without an app store? Do you remember you couldn't take video with the first iPhone? Do you remember the first iPhone only had 2G and not 3G, so it had really, really, really bad internet?"

Like, most people don't remember that. Most people, the iPhone that they actually think of as an iPhone was like the third or fourth iteration of the iPhone. The first version of the iPod had like an actual physical scrolling device where like, the Sam would get stuck into it and it would break all the time. Even the great Steve Jobs iterated his products over time.

So, if you find yourself being a fake Steve Jobs, thinking, "I know exactly what the customer needs; I just need to raise 10 million dollars and spend a year building it, and then launch it," think again, right? Like, if Steve Jobs needed multiple tries to get his products right, maybe you need to as well.

Next, let's look at some examples, and in all these examples, you're going to see three pretty simple points. First, all of these products were fast to build; they could get out of the market quickly. Second, they all had very limited functionality. The third, and interestingly enough, all these products appealed to a small set of users.

These founders realized that just making something that is small for people's love was far more important than making something that could address all the needs of all potential customers from day one. So here's what the first version of Airbnb looked like, and if you were a user when Airbnb first launched, here are some of the fun things that you didn't get to experience.

There were no payments. If you found a place on Airbnb, you couldn't pay for it there; you had to arrange for payment some other way. There was no map view, so there was no way for you to actually see where the places were in the city—that's a pretty basic one. Three, even more funny, you had to stay on an air bed; like, you couldn't rent out your whole house; you couldn't rent out a room in your house.

Then fourth, the first version of Airbnb only worked for conferences. They would literally spin it up in a city when there was a conference; when the conference was over, they'd spin it down. That was Airbnb to start; that was the MVP.

Here's a second example—this one's my company, Twitch. Twitch started as a site named Justin TV where my co-founder Justin had a camera on his head that broadcast 24/7. In the first version of Twitch, there was only one page—the page that you're seeing here. There was only one streamer; his name is Justin. There were no video games except for like we randomly would play video games sometimes, like, Guitar Hero or something like that.

And streaming was ridiculously expensive. We were paying a CDN; we hadn't built our video system yet, but this was the first version of our product. Now when you go to Twitch, it's completely different, but this is where it started. Finally, we have Stripe; this was the first version of Stripe. Back then, it didn't even have the name Stripe; it was called Slash Depth Payments.

Back then, they had no fancy bank deal; they were working with a tiny bank. There was literally no direct APIs with that bank for setting up accounts, so they'd have to call the bank and every night file manual paperwork for you to get your account set up. And there were almost no features in their API.

The first version of Stripe was so basic that even us back in the day at Twitch couldn't use it because it didn't have enough features. But the folks who could use it were early-stage YC startups who all they wanted to do was accept simple credit card payments from their customers. That's all Stripe did in the beginning, and that was more than enough to get started.

So you might ask yourself, who are these people who actually want to use crappy MVPs? You're telling us that they're going to be built fast; they're going to probably not work that well, and we're gonna have to iterate the hell out of them in order to actually make them good. Who are these early adopters who'd want to go through that experience?

There's this fun analogy that I was told as an early-stage founder: you want to build your first version for customers who have their hair on fire. And I never quite understood what that meant. I mean, like, it makes sense, I guess, but I always find it more useful when I attached a story to it.

So, imagine that you are a person and your hair is on fire right now as you're watching this. Now imagine if I was sitting in the room next to you, what is the thing that you wish I could sell you to solve this problem? Your hair is currently on fire; probably most of you will think some version of a bucket of water, hose, some kind of water thing.

Now that is a great product; that's like the iPhone today; that would solve your problem immediately. I don't have that; I'm a founder; I've got an MVP. What I'm selling is a brick. Now, what would you do if I was selling you a brick?

Now, some of you are like, "Well, I would, you know, I would leave the room; I couldn't use a brick." Your hair's on fire; you would buy that brick and you would hit yourself on the head with the brick to smother the fire. That's an MVP! It's not the perfect solution, but you are in so much pain as a customer, you will use a non-perfect solution to solve your problem.

That's the customer you should be going after: for customers who are not desperate, you can wait. You don't have to go after them now; just go after the desperate ones first. Don't make your life a lot easier.

Now, I know some of you, especially those who've gone to business school, I know a lot of you have said, "I can skip this step; instead of building an MVP, iterating, iterating, why don't I just survey my users? Why don't I just talk to 100 users and they'll tell me what to build?" I wish this was the case. I wish that users could just tell you what to build and then if you built those things, you'd win. In fact, I think every business wished that was the case.

Here's the problem: your customers are experts in their problem, but they actually don't have all of the answers at how to solve their problem; that's your job. That's the job of the person who's building a new product. Surveys might help you understand the pain that your customer is going through, but they will never help you figure out how to solve that pain.

The only time that you start having that conversation with the customer is when you can put a product in front of them, preferably a crappy MVP, and start saying, "Does this solve your problem?" I haven't really seen a shortcut to this step. I haven't seen a shortcut of building something pretty fast that's pretty crappy to get started, and even for larger companies, even for enterprise software companies, if you go back in time, the first versions of their product, they were not perfect; they were far from it. They were the minimum that those customers were willing to use.

So across the entire board, you gotta start with the minimum viable product. I think one of the most important points that I want to leave you with is that you don't start your startup with all the answers. Building a startup, especially the first phase of building a startup, pre-product market fit, is all about learning. It's all about taking some of the insights that you start with, bringing them to the market, and learning.

Most of the solutions, most of the best parts of products we use today were discovered after those products were launched, when those founders were learning from their users. Building and launching MVPs is the fastest way to start the process of learning, and the faster you learn, the more likely you are to build something that people love before anyone else.

So, let's say I've convinced you that now you actually want to build an MVP. How do you make sure you do it quickly? Here are some tricks: One, give yourself a very specific deadline. It's a lot easier to make sure that you're building something that's the minimum viable product if you give yourself two weeks or a month or a month and a half to complete it versus if you don't give yourself a deadline.

Second, write down your specs. If you think that there are five or ten features required in order to launch an MVP, write them all down. Don't put yourself in the position where you are constantly trying to figure out, "Should we have that feature? Should we not have that feature? I don't remember the feature we talked about the other day; how should it look? How should it work?" If you write it down, then you can just focus on building instead of continuously debating what should be built.

Number three, cut that back. After you write all that stuff down, go through each one of those items and ask yourself, "Does a truly desperate customer need that feature to start?" You're probably surprised at how many features you can leave off for the second, third, or fourth version of your product and just get the basic stuff out first.

And then number four, and most important, don't fall in love with your MVP. It's gonna change; you're going to iterate it; it's going to get very, very, very different over time. You want to do it fast and you don't want to fall in love with it; you want to fall in love with your customer, with your user, not in love with the crappy initial product that you're building to start learning from that user.

All right, so hopefully you don't need any more convincing. You understand that the simplest and easiest path, and the smartest and most Jedi path, is to build and launch your product and then iterate it. And so, I wish you all a lot of good luck, and while you're building, remember one thing: it's far better to have a hundred people love your product than a hundred thousand who kind of like it.

So when you're releasing that MVP, it's totally okay to do things that don't scale and recruit those initial customers one at a time. If you care about those customers, I promise you they will talk to you, that you can work with them, and you can help them figure out how to solve their problems and, as a result, help figure out how to build a great product for them. Thank you very much and good luck. foreign [Music]