Michael Seibel - How to Plan an MVP

My name is Michael. Uh, I work here at Y Combinator. I helped run the accelerator. Uh, before that, I did two YC startups—one in 2007 and one in 2012.

Today, I'm going to talk to you about a minimum viable product, so MVP. We always yell at founders to not use jargon, yet we have this whole set of stupid startup jargon, and MVP is one of them. Um, when you think about an MVP, you should think about something ridiculously simple. This is the first thing you can give to the very first set of users you want to target in order to see if you can deliver any value at all to them. That's all it is. It's extremely simple.

I know you guys had a talk last week about how to come up with ideas, how to come up with problems you want to solve. What I will tell you is that it is helpful to talk to some users before you decide to build your MVP. This doesn't mean you have to go into a three-year kind of research situation or you have to work in industry for 10 years, but some conversations are helpful. It's even more helpful if you're your own user, so you can tell whether your product's working for you.

I always get this strange question of how do I get my first users, which always kind of confuses me, because theoretically, you decide to solve a problem that you know someone has. So the way you get your first user is you talk to that person that you know has the problem, and if it's you, it's even easier. So, um, if you are building a product for a mysterious set of users that you have no idea who they are, question that slightly, um, very slightly.

Okay, so the goal of a pre-launch startup, um, is extremely simple. Step one: launch quickly. This is something that's been part of the YC ethos from the very beginning, and it's been great advice for 10 years, and it continues to be great advice. Um, if you can walk away from one thing from this presentation, it's launch something bad quickly. That's it. Like literally, the rest of what I'm going to say is basically going to be re-summarized versions of that same thing.

The second thing that an early-stage startup needs to do is get some initial customers. Get anyone using your product. You don't have to have a vision of how you get everyone using it, but just anyone interacting and seeing if they can get value out of the product. You'd be surprised at how many founders' journeys end before a single user has actually interacted with a product they've created. Um, it's very, very common, so please get past the step—it's extremely important.

The next one is talk to your users, any of them, after you've launched this MVP and get feedback. This is one that's also an extremely common mistake because most founders in their heads have an idea of what they want to build, and so they kind of have this weird feeling that if I haven't built the full thing yet, getting feedback on the shitty initial thing is kind of useless. Of course, it's not going to work; it's not the full thing. The full thing is going to take three years, 10 million dollars, a whole team.

So feedback on the little thing is useless. The reality is that, in some ways, the full thing is this really awesome idea in your head that you should keep in your head, but it should be very, very flexible, because it might turn out the full thing that you want to build isn't what your customers want at all.

Um, I have the saying: hold the problem you're solving tightly, hold the customer tightly, hold the solution you're building loosely. And last, most importantly, iterate. I like to kind of distinguish between iterating and pivoting. A lot of founders, once they've figured out how to build something, fall in love with it, and so if it doesn't work for a certain set of users, they start thinking, "Well, I wonder what other problems this thing can solve." Well, you know, the screwdriver is not actually good at screwing in anything, but I wonder what other problems it could solve.

And they're like, "Oh, maybe you can use it to cook; maybe you can use it to clean." And it's like, no, like the problem was I need to screw something in. The user was like a mechanic, and if your screwdriver doesn't help the mechanic solve the problem, keep the mechanic, keep the problem, "I need to screw something in. Fix the screwdriver." Like that's the thing that's broken, right? The broken thing is not the mechanic, and it's not the fact that they need to screw something in.

So iterate, continue improving on your solution until it actually solves a problem. In most cases, most people should be building a very lean MVP. So by that, we mean, um, you should be able to build it fast—in weeks, not months. This can either involve software, or honestly, we see startups just start with a landing page and a spreadsheet, but most startups can start very, very fast.

Second, extremely limited functionality. You need to condense down what your user needs, what your initial user needs, to a very simple set of things. A lot of times, founders want to address all of their users' problems and all of their potential users when in reality they should just focus on a small set of initial users and their highest order problems and then ignore the rest until later.

You should have a vision of everyone. You should have an MVP—very small. All this is is a base to iterate from. That's it. It's just a starting point. Um, it's not special in any way; you just have to start, and so please make sure you don't feel like your MVP is too special.

Okay, uh, here is a classic example. Uh, this is one of Airbnb's first landing pages, uh, in 2008, I believe. One of the things that you might be interested in about Airbnb's first product is that there were no payments. When you found a place to stay on Airbnb, you had to exchange money with the host in person.

Needless to say, that was a pretty big problem, but they started without payments. No map view— you know how when you search Airbnb, you can see where the house is in the city? You don't have that; sorry. Um, and the person writing all the code, Nate, was working part-time.

Okay, so everyone tells these kind of magical stories about how everything was perfect from the beginning—Airbnb? Not perfect from the beginning. Uh, the next one, Twitch. This was what Twitch looked like day one—not very familiar? Well, maybe a little familiar. There's some video there, and there's some chat there. Other than that, nothing else. Uh, Twitch launched as Justin TV, which was an online reality TV show.

There was only one channel, Justin. You had to follow his life; if you didn't like his life, you had to leave the website. That's all there was. The video was extremely low resolution. It was funny—a founder asked me back in the day like, "Oh, like wasn't it weird you guys had video in your apartment? Weren't there all these, like, secret documents and things that, like, people would be able to see?" And it was like, you could barely recognize our faces, let alone documents that we had.

Um, and most importantly, there were no video games—no video games, except if we decided to play video games in our apartment. Like that was the only time video games ever appeared. And so let me just say, you can do that quickly. When you think about Twitch, it's much more complex now.

Last, Stripe—which wasn't Stripe; it was called Slash Dev Payments, because why not? Like, let's make a name that's really easy to remember. Um, this was Stripe day one. No bank deals. I won't tell you exactly how they processed payments, but, uh, it was in a very startupy way—almost no features. And even cooler, if you wanted to use Stripe, the Stripe founders would come to your office and integrate it for you. How nice is that?

Um, half because they were just desperate to get anyone to use it and half because it was a great way to find bugs before the users found bugs. Uh, integrate yourself. So these are just three examples of extremely simple, extremely fast to build MVPs. All of these are billion-dollar companies, and they all started with something that most people would say is pretty shitty.

In very few cases, you have to build a heavy MVP. I just invented that term "heavy MVP" when I made this presentation two days ago, so, uh, you know, maybe it becomes a thing. If you're in an industry with significant regulation—like insurance or banking—um, sometimes drones, although sometimes not, um, it's hard to launch. It's harder to launch. You have to pass through a bunch of regulatory bodies first.

If you're doing hard tech, if you're building rockets, it is hard to build a rocket in a couple of weeks. Biotech, it is hard to invent a cancer drug in a couple of weeks. Moonshots—well, fill in all the other blanks. It's hard to bore tunnels in the earth and have extremely fast vehicles that replace cars in a couple of weeks.

So if you're in that situation, um, please remember that your MVP can start with a simple, simple website that explains what you do. Um, it's helpful when you talk to people—interact with people—that they can refer back to something, so that can be your start. And you can build that simple website in days, not weeks. So many ways, maybe your heavy MVPs are faster than your lean MVPs in some weird, strange way.

Now I want to talk about launching for a second because a lot of founders have this misconception about launching. Um, they see big companies launch stuff, and they assume that's what startups do. In fact, they see companies—they kind of think about startups. Facebook's not really a startup anymore, but they see them getting a lot of press and getting a lot of buzz and yadda yadda, and they have in their head that that's what a successful company looks like when they launch.

Well, let me ask you this question: how many here remember the day that Google launched? No? How about Facebook? Um, okay, how about Twitter? No? Great! So it turns out that launches aren't that special at all! Okay? So if you have this magical idea of your magical launch, you want to do, throw it away. It's not that special.

The number one thing that's really important is to get some customers. So to make people feel better, let's use different terms. How about launch is when you get any customers, and how about like press launch? Press launch? Really impressive is when, like, people write about things, and it's all exciting, and you get all this buzz. Let's push the press launch off, and let's push the get any customers launch really, really soon. That's our goal here.

It's a lot harder to learn from your customers when they don't have a product they can play with. You know, you can talk to your customer all day, but you have no idea whether the thing you want to build can solve their problem. If you put the thing in front of them and it doesn't solve their problem, you know right away.

And so all the research in the world is good, but until you can put something in front of people, you have no freaking idea whether it's going to work. So spending all that time on a pitch deck is not as valuable as spending your time building anything that you can give to a customer.

Finally, some hacks for building an MVP extremely quickly. First, time box your spec. So your spec is the list of stuff you need to build before you launch. Time box it. Say, "Okay, what happens if I want to launch in three weeks?" Okay, well, the only things that could be on my spec are things I can build in three weeks. That makes your life a lot simpler. It allows you to remove all the features you can't build in three weeks.

Second, write your spec. This seems really straightforward, but most people mess this one up. It's really easy to change what you're working on before you ever launch it because you never write it down. You start working on something. You talk to a user; they say, "Oh, I would never use that," or, God forbid, you talk to an investor, and they say, "Oh, that could never be a company, because investors know everything."

And so you decide to change what you're working on. Because you never wrote it down, you don't even really realize you're changing it. And so your three-week plan turns into a three-month plan. If you write it down, at least you can be honest with yourself that you're changing your spec all the time.

The next one is cut your spec. A week into your kind of three-week sprint, you probably realize that you added too many things to your spec and you're not gonna make your deadline. That's okay. Just cut the stuff that clearly isn't important, and if there's no non-important things, start cutting important things. Most of the goal here is just to get anything out in the world. Once you get anything out in the world, the momentum to keep anything going is extremely strong.

Once you have any—if you don't have anything out in the world, it's very easy to just delay, delay, delay, delay. And then last, don't fall in love with your MVP. So many people fall in love with the vision in their head, and none of the products I showed you before was the initial vision of what it ended up being.

So please don't fall in love with your MVP. Um, it's just step one in a journey. You wouldn't fall in love with a paper you wrote in the first grade, and like that's like the level of impact often your MVP has.

All right, it was great talking to all of you. Thank you very much!