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.