How to plan an MVP

My name is Michael. I work here at Y Combinator. I help run the accelerator. Before that, did two YC startups, one in 02/2007 and one in 02/2012. And today, I'm gonna talk to you about, 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.

When you think about an MVP, 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 ten 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, if you are building a product for a mysterious set of users that you have no idea who they are, question that slightly, very slightly. Okay. So the goal of a prelaunch startup, 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 ten years, and it continues to be great advice.

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 gonna be resummarized 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. It's very, very common. So please get past this 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 extremely common mistake, because most founders in their heads have a 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's going take three years, ten 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. So I have this saying, hold the problem you're solving tightly, hold the customer tightly, hold the solution you're building loosely. And last, most important, iterate. And 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, if your screwdriver doesn't help the mechanic solve their problem, keep the mechanic, keep the problem, I need to screw something in. Fix the fucking 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 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.

It doesn't 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. Here is a classic example. This is one of Airbnb's first landing pages, in 02/2008, I believe. One of the things that you might be interested in about in 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 fucking 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. 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. 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.

Twitch launched as Justin TV, which was a 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. 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 slash payments, because why not? Like, let's make a name that's really easy to remember. This was Stripe day one. No bank deals. I won't tell you exactly how they process payments, but it was in a very startup y 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? 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. 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, you know, maybe it becomes a thing.

If you're in an industry with significant regulation, like insurance or banking, sometimes drones, although sometimes not, it's hard to launch. It's it's harder to launch. You have to pass through a bunch of regulatory bodies first. If you're doing hard tech, if you are building rockets, it is hard to build a rocket in a couple weeks. Biotech, it is hard to invent a cancer drug in a couple 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 weeks. So if you're in that situation, please remember that your MVP can start with a simple, simple website that explains what you do. It's helpful when you talk to people, when you 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, anyways, maybe your m 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. They see big companies launch stuff, and they assume that's what startups do.

In fact, they see companies they kind of think about like startups. Facebook's not really a startup anymore, but they see them getting a lot of press and getting a lot of buzz and yada yada yada, 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? 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 wanna 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 friggin' idea whether it's gonna 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 a 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 fuck 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, and because you never wrote it down, you don't even really realize you're changing it.

So your three week plan turns into a three month plan. If you write shit 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 going to 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 Once you 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 what it ended up being. So please don't fall in love with your MVP. 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. Alright. It was great talking to all of you. Thank you very much.