How to Plan an MVP — Michael Seibel | YC 

YC   CEO  and Partner  Michael Seibel  shares his approach to building an  MVP  and getting your first users as a pre-launch  startup
Watch if: 
  • you haven't built an  MVP  yet 
  • you're trying to figure out which features to put in your  MVP
  • you're building an  MVP  but don't have anyone using it yet 
  • your  MVP  is taking longer than expected to launch 
 
Read more on  product  development cycle fundamentals on Michael's blog:  http://www.michaelseibel.com/blog/product-developm...
Transcript 
Michael: My name is Michael. I  work  here at  Y Combinator . I help run the accelerator. Before that, I did two  YC   startups , one in 2007 and one in 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 , you should think about something ridiculously simple. This is the first thing you can give to the very first set of users you wanna 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 users, 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 10 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 gonna say is basically gonna 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 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 wanna 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 gonna  work . It's not the full thing. The full thing is gonna take three years, $10 million, 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 wanna 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 and 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, this 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 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 the  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. 
The 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 wanna 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'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 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 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, 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 /dev/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-ey 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 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, 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 wanna 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 wanna 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 frigging 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 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 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. And 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 realized that you added too many things to your spec, and you were 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, 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. Okay. That's the talk. I have a little bit of  time  for questions. Any questions? Perfect. No questions. Oh, go ahead. 
Woman 1: I'm finding, talking to users, I have several subtype segments, and of course each one wants a particular thing, and another one wants a particular thing. So, the numbers are so small that they kind of even out. So how... 
Michael: Great  question . So, you talk to users and they have all these things that you want to build, and there isn't a lot of overlap between them. So, I will give you kind of the meta answer: Never ask users for features. Never ask users to tell you what they want. It's not the user's job to come up with features. That's your job. The user's job is to give you  problems . And so, I would assume that if you were talking to these users, there's some continuity in the  problems  that they have. They probably have no idea how to solve the  problem
And so they're probably giving you a long list of potential features they think can solve the  problem , as opposed to spending a lot of  time  just talking about what their  problem  is. How often do they experience it? How intense is it? Are they willing to pay for a solution? Do they know other people who have the  problem ? So, like, those are the questions I'd be trying to get out of someone. And if you see someone sneaking into feature zone, like, "Oh, you know, I love  Microsoft  Word, but I wish that, like, someone could build something that lets me do blah, blah, blah, blah, blah," right, that you've gotta scoot it back down to, "Oh, well, why do you wanna do blah, blah, blah, blah, blah? What  problem  do you have? How often do you encounter that problem?" And, like, get it back to the  problem . That's how you avoid feature death. It's extremely common. 
Woman 2: I find myself walking that very thin line between staying focused on my  MVP , but changing it up because I'm finding one thing better. So, I started off on my  MVP  talking to all my potential users, and I'm, "No, no, no, no. We gotta do this, we gotta do this, we gotta do this." So, like, do I take my ADD medication and just keep going with what I started with, or when do you stop and say, okay, this warrants a change? 
Michael: Oh yeah. Sorry. So the  question  is, I'm stuck in this cycle where I keep on changing my  MVP  and I don't launch. Obviously, a lot of people are stuck in that cycle, and there are a lot of  startup   problems  where the answer is, "stop doing what you're doing." Just stop it. Like, you don't have to keep on changing your  MVP . One of the reasons why perhaps you're changing your  MVP  is because you think it's special. If you didn't think it was special, you would stop changing it. You'd stop editing it. 
Woman 2: I don't understand. Explain that again. 
Michael: If you think your  MVP  is special, you think it has to be perfect. If you think it has to be perfect, you spend a lot of  time  messing with it. If you assume that it has to be really shitty, right? Like, if you think, like, "Okay, like, I'm literally trying to find a shirt in my closet that I can paint with and then destroy," you don't spend a lot of  time  tailoring that shirt, right? So, if you think your  MVP  is less special, you'll spend less  time  tinkering with it. 
Man 1: Say you launch an  MVP  and you're looking for  feedback , what are the key things you want to ask your users? 
Michael: This is a really simple  question . What's the key thing you wanna learn when you wanna get  feedback  on your  MVP ? Does it solve the  problem  I want it to solve? That's it. You can find 80 different ways of answering that  question , but if you clearly understand the  problem  you're trying to solve, then it's a pretty clear...oftentimes, you don't have to ask. If it's in front of the user, you can see whether they're, like, doing the thing you want them to do or, whether they're, like, not. Oftentimes, you can see it in the numbers. If it's a  problem  they have every day, and you introduced a user to it, did they come back the next day? I've never really seen a  product  that solves a  problem  people have every day, that actually solves the  problem , where a user just stops using it because, like, whatever. So, there are lots of, like, weird nuances here that are completely irrelevant. Does the user do the thing, solve the  problem  that you want them to solve? Other questions? In the back here? 
Man 2: How long should an  MVP  last? I mean, you start growing, and then what are the next steps? 
Michael: You know what's fun about  startups ? I don't like thinking about timelines, and I don't think linking about roadmaps. Like, for people who are in the pre-MVP stage, like, who knows? Launch something. Figure it out. You decided to do a  startup , and one of the characteristics of  startups  is that how to get from A to Z is not gonna be clear. And so, if you're too focused on like, "Oh, well I understand getting to  MVP  is step B, but I'm really focused on steps C, D and E," I would tell you, like, "Hey, how about solve the  problem  right in front of you first?" Yep? 
Man 3: So, how do you balance, for example, improving the  MVP  to grow the retention of customers, versus betting on efforts to grow acquisition and regeneration, in terms of  problems
Michael: Post-MVP, should you  work  on  growth , or should you  work  on retention? I love this  question . It's the funnest  question  in the world, because it allows me to give, like, a ridiculously canned answer. Both. Yeah. Here's what happens. A lot of founders kind of fundamentally understand the  startup  is a multi-variable  problem , but multi-variable  problems  are hard. So they try to reduce it to a single variable. So they ask the, like, secret advisor, like, "Oh, what's more important,  growth  or retention?" And it's like, what's more important, like, taking a shower or going to the bathroom and, like, do a number two? I'd like you to do both. Sorry. Both are important. As a founder, you're gonna have to juggle multiple things. Yeah. Okay. 
Man 4: Okay. Can you share a story with, like, a  startup  that couldn't talk to the end users because end users didn't want to talk about the  problem  and how they overcome that, if you know. 
Michael: Let's be clear. The  question  is, how do you talk to your users if they have a  problem  they don't wanna talk about? Why don't you tell me, is, what that is? 
Man 4: Type two diabetes. 
Michael: Type two diabetes. I am perfectly confident that you can find 10 people who wanna talk about their type two diabetes. And I  question  you starting a  startup  to help type two diabetes people if you don't know anyone who's got type two diabetes who's willing to talk to you. So I think that's, like, one of those false setups. Like, I reject the premise of the  question . All right, next  question . Go ahead. 
Woman 3: How many people would be enough to sign up, or how many active users would it be good to have in the  MVP  before presenting to investors, for example, based on which metric ... market size or? 
Michael: That's a great  question . If I were to summarize, I would say, how far along are you before you talk to investors? I'm also going to punt on that answer. I think there's gonna be a whole lecture on when you should talk to investors. And so, I will say, wait for that lecture, and whoever gives it will do a great job at answering that  question
Woman 5: My  question  is, what type of numbers or  traction  should you look for before your  product  is validated? 
Michael: I'll rephrase that  question . How do you know when you have  product-market fit ? Okay. The classic answer, which is actually correct, and founders really hate, is that if you're asking, you don't have  product-market fit . What tends to happen when you have  product-market fit  is that people start using your  product  so much, you transition from doing anything, other than just keeping it online. That's what  product-market fit  tends to look like. So, you stop thinking about new features. You stop thinking about improving your, like, conversion through funnels. You stop thinking about how to get better distribution. And you are literally just, like, "Holy shit, I don't know how I'm going to serve the people who are coming to my  product  tomorrow. I'm at a loss. And next week, I'm at a loss. And I'm pretty sure that we're gonna die, because we're have too many users." 
And what's funny is when I put it that way, it's not hard to know whether you're there or not. And the such a horrible reality is that almost no one gets  product-market fit . Almost no one. Almost no one. So, like, a lot of people like to throw around the term, and a lot of people like to redefine it as, like, "Someone's using my product." That's not the term. The term for someone's using your  product  is, "You have a user." Which is good, but it's not  product-market fit . In the back. 
Man 5: The more users we talk to, the definition of the  problem  keeps on getting bigger, bigger and bigger. So, when figuring out  MVP , where do you start? We started working with just one user, and we tried like just one small experiment with them, but we learned more attributes of the  problem  itself. 
Michael: So, what happens if you learn more about the  problem , and the  problem  expands as you start interacting with users? That's totally fine. That's expected, in fact. What I would say though, is that where founders usually make the mistake is they think they have to solve the  problem  for all users. And so, most importantly, if you have one user with a set of  problems , a nice thing to do would be to try to figure out, is there anyone else like them? And, like, one fun thing you could do is just ask them, "Hey, do you know anyone else who's got your exact same problem?" Any  problem , when you kind of scoot back and you think about the vision of any founder, it actually encompasses, like, a whole subset of  problems . And I think the thing that gets people really screwed up with their  MVP  is that they have a vision that's big, and they're not willing to have an  MVP  that's small. 
They feel as though if they're not addressing all of the potential users up front, then they're somehow failing. And, like, there are a lot of things that a  startup  has to do, a founder has to do, where they're keeping two things in mind at the same  time , right? Vision big,  MVP  small, right? Grow, and retain. One thing we talk about at  YC  a lot: your investor  pitch , and your customer  pitch , very different. And, right, founders always want to smush these things together or kill one, because it's so much easier to think of it as a single  problem , like, single thing in your head, versus two opposing things in your head. How could it be true that we want to do payments for everyone, and have a little  API  that's so hard to use that we have to install it for people, right? And it's like, both things are true, and you have to be comfortable with that. All right. One more. 
Man 6: In the pharmaceutical  space , will my users be scientists, or will they actually be patients? 
Michael: In the pharmaceutical  space , who are your users? I think that that's a  question  for you. You were starting the company, you know what you're building, you know a  problem  you're solving, you know who has the  problem . I don't know any of those things. All right. It was great talking to all of you. Thank you very much. 
 
Notes that link here:
Please sign up or log in to add comments and/or write your own notes and articles