- The author discusses the importance of building a minimum viable product (MVP) and iterating based on customer feedback.
- They emphasize the need to launch something quickly and learn from customer interactions, rather than getting caught up in surveys and interviews.
- Early adopters are open to trying new products, even if they are not perfect, so there is no need to fear negative feedback.
- The author challenges the misconception that starting with something small is a bad idea and highlights the iterative process of successful products like the iPhone and iPod.
- Examples of successful MVPs include Airbnb, Twitch, and Stripe, which started with limited functionality but appealed to a small set of users.
- The author encourages founders to lean into their fears and question whether their company would actually die if their product doesn't work perfectly.
- They caution against the mindset of building a perfect product from the start and highlight the importance of iteration.

- Building an MVP (minimum viable product) is important for early adopters who have urgent needs
- Customers with urgent needs are willing to use a non-perfect solution to solve their problem
- Surveys may help understand customer pain, but they won't provide solutions
- Building and launching an MVP is the fastest way to start learning and improving
- Tricks for building an MVP quickly: set a specific deadline, write down the spec, cut unnecessary features, and don't become attached to the MVP
- It's better to have a small number of customers who love your product than a large number who only like it

Y Combinator Group Partner, Michael Seibel, explains how to build a minimum viable product (MVP) for your startup idea. Using examples from real YC companies, Michael walks through how to determine your MVP feature set, build prototypes and demos for user testing, and present your MVP to early customers or investors.

Apply to Y Combinator: https://yc.link/SUS-apply
Work at a startup: https://yc.link/SUS-jobs

Chapters (Powered by https://bit.ly/chapterme-yc) - 
00:00 - How to Build an Minimum Viable Product (MVP)?
01:50 - Pre-launch Startup Goals
04:26 - Founders Biggest Fear
07:17 - Examples - Software MVP
07:48 - Airbnb
08:36 - Twitch
09:15 - Stripe
10:36 - Solving Hair On Fire Problem
14:12 - Build an MVP Quickly
15:51 - Outro

All right, 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.

The person who is the Jedi, the 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 2 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 and improve it over time.

The wrong answer is to do a hundred surveys and 600 user interviews and contact every single 1 of the competitors and spend a year fundraising and hire 100 people, and all these other things that you can distract yourself with, that it 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 them.

That doesn't mean that the thing you build in your MVP is gonna work, right?

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?

Talk to more users, iterate your product, talk to more users, iterate your product.

More often than not, after 3456 iterations, your VP is going to be very different.

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 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.

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 kinds 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 gonna work perfectly from day 1, 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 gonna try your product in the first place.

So you don't have to worry about losing those people because you never had them.

You're not gonna get them to get started.

Now, 1 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?

All your co-founders aren't going to quit.

Whenever we encounter these fear scenarios, we like to dig in and kind of ask like, well, what would actually happen?

You do talk to a customer, you do demo your product, it doesn't work.

You wake up the next day, is anything that different?

Can't you reach back out to that customer you demoed to a week later when you've made the product better?

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 1 year building your MVP because you're afraid the first customer might not like it.

Now there's another group of folks who thinks I know what the perfect product is and I know it's going to take a year to build.

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 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 that the first iPhone only had 2G and not 3G?

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 sand 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 needs to raise 10 million dollars spend a year building it and then launch it Think again, right like if Steve Jobs needed multiple tries to get his products, right?

And in all these examples, you're going to see 3 pretty simple points.

First, all of these products were fast to build.

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 a small group of people loved was far more important than making something that could address all the needs of all potential customers from day 1.

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.

If you found a place on Airbnb, you couldn't pay for it there.

You had to arrange for payment some other way.

So there was no way for you to actually see where the places were in the city.

3, Even more funny, you had to stay on an airbed.

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 and when the conference was over, they'd spin it down.

Twitch started as a site named JustinTV, where my co-founder Justin had a camera on his head to broadcast 24-7.

In the first version of Twitch, there was only 1 page, the page that you're seeing here.

There's 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.

Back then it didn't even have the name Stripe.

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 are 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 gonna be built fast, they're gonna 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.

It was, 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, it makes sense, I guess, but I always found 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?

Probably most of you will think some version of a bucket of water, a hose, some kind of water thing.

That would solve your product immediately.

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 like I couldn't use a brick.

You would buy that brick and you would hit yourself on the head with the brick to smother the fire.

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.

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 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.

Your customers are experts in their problem, but they actually don't have all of the answers on how to solve their problem.

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 the minimum that those customers were willing to use.

So across the entire board, you gotta start with the minimum viable product.

I think 1 of the most important points that I wanna 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, bring 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.

And building and launching an MVP 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.

1, 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 2 weeks or a month or a month and a half to complete it versus if you don't give yourself a deadline.

If you think that there are 5 or 10 features required in order to launch an MVP, write them all down.

Don't put yourself in the position where you're constantly trying to figure out, should we have that feature?

I don't remember the feature we talked about the other day.

If you write it down, then you can just focus on building instead of continuously debating what should be built.

After you write all that stuff down, go through each 1 of those items and ask yourself, does a truly desperate customer need that feature to start.

You 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 4 and most important, Don't fall in love with your MVP.

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 1 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 1 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.


Speaker 0: All right, 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 midwhip meme. The person who is the Jedi, the 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 2 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 and improve it over time. The wrong answer is to do a hundred surveys and 600 user interviews and contact every single 1 of the competitors and spend a year fundraising and hire 100 people, and all these other things that you can distract yourself with, that it 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 them. That doesn't mean that the thing you build in your MVP is gonna work, right? It's probably not gonna 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 3456 iterations, your VP 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 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 kinds 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 gonna work perfectly from day 1, 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 gonna 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 gonna get them to get started.

Now, 1 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 aren't going to quit. Whenever we encounter these fear 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 wanna 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 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 1 year building your MVP because you're afraid the first customer might not like it.

Now there's another group of folks who thinks 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 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 that the first iPhone only had 2G and not 3G? So 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 sand 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 needs to raise 10 million dollars 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 3 pretty simple points. First, all of these products were fast to build. They 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 a small group of people loved was far more important than making something that could address all the needs of all potential customers from day 1. 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 1. 3, Even more funny, you had to stay on an airbed. 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 and 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 JustinTV, where my co-founder Justin had a camera on his head to broadcast 24-7.

In the first version of Twitch, there was only 1 page, the page that you're seeing here. There was only 1 streamer. His name was Justin. There's 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 debt slash payments. Back then they had no fancy bank deal. They're 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 are 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 gonna be built fast, they're gonna 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. It was, 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, it makes sense, I guess, but I always found 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, a hose, some kind of water thing. Now that is a great product. That's like the iPhone today. That would solve your product 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 like I couldn't use a brick. Bullshit 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. It'll 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 is 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 on 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 1 of the most important points that I wanna 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, bring 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. And building and launching an MVP 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's some tricks. 1, 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 2 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 spec. If you think that there are 5 or 10 features required in order to launch an MVP, write them all down. Don't put yourself in the position where you're 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 3, cut that spec. After you write all that stuff down, go through each 1 of those items and ask yourself, does a truly desperate customer need that feature to start.

You 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 4 and most important, Don't fall in love with your MVP. It's going to 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 1 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 1 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.

♪♪

See all Y Combinator transcripts on Youtube

How to Build An MVP | Startup School