<ul><li class="ql-align-justify">Talk to your users before you came up with MVP</li><li class="ql-align-justify">Build MVP with limited functionality. You need to condense down what your user needs, what your initial user needs, to very simple needs </li><li class="ql-align-justify">Don't take too much time to build MVP try to build MVP within three weeks.</li><li class="ql-align-justify">Don't fall in love with your MVP don't think it should be perfect and spent a lot of time.Treat it as one of the steps to be completed </li><li class="ql-align-justify">Ask feedback from real customers and iterate it.</li><li class="ql-align-justify">Always be more flexible to change your solution according to your customer's needs and try to be in contact with your customer.</li></ul>

Minimum Viable Product

YC CEO and Partner Michael Seibel shares his approach to building an MVP and getting your first users as a pre-launch startup.

startup

Startups

YC CEO and Partner Michael Seibel shares his approach to building an MVP and getting your first users as a pre-launch startup.

<ul><li>you haven't built an MVP yet </li><li>you're trying to figure out which features to put in your MVP </li><li>you're building an MVP but don't have anyone using it yet </li><li>your MVP is taking longer than expected to launch </li> </ul>

Read more on product development cycle fundamentals on Michael's blog: <a href="http://www.michaelseibel.com/blog/product-development-cycle-fundamentals">http://www.michaelseibel.com/blog/product-development-cycle-fundamentals </a>

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?

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.

How to Plan an MVP: Getting Started, Building Product

Minimum Viable Product

Related collections

Other curated ideas on this topic: