Without any further delay, I will introduce to you Michael Seibel,
the CEO of Y Combinator, the founder of companies
like Justin TV and Twitch and socialcam.
To begin what is going to be a deep dive into
product over the next several lectures. Michael?
So before I begin,
I kind of had a conversation with Jeff and I wanted to say
a couple things about my experience at Justin TV and
Twitch. So what I will say is that we
broke many, if not all of the rules that
I'm about to tell you. At various points
during our company,
the things that allowed us to survive were
one, our founding team was extremely technical.
Justin, Emmett and Kyle all were
amazing to work with. And basically what I found amazing about
them is they were not intimidated by any technical challenge.
I think that I would not be standing here if I wasn't
privilege to work with them. And so I think this is something that
a lot of companies, a lot of startups, a lot of startup founders
don't truly understand. Like that fact allowed us
to break a lot of rules. The second is we didn't spend a lot of
money. We moved out when we were
21, 22, 22 and 23. We lived in
a two bedroom apartment.
That apartment cost $2,500 a month. We were each given
$500 a month walking around money, which technically
is against the law because it was below minimum wage,
but who cares about laws? And that
was it, that was the game. Emmett got his own bedroom.
Kyle and Justin slept in bunk beds. I slept in the living room
and sometimes on the balcony. We just didn't spend much
money. That gave us a lot of ability to screw up and
make mistakes. And then I'd say the last thing that was kind of interesting,
I only realized later is that our ego was highly
tied to our startup. We were
not doing a startup to have a cool resume item. It was really
the only thing we had done on our own. And so I think at
various points during the company when it looked like we would fail, basically our
startup failing was our life failing, right? It was like, well, this is the
only thing you've done so far and so if it fails, you get F on
life. And I think that we all
had that feeling very internally and therefore
we just couldn't really conceive of giving up. So I think more
than anything I'm going to say in the rest of this presentation, those were the
three things that saved our company, made our company work,
and strangely, I don't even think if you take one of those
things away, any one of them we would have died. So this isn't one of
those things where it's like, oh, you can grab for one or two, and that's
pretty good. We needed all three or else, game over.
So as I get into product, I'm going to tell stories
from Justin TV from really early
days at Twitch when I was still there, and then also from
a YC company from a couple batches ago named Poppy.
It's a company that I've advised since I've invested in DID yc great
founder named Avni. And weirdly,
I just feel like I needed to do a case study outside of my own
story. Somehow it's going to help share these lessons a little better.
So I always like to start with,
what problem are you solving? Because when I'm pitched by
founders, most often they just want to tell me what their idea is,
what they're going to do, what their product does. I think what's interesting is that
oftentimes they don't even know why.
They don't know what's the problem that they expect to be solved at the
end of what they're doing. Now, I think that for some businesses it's
totally fine, right? I think that especially
if you're early on, especially if things are still in project phase,
whatever. But I think at some point, pretty early
on, you have to figure out what are we
doing and what do we expect the result to be.
So at Justin tv, the first thing the problem we were solving
was entertainment. We were making TV shows. Justin was the first
one broadcast his life 24 7. It was supposed to be a TV show.
It was actually pretty easy for us to understand whether that was working or not.
Is anyone watching? That's the problem we were solving. People watch
TV shows. No one was watching. So we didn't solve the problem.
Then when we pivoted to an open platform, the problem became,
can we let anyone broadcast live?
Like, that was the problem we're trying to solve. Anyone can broadcast live on the
Internet. And once again, once we understood that,
it was very easy for us to judge whether or not someone could do it.
We had this open platform as anyone using it. But I think that, like,
that was key to what we were doing. And then sometimes when I talk to
founders, there's something they want to do in the world, there's a problem that they're
kind of vaguely interested in, or there's an idea they're vaguely interested in, but they
really haven't nailed down what's the actual problem we're solving. If you don't
know the problem, you can't know whether you solved it.
The first thing I ask founders, can you state the problem clearly in two sentences?
If you can't, you don't know the problem. Right. In fact, it should really only
take you one sentence. So if someone asks you what problem you're solving
and you find yourself delivering an essay, you're doing it wrong.
2. Have you experienced the problem yourself?
This is not always required, but is certainly helpful.
I've met a lot of founders who are trying to solve a problem for
someone else who they've never met, never talked to, and don't
truly know whether that person exists in the world.
And so, all things being equal, this is a great hint that you're
onto something. Well, at least one person has had this problem before.
The next one is, can you define this problem narrowly?
What's interesting is when you get started,
you can't really solve this problem for everyone who has it.
So when Justin TV first started, we couldn't let anyone broadcast
live video. You had to have a laptop, you had to have good Internet connection.
You had to have a webcam. There are all these kind
of things you needed. And so could we actually now
talk about. All right, we want to make live video for everyone,
but let's talk about the people that we can address first. Who can
we help first? And I think oftentimes founders kind
of want to skip that step. They want to solve the mega problem.
Like, I want to cure cancer. I'm only talking about when everyone's
cured, as opposed to, like, what can we address immediately?
How do we get the first indication this thing is working?
And then the last one is the problem solvable. So here's
what I'll bring up with Poppy. So Poppy is a company that's
essentially Uber for babysitting. They make it really easy for
babysitters. I'm sorry, for parents, you need babysitters to get babysitters.
Poppy is a very interesting company because you need babysitters for a lot
of different types of things. Some people need a
babysitter five days a week while the parents at
work. Right. That looks a little more like a nanny. Some people need a babysitter
when it's an emergency. Oh, I have,
you know, I have a medical emergency and I need a babysitter right now because
I need to go to the hospital. Some people need it because there was
misplanning. Oh, I thought my husband was going to be here this time, and it
wasn't. I thought I was going to Be here. This time it wasn't I need
a babysitter. Some people need a babysitter because they have an infant,
right? And so this babysitter needs to have a bunch of skills. Some people need
a babysitter to watch their 15 year old to make sure they don't get out
of the house. Different skills. And so what's interesting is that
if you just start with, oh, we're going to help people get babysitters,
it's not really good enough to understand what you can address right
away. Right. Which one of those use cases do you want to address?
If you were to state the problem more narrowly though,
let's say we wanted to start out with infants, right?
We want to make it easy for parents to get babysitters for infants. Then we
can really ask the question, is the problem solvable? I think one of the
things that Poppy discovered when operating their business is that
the level of skill that you need for a parent to trust you
with their infant when they haven't met you is very,
very high. So the idea that you're going to have a rotating
set of people you haven't met watch your little baby hard,
very, very hard. They have to be very skilled. And then on the flip side,
the Uber model only works because there's a whole bunch of
basically replaceable people with a common skill.
Well, it turns out the people who've got the skills to watch infants and
make parents comfortable with that tend to have nanny
jobs where they work lots of hours and tend to be paid fairly
well, especially in up and coming cities. And so now we have
this disconnect where it's like, well, we want to solve the problem of infant watching
for moms. But that talent pool, who can solve
the problem, the supply of babysitters, they might not exist.
Problem might not be solvable. And so going
through this exercise in real time, like with your products out
in the world, you should be thinking about these things. You should be thinking,
how have I narrowly defined the problem I want to solve first? And you should
be always asking yourself, is it actually solvable?
I think a lot of founders just don't want to think about this because
it's hard. It's hard to think about who you want to talk to first.
It's hard to understand, oh, maybe I can't solve their problem. I have to move
on. Avni was a mother of two kids
and she was really pissed she couldn't solve this problem because it was her problem.
But it's turned out to be very, very hard Problem to solve.
Young infants on demand babysitters.
All right, the next question I always ask is,
who is your customer? And really,
you don't understand the problem you're solving until you understand
who you're solving it for. A lot of times people just
want to say, everyone. Everyone's the customer. Right. And that
seems like it makes sense in some cases, right? If you're building a social
network or a search engine. Right. Everyone uses those things. Now, what I
will say is that in almost all of the products that everyone uses now,
there was a time when almost no one used them. And the.
The creators of those products had to figure out who was the ideal first customer.
And so if you don't have a good answer to this question,
you're going to be lost. You have no idea who you should talk to to
ask them whether this problem has been solved, and you have no idea who to
talk to to figure out who this product is
for. And you'd be surprised at the number of
founders who are just building something as if they were writing a
creative novel where it's just a product of their own brain
and no interaction with anyone on the outside. And it's not even
a problem that they're solved that they've experienced themselves.
Don't do that. Don't be one of those founders. Like, you can
talk to your users. You just have to figure out who they are.
The next question I often ask is, how often does
your user have the problem? What's so surprising is
when you talk through startups with people,
sometimes they choose problems without quite understanding
who the user is or the frequency of the problem. So I'll give you an
example. A lot of people will come to YC and a popular
idea back in the day was to build a car shopping website.
Now, if you guys have been on car shopping websites, especially about five years ago,
they all basically suck. They're hard to use, they're not
very transparent. You kind of want to have this almost Tesla experience of just
buying a car, but they never actually work out that way. And what's
interesting is that, like, a lot of founders come back to this problem over and
over and over again, and they always think that their customer is the person
buying a car. Now, the reality is that
when you go buy a car, assuming it's not a complete lemon,
you typically keep that car for seven years. So what happens if
I told you I'm going to create a startup and if I home run with
my customer, if my fucking customer loves me, they're going
to Come back seven years from now.
That's hard. It's very hard. It turns out a lot of
the car buying websites are not built for the person who's
shopping for a car because that person doesn't have a problem very
often. They're actually built for the person who's selling a
car. That person has a problem every day.
Every day the dealership has to hit their numbers.
And so you don't see as a customer how
that product helps the real customer,
the person who's trying to sell cars. And so by doing this analysis,
I really try to push founders in understanding who is getting
the most value out of this product. And it's really helpful if you're trying
to help someone with a problem they have. Frequently. If you think
about the products that you use on a daily basis,
they tend to be on the front screen of your phone. You tend to use
them without even thinking. They become almost extensions of you.
If you think about apps that you've installed and then they're kind of on the
third page in the back, or they're buried on the second page of some folder,
those tend to be the ones you don't use very often.
Hopefully they don't need you to use them very often, or else they're probably not
very good business. The next question I always ask is,
how intense is the problem? I find a lot of
founders think they have a good idea, but they don't do this frequency and
intensity analysis. And so if you have both an
infrequent and low intensity problem that you're trying to solve,
you're going to have a problem getting a lot of customers even interested in talking
to you. All things mean, if you graph problems, it's nicer
for them to be higher intensity, higher frequency. Let's think about
a company like Uber, for example.
Usually when you are somewhere and you need to go somewhere else,
it's a pretty intense problem. I have to go to work,
I have to go to the doctor, I have to go pick up my kids.
They're so intense. You might have bought like a $20,000
car to help you do those things. Right? So it's an intense problem.
And then when you think about frequency, how often do you move more
than a mile, more than walking distance? Every day.
Happens a lot. And so if you think about that,
even though you look at the taxi market and you say,
oh, taxis, you know, before Uber taxis, that's not that big of a market.
If you just look at the customer, you say high intensity problem,
that happens very often. There's probably a good business here.
The last one is, are they willing to pay? So many founders
who come into yc, their first thought is completely
wrong on this front. Their first thought is I need to give it away
for free because that's the only way I'm going to get users.
One of the things that I always push them to do is think about it
this way. If you want to know whether you have a good product,
it's a lot easier to make it a little bit harder for your users to
use it and then see if they use it anyways.
Because if I have extremely intense problem and you say, well,
it's going to cost 100 bucks for the person with extremely intense problem,
they're probably thinking that's a deal. If you have an
extremely, if you don't have extremely intense product problem, you charge
$0. You're going to be a bunch of users who come in who don't really
have the problem, but they're just trying something out.
If you try to learn from them on how to improve your product, oftentimes they'll
lead you astray. So strangely, starting with a higher price
or a price is almost always better than starting from
almost always better. And if you have to start free,
you need to do this analysis of how do you talk to the users
where the problem is actually intense? How do you talk to the users who are
using your product frequently in production for real world purposes as
opposed to the hobbyists? Talking to your customers is good,
but talking to the wrong customers, very, very, very bad.
I've seen a lot of companies that are basically hijacked by
bad customers, especially companies where there's
real world costs. So for example,
you know, if you have a company like Poppy, there's real world costs in
recruiting, managing and working with all of these babysitters.
And if you have a company, if you have a customer who's trying to basically
take advantage of that system, being late, being non responsive,
being rude to the babysitters, that's not going to help you run your
business. And you'd be surprised at how many hijack customers there are
out there. The last question I always ask people is how
easy is it for your customers to find because inevitably you're going to need to
reach them. And what's interesting, I look at the last batch,
there were two B2B companies, one B2B company was here in
America and it was very easy for them to find customers. They could Basically go
to LinkedIn, find their customers on LinkedIn, find their email addresses,
email them. They can email 1,000 customers a week.
Another company doing B2B was in China. And interestingly
enough, reaching out over email in a B2B
context in China just isn't a well done practice. Getting access
to people's email addresses is actually not very hard, not very easy.
And so, strangely, they had this challenge of a relatively
simple business to explain a real intense problem that happened often,
yet they had no way to reach their customers and they had to basically invent
new ways to do it. And so I often want to ask this
question, because if your customers are ridiculously
hard to find, you better have a solution for that upfront.
You can't build the whole thing and expect for them to find you.
And so oftentimes you had a situation where
someone's trying to build a product for either an imaginary customer
or a customer who can't really hope to use the product.
I'm trying to get water to people
in the middle of the desert in the Sahara.
All they need to do is download my app and go online
and then they can put their GPS location and then we'll deliver water to them.
That's not going to work, but you'd be surprised at how many people just don't
think through those logical steps. All right,
next up, does your MVP actually solve the problem
that you want to solve? This one is so hilarious
how often it comes up, because in the process of building an mvp,
things just go weird and squirrely. So you had this problem and
then you started building it, and then you talk to other users and then before
long you're launching something and then you realize it
doesn't actually do the thing that you promised or even the thing that you want
to do. So part of your process of building the mvp,
it's really helpful to do these pre steps first.
It's really, really, really helpful because then you can
always gut check yourself on, am I actually solving the problem? The other
thing is that it's really helpful to build your MVP quickly.
Typically, the longer it takes, the more you're going to have MVP and problem
drift, or customer drift. If you decide to only build your MVP in
two weeks, it's a lot easier to stay on task and make sure actually solving
that problem for that customer. The way you test this, by the way,
is you give your product to customers.
Like you have to do that. That is a required step.
What I find interesting is that a lot of people think of their product as
a painting, as something that could be appreciated
as a piece of art, as something that even if it's appreciated by one
person is special. That's not what you're making. Products are
not paintings, they're not art. If users don't find
products useful, then the products are by definition not
useful and they're a waste of your time to build.
And I think a lot of people want to be artists.
The startup world is very unforgiving to artists.
And I think that interestingly, after the fact, a lot of people are painted
as artists, right? Like Steve Jobs is painted as this like magical artist,
right? The other day he had to figure out how to make a phone
that millions of people would buy. If only one person bought the iPhone,
he would be seen as a failure. So the
definition of art is it only has to be appreciated by one, or maybe
even none. That's not the apprecia,
maybe just the creator. That's not the definition of a successful product.
So this is what you should always be gut checking. Does your MVP solve the
problem? The number one problem with this question is that it hurts. The answer
hurts. You're going to find that a lot in startups where the answer hurts.
You know, it doesn't solve the problem. But as long as we don't talk about
it, maybe nobody knows it doesn't solve the problem.
A lot of the answers inside of startups feel that way.
Which customers should you go after first? A lot of
founders are very confused by this question.
What I find interesting is just like the instinct is to go after customers
by making the product free. For some reason, I find a lot
of people think that their instincts should be to go after the hardest
customers first. Almost as if it's like a proof, like if I can get
this impossible person to use something, then like it'll be
easier. I know that I've made something good.
I like to start from a different point. It's an mvp, you know you've
made something bad. That's the definition of mp.
It's bad. So the real question is like, how do you
find people who are willing to use a bad product,
right? They have to be the most desperate,
the most desperate. And so a lot of times when I talk to founders,
I really push them towards who are the most desperate customers
and how do you talk to them first? That's what I define as easy,
desperate. If you're having like a, you know, if you're
trying to sell a simple piece of software to someone, $1,000 a month,
and you're engaged in a six month conversation with a company,
that's not a desperate company move on.
In fact, when you're doing enterprise sales early as a startup,
like, you're looking for even more desperate customers just because
literally takes so long to sell them. So if you don't feel like you're dealing
with desperate people, if you feel like you've dealt, you are trying
to get impressive customers who aren't desperate,
you're probably doing it wrong. Literally the number
one thing I often tell founders, just like, whose business
is going to go out of business without using you? Which people
out there are not going to be able to get to work or to watch
their kids? How do you find the people who are just literally
screaming for something like this? And then
how do you talk to them and not talk to your friends?
You had a whole bunch of friends who were using socialcam,
right? My company was doing video for sharing with
friends and they weren't really using it. They were using it because it was like
my app and they were friends with me. I literally had one friend who was
like super honest about this. Steve, CEO of Reddit. When we sold socialcam,
he literally said, thank God, now I can delete this app from my phone.
So the perfect definition of someone you should not be trying to get
product feedback from, right? And so he
didn't have the problem we were solving. Many of your friends won't have
the problem that you're solving. Make sure you find the.
And by the way, the kind of community of startup people
and, or investors usually don't have the problem that
you're solving. So if you're using investors as a trigger for am
I solving the right problem? Or like, do they
find this useful? It's almost never the case. I'm almost never the
user of a product that comes into YC and so
ignore your investors, ignore your friends. Like, they will lead
you 100% astray out of good intentions. They'll try to be
helpful. Well, you know, I've never lived in the Sahara. I've never
been thirsty. But maybe it should work like
this, right? Like horrible. Run away. Run away.
Once you start having customers, I think it's a very helpful exercise
to try early to identify bad customers.
These are people who are blasting your support.
These are people who are constantly,
constantly complaining. My co founder, Justin,
he had a company that was basically on demand personal
assistant and he was the first one who I met
who actively fired a customer. It was basically like uber for
personal assistant. It was called Exec. And literally a customer
would have the exec do something like crazy,
like something you couldn't do right, like reorganize my house the way
I want things organized. And I'm not going to tell you how I want them
organized or go shopping for me, but I'm going to
critique every single piece of fruit and vegetable that you picked out.
So it was a completely unrealistic expectations. And so after refunding the person
four times for four different tasks, the person did a fifth
task on the product, right? Because he's getting a bunch of value for free.
And Justin calls him and says, you're fired. You can't ever use product again.
Like, look for those people. Because if you are delivering anything
of value, there will be people trying to exploit that value.
And some might be doing it not out of
the goodness of their heart. So don't let these
people lead you astray. We already talked about this.
Don't discount. Now, here's a caveat
on discounting.
Parker from Zenefits came to YC a couple years ago and
he gave this great talk about enterprise sales.
And Zenefits is a product that's given away for free. So it's actually kind
of an interesting enterprise sale. And one of
the things he said that really got to me was that there
are ways to convince organizations.
Basically you can structure discounts and incentives into
your sales pitch if you basically understand
what value you're getting back. So his example was
he would try to sell to a company to switch on to Zenefits for their
healthcare. And he would say,
look, because of this third party, let's just say AWS has
given us a discount. Who knows why, right? We just bought
dedicated instances. So now we have 40% lower AWS
bills. So we can actually pass on some benefit to you,
but only for the next 30 days. Now, I feel horrible
even telling you this because I want you to take as much time as you
need to buy my product. I would just hate if you bought it on the
31st day and I couldn't give you this discount. Now this
isn't a let me give this away for free like,
because I'm afraid people won't use it. This is a very structured
process that he did. He basically incorporated a deadline
based on some third party providing a benefit
to the customer. And he knew that when
he said this to the customer. Every time that this was talked about
internally, the deadline would be brought up and the discount would
be brought up. And suddenly this has now become not a way to
be afraid, right? To, oh, I'm not sure if I make customers let me just
make it free. It became A way to speed up the process. And his discount
was just baked in, like he just priced the product 15% higher.
So it's like literally like that is
the way to do it. The way not to do it is I'm afraid no
one's going to use it, so I have to not charge any money.
Okay, the next is how to set up metrics. How many
of you are using Google Analytics as
your primary metrics product? Raise your hand.
Okay, you are doing it wrong.
Yes. So setting
up metrics is something that's super important very
early in your company because it's how you know whether your product is being used
or not. And it's one of the number one sources of new product ideas and
inspiration. So Google Analytics, I would say, is a great
product for knowing how many people came to your website today and how many
pages they viewed which used to be relevant and is not really relevant anymore
and where they came from. What it's not a great product for is
identifying what people's actions were when they
were using your product. Did they click this button? Did they see this screen?
How long were they on the page for before they did something else? Did they
leave something in their cart? For all of those things, you want an events
based metrics product. Mixpanel amplitude heap.
I think we've funded like 50 of them. There are like 100 of them out
there. You should be using one of them. If you're not,
you can't be sophisticated at building your product.
This is just kind of a prerequisite. So get on it.
And this goes back to the early thing that I mentioned, which is technical teams.
For a technical team, implementing Mixpanel is ridiculously
easy. For a non technical team, it's basically impossible.
This is just one of the many advantages of having a highly technical team.
You actually know what your users are doing. Without this, you're just missing a
huge part of what you need to know the next
thing. And Suhail from Mixpanel gave a great talk about how
do you set up Mixpanel? One of the challenges of setting up Mixpanel is
the second that you're sitting there saying, I want to track what my users are
doing, you can come up with like 150 things your users can do with
your product and you want to track all of them. That's often a mistake.
If your analytics product has got too many analytics
in it in the beginning, it will be hard to use. And part of what
you're doing if you've never used product like Mixpanel before is learning how to use
it and most importantly, teaching your employees and your co
founders how to use it. Because this product should be a product that everyone in
your company understands how to use. Because everyone in your company should understand how
the product is functioning. This is not something that like the CTO uses
and creates reports from. This is interactive product that everyone can use.
So to start, pick 5 to 10 simple stats.
Let's take Instagram as an example, right? If I were to pick 5
to 10 simple stats for Instagram, let's say opened
the app, created an account, took a photo,
applied any effects, shared the photo.
That's probably all I need in the beginning, right? I mean, the number one mechanism
for Instagram is taking a photo and sharing it. I can track that.
I'm pretty happy. The other thing that I will warn you
about is that if your product is good, the naming
conventions for these stats are going to become very important. Because one day there will
be 100 or even 1000 stats you track. So think a little
bit ahead of time and don't name something, something that only you'll
understand. Make sure that you, if your company is good, many, many people
have to look at these stats. Make measurement a part of your
product. Specifically. Oftentimes when I talk to
founders, they say, we built it on this release and we'll add the measurement
some point in the future. I don't understand how that works.
You build something you want people to use, but you're not incorporating
the measurement that tells you whether people are using it. That doesn't
work. Building measurement is part
of a product spec. So when you spec out a product, you better
spec the stats you expect to be tracking. And you
should also spec the stats that you think are going to improve when
you're building that product. That should be part of the spec. It should be part
of the first release. Otherwise you're flying blind.
And this is just countless times at Justin tv. This has screwed us.
Okay, product development cycle. So Justin TV
was in Twitch was three Yale kids
and one MIT kid at Yale. Probably the most productive skill
you're taught is how to argue with other Yale kids. And so the
number one way to get product developed at Justin TV was to win an argument
with the three Yale kids. Kyle disliked
this so much that he actually switched his sleeping schedule
so that he wouldn't have to be involved in these arguments. So we were awake
from about 8am to about 12 midnight.
He would wake up around 11 midnight and
write code all night and then go to sleep in the Morning so he
wouldn't have to argue with us on what stupid thing to build.
One of the classic arguments at Justin TV that lasted approximately
three months was the background color
for the original site. The original site is just one page.
Justin wanted a black background, I wanted a wood
grained background. Three months of
bait. We settled on changeable
backgrounds. So there were five
background options. Clearly idiotic.
Like I said, we made many of these mistakes. We didn't
actually really learn how to do a product development cycle until we failed
at it for about five or so
years. And during that time,
this is what bad product development cycle looks like.
One, we would release every three months for
a web only product. That is horrible.
Second, we would have a product meeting and we wouldn't write anything down,
right? It was just four of us. Can't you remember? You're an idiot if you
can't remember a conversation four people had, right?
And if you forget something, just ask one of the other four people in the
room, right? No. So as a result,
during the first month of the dev cycle, we'd all
go off working on slightly different versions of the thing we wanted to build because
we didn't write down the spec. Then at the end of that month,
we'd come together and we'd be like, oh wait, this isn't. We're not
really building all the same thing. And then we'd have another product meeting where
we didn't write anything down and go off and build
again for another month. At this point,
two months in, we probably have about three weeks of productivity
and about five weeks of just stuff that's going to have to be thrown away.
At this point in we come back together and realize that we're
not 2/3 of the way done through this sprint, we're less than one third
of the way done and we're starting to get sick and tired of this feature
that we're building. So then we basically say, all right,
slash and burn. Let's just make a shitty version of it.
And we take another month to do that. Now, we've worked on this product for
three months. If you had any good or new or interesting ideas
during that three month period of time, you were told, we're already
working on something else, so your ideas are worthless, just write them down somewhere.
Whatever. We're working on this thing right now. At the end of the three months,
instead of wanting to iterate, we were sick of the goddamn feature we
just spent three months building poorly so we would
launch it. And if it wasn't used right away, we would come up with
some new brainstorm on some brand new feature that would rescue the company.
This is the wrong way to run a company. It was
absolutely horrible. I was talking to Jeff earlier. The major product decisions
that Justin TV made that carried through to Twitch to
today was chat on the right, video on the left.
We decided that in 2006 it is the same way.
2018, the vast majority of the product decisions we made
were horrible and never saw the light of day because they went through a process
like this. So if your process revolves around
arguing, revolves around not writing spec,
revolves around long dev cycles, you are doing it wrong.
You are 100% doing it wrong. What I'm going to give you is
a model of how we figured out how to solve the problem.
Steal as much or as little of this as you want, but understand that
if you have any of the symptoms I'm talking about, you need to solve
them or else your company is just going to be much less productive than it
could be. First, you need to actually have a
number that you track that reflects how good
your company is doing. Almost always, if you
ever are going to charge money to your customers,
this number should be revenue. Almost always.
If you are never going to charge your customers money like
Facebook, then maybe it should be a usage based metric like
how often do your customers come back every day like DAUs,
it is almost always one of those two
usage. If you will never charge the customers money,
if you will charge the customers, many people will invent reasons
why these two metrics don't apply to their business.
1% of them might be right, 99% of them are probably wrong.
Whatever this KPI goal is, make sure that you're measuring it. Make sure that everyone
in your company knows what this goal is every day. Helpful to put it on
some screen somewhere. If an investor asks you what your KPI is, you not only
should be able to say what it is feel to say what the metric is,
you say where the metric is now, where it was three months ago, where it
was when you started. This is kind of table stakes.
The next thing that we would do is as kind
of product person, I would come into the meeting and I would
say this is the KPI we're looking to improve this cycle.
At socialcam, the top level KPI was
daus and the three ways that we thought we contributed to daus
was either new users, retention of users
and new content created those three things. So every
cycle we ran one of those three numbers.
Moving that number to the right direction was the goal and we'd
run an open brainstorm. Brainstorm for us would take a couple hours.
And it was a real brainstorm. It wasn't a brainstorm where like you say,
what about this? And your co founder says, that's a dumb idea. That's not
a brainstorm. The real brainstorm is that any idea that's stated
is written on the board. The cool thing about these brainstorms
is that everyone's computers were always open to Mixpanel.
So if you had an idea or you had a thought, you could always
just go in and check the metrics and see like, oh, is that right or
is that wrong? You'd be surprised at how
much value there is in seeing your idea on the board.
Not everyone's going to get to have built what they want to
have built. But the fact that your idea was considered and added to the board
actually makes people feel a lot better than otherwise.
People feel horrible when their ideas are shot down.
CEOs, their job is to make their employees not feel horrible all the time.
Sometimes I think CEOs think their job is to to shoot down ideas.
It's not. It's not going to help you at all. And everyone,
by the way, in our company participated in this brainstorm. At that point, that was
four people. So easy to do. The next thing was
we did what's called easy, medium hard. So our brainstorm was actually
typically split up into three categories. New features or iterations on existing
ones, bug fixes and or other
maintenance and tests. A, B test that we want to run.
We have a whole board filled out with ideas on these three categories.
And then we go through and do what's called easy medium hard. For us,
hard meant it would take one engineer most of the dev cycle to build.
Medium typically meant to take a day, two days easy means
we could do multiple in a day. This is extremely important.
How many of you in this room do not know how to write code?
Raise your hand. There we go. I am
one of you. It's extremely hard if you don't know how to write
code. To figure out whether your idea is easy to build or hard
to build. That's something that you actually learn as a skill over
time. And this process basically is the process
that can help educate you. It turns out that easy ideas
get built way faster, way more quickly than hard ideas.
And it turns out that most hard ideas can be restated as
an easy idea if you just understand what bits of your hard idea
are both useless and hard. And most of the time There
are useless and hard bits in hard ideas that can just be removed.
And so for us this was educating everyone on the
team and for us we had a cross functional team. So someone might not realize
that this is really hard on the video system. It might be an easy web
feature, but hard on the video system or vice versa. So this was basically educating
everyone on the team on what's easy, medium, hard. It also created an objective
standard by which to start thinking about these ideas instead of just based on
the argumentability of the person delivering them. It was like, well,
your idea is like really freaking hard and seems like it wouldn't move the numbers
that much based on Mixpanel. Whereas like this other person's idea is
super easy and probably can move the numbers a lot. The next
thing we would do is we decide hard first.
So we look at all the hards and we say which hard is going to
impact the KPI the most. And then
we moved to easys and then we moved to I'm sorry. Then we moved to
mediums and then we moved to easies. What was interesting is that like
just with the ideas on the board and with easy, medium, hard, a lot
of the ego was removed from the debate because one, you knew your idea had
been considered and two, you'd send us some objective measure about how hard it
was. And three, because the board has a bunch of ideas on
it now, it's probably pretty easy for you to find an easy
idea that you really like. And so you're just going to be excited that
that's probably going to get in and your really hard idea,
that's fine. If it doesn't, the next step
is you have to write the spec. This is where everyone fucks up. The meeting
might be going on for four hours now and
this is the step no one likes. You actually go through and you
actually write down. What do we mean by we're adding video filters to
socialcam? What do we mean by were allowing
people and Justin TV and Twitch to chat with one another? What does that actually
mean? How is it going to work? This is
really important and once this is done, you can then distribute
tasks to the team. Now we would run these cycles every
two weeks at socialcam because back then submitting to the
App store took longer. If you're doing a pure web product, you can run these
cycles once a week. The rule that we had to
make the team not hate these really long meetings. This was the only meeting we
had. This is the only meeting. And so it might
take two hours. It Might take six. But for that two week period of time,
there were no other meetings. In fact, for me, being a non coder,
my number one job was to shut the fuck up because I
could create a problem, right? We're busy
working, we have this written spec, everyone knows what they're doing. If I have some
brilliant idea during that two weeks, right,
That'll throw the whole thing into chaos. Suddenly the written
spec is not important, we're back to the drawing boards or we're changing
things, yada, yada, yada. What I had to realize is that every two weeks
we do this over again. So for that burning idea, just fucking wait two weeks
and we're going to have the meeting again and then we can get it in.
And turns out your burning idea is probably wrong. So it's totally fine to
wait two weeks to try to convince people to do something wrong? It's totally
fine. As opposed to like having this cadence meant every
two weeks we had success every two weeks. If we built what we said we
were going to build, we felt good. And then that cadence meant that we
go into the next cycle and do even more. This cadence is extremely
important because it's going to take you guys a long time to find product market
fit. You'll be trying a lot of things, iterating a lot,
and if that process doesn't feel fun,
you're going to get very frustrated. This made the process feel fun because we
had goals and we accomplished them. Pivot versus Iterate
A lot of YC companies and a lot of founders in
general will tell me our thing isn't working.
It's been two months, it's time to pivot.
When I think about that statement, it blows my mind,
right? You're building a new product for a customer
who might not have ever used a product before. For you're oftentimes exploring a
problem that you only know to some degree, or you've only experienced it
personally. What makes you think two months is enough time
to know whether you figured something out what impressive
thing only took two months to build?
So if you're not thinking that the process of coming up with a solution for
this problem is probably more like a two year process,
you're doing it wrong. If you are unsatisfied with significant progress
in under two years, you're probably doing it wrong.
It's going to take time. You're doing something hard.
If it was really easy, someone else would have done it. So I
define pivot as changing the customer
or changing the problem. This should be rare.
This should happen infrequently,
many times. This means you should start a new company.
I defined iterate as changing the
solution. It turns out you had the right customer, you had the right
problem, your MVP was shitty and it didn't work.
We need a new solution. It turns out maybe your MVP was
great, but it didn't solve the problem. We need a new solution.
It turns out you showed the product to your customers and they didn't want to
use it even though they have burning problems. We need a new solution.
Oftentimes I see this in reverse. People think solution first,
and when the customers they thought didn't like their product, they try to
find some other random customer who does, who might even have a
completely different problem. And they tried shopping around their solution because they think
their solution is the genius part. I think the
problem is the genius part. I think identifying a problem that other people haven't
figured out is worth working on is the genius part.
Right? Facebook wasn't first to social networking and Google
wasn't versus search engines. Their genius was understanding that
the people who came before them hadn't solved the problem. And if
they could solve the problem better, they'd build huge companies.
Their genius wasn't, oh, we built this cool thing.
Let's just figure out who might want to use it. Wrapping up a little bit
here. I like to tell a story about fake Steve Jobs
versus real Steve Jobs. A lot of people think that
Steve Jobs is this person they should emulate,
but they have a false picture in their heads of what Steve Jobs was.
They think that like he dreamed perfect ideas out of his
head and into the world. And what's funny is that I think oftentimes
people look at the iPhone as a perfect example of this,
but they look at their iPhone today. Your iPhone
today is fucking magical. The first iPhone
sucked in almost every way.
And they don't realize that Steve Jobs wasn't somebody who was
just not iterating, who just imagineer perfection. Minute one.
Steve Jobs was iterating at every step.
So I like to remind people what the first iPhone did.
First iPhone, no, 3G, back when 3G was a
standard feature. So, oh, you have this great Internet browser, but you can only use
it on edge, which means it fucking sucks,
right? One carrier. Oh, you don't have this carrier,
Sorry. Switch carriers figure that out.
Horrible battery life. Screen cracked all the time.
No app store. You can't even download other apps.
That was the first iPhone. Everyone forgets that iPhone. So if you
are the person in your company who is Being Fake Steve Jobs is
saying the product has to be this way. Because what I said,
fuck the customers, fuck everyone else, Fuck you.
Make the product the way I want it to be. You're being Fake Steve Jobs.
Real Steve Jobs released a shitty MVP that was revolutionary,
but still fairly shitty. And every year iterated it
until you have the thing in your pocket right now, which is pretty damn good.
Real Steve Jobs iterates and talks to customers.
Fake Steve Jobs just dreams and creates art.
Don't be Fake Steve Jobs. Okay,
so with all of this, I want to go back to the beginning.
What I said in the beginning still holds. Justin tv. The only reason why I
actually even know any of these rules is because we broke all of them.
The one thing that Justin TV and Twitch had was a
really strong technical team with high ego in the product
and low burn. When we started figuring things out
with Twitch, it was very interesting. Gamers had been
on our product the whole time.
Gamers have been streaming on Justin TV since almost the beginning. At any
given time, there were 20% of our traffic. For years,
we ignored them. We ignored them. We ignored them.
We ignored them. We ignored them. They still use the product. We didn't
build features for them. They still use the product. They must have been pretty fucking
desperate because they still use the product year after year.
The number one thing that changed when we started working on
Twitch was we started talking to them. And what's weird was it's
not like we were talking to other users. And the other
days with smtp, we didn't talk to any users. We had this like crazy product
development cycles. We couldn't do that with talking users too.
So what we did in the beginning was we literally just sat down with these
gamers and we said, what did you want? And what's funny is we didn't build
them anything very special. They were like, oh, like lag sucks.
They wanted like little things. What was great about it was they
realized we were now going to build something for them and
no one on the Internet was building things for these gamers.
And they realized that when we said we were going to build something, it came
out. When was the last time that you talked to someone building a product
that you like and you said, can you do this? And they did it.
When was the last time you suggested a feature to market Facebook and then the
feature came out? Never. Like, it's one of the magical
things you can deliver as a startup is you can talk to a passionate user
and then you can build what they want and then you can say here it
is and they will fall in love with you, even if those features are relatively
mundane. Because let's clear Twitch today. Chat on the right,
video on the left, the same product.
What was great about this process was by talking to them, they realized
that we were on their side. We realized they were building something for them.
So they told their friends. That was the major change.
If we didn't have the technical team, if we weren't cheap, if our
ego wasn't involved, never would
have gotten to that point. And if you look at the history of Justin
tv, in the first five years it went from being worth nothing
to being worth about $24 million. In the
next three years, it went being worth $24 million to being worth a billion.
That's what software can do when you hit the right customer.
Let's do a couple questions in the back.
So you mentioned that you should try to charge
discounts, but if you, if even your final
product, you're planning to make it a free app and monetize
with some premium content, what should you do?
So the question is, put it more generally,
should you be going free? If your final idea for a product is to be
free, What I would say is this. If your users
are users who you never plan to charge,
then it's totally fine, free to be free. But if you do plan to
charge them in some way, it's really helpful to charge them as soon as
possible because you want to know whether or not they're willing to pay.
And certainly if their business depends on it, it's especially
helpful to charge them. So that's the measure that I would use.
And there are all kinds of little tweaks and so on so
forth. But at a high level, do you ever plan to charge them? I charge
them. If you never plan to charge them, you plan to monetize based on
ads, which is really usually the way that you never plan to charge them.
You can monetize with ads. If you're not going to monetize with ads, you probably
should start charging them. All right, next question.
Thank you for sharing all this. You mentioned that the almost
always the best revenue or the best KPI to track is revenue.
Yep. Let's say I've launched I'm early phase. I'm trying
to get that first sale. I know for a few weeks it's going to be
hard to get that to go from zero to anything. Should I still be writing
revenue down or should I track something? Revenue.
If your metric. If your KPI is metric,
yeah. Yeah, yeah, do that. If your KPI is revenue
and the number is zero, should you still be tracking that as your top
line KPI? The short answer is yes. You should be depressed
looking at that number every week until that's the answer.
Now let's be clear. Like I said with socialcam, there are contributing
numbers to that. And so whereas DAUS
was our top line metric, the things we thought
contributed to that new content, new users,
retained users, those numbers we can move. So if you're in a sales type
business, your KPI number one revenue, if it's zero, that should
fuck you in the face. 00, zero. Horrible. But then
you should ask yourself maybe your three other metrics are how many
conversations did we have this week? How many people are in contracting,
how people are in onboarding? And those can be your three numbers that
will, if those numbers move, you expect the revenue number to
move and they can keep you motivated. But your top line KPI
is no bullshit. Like absolutely no bullshit.
Okay, thank you. We're a hardware company
pre launch and so our users,
our target market, experience our problem five to 900 times a
day. And the intensity is can we pay our rent or not?
But we'd like to offer presales as a way of getting the product to
market. Do you guys have any tips on doing that?
Do we have any tips on pre sales? What I would say is that there
are many, many tips on pre sales. I would email some founders
who've done it before. That's one of my best tip is to email them and
ask them what they did. The number one mistake I see with
pre sales is discounting. The number one mistake is that basically
especially hardware, founders will misunderstand how much they need
to charge so they don't lose money and so their presale becomes
their death. So I'd avoid that. All right,
two more quickly on the way back.
What was the hardest part of that and how did you deal with it?
What was the hardest part of having a slow burn? Well, we were young,
so it wasn't hard at all. We were living like we lived in dorms.
I think it's a lot harder now, right? I've got a kid, I got
a wife, got an apartment, got a car. It'd be really hard now.
And so I think really the hard
part about slow burn is can you adjust your lifestyle
if you've already leveled it up and if you haven't leveled up your lifestyle yet
and you're still working, you know, if you're young and you're still, working at a
company that's paying you well, not leveling up your lifestyle is
a big way to stay ready to do a startup.
Adding on the mortgages and the cars and the vacations makes it a lot
harder. I just know a lot of people who never could come back from that.
Absolutely never in the back. Yeah.
Can you talk a little bit about going from data to early mvp?
Going from beta, how do you go from beta to early mvp? I don't really
know what those distinctions are. All I know is are people using your product?
Yes. No. If people are not using your product,
get to the point where people are using your product extremely quickly. Once people are
using your product, there's all different labels for it. Beta,
pre launch, alpha, blah, blah, who cares?
It's just that's the dividing line. Like are people using your product? The next question
is, are you actually solving their problem? That's the next question. Not like,
are we following this line of launching things?
Most YC companies will launch many, many, many, many times.
So that progression isn't really that important. Are people
using your product? Yeah. Great. Bam.
You're launched. Congratulations. Call whatever
you want. All right, one more.
Here you go. Yeah, I mentioned regarding how to
select graph text feature to work on.
You already mentioned it and I'm sure that we should follow the metrics.
But imagine that we have a pool of
two or three passionate users, but each one
wants something different. So we will be an expert in which we
are ensured which one will impact.
So this is a great question and
I'll have an unsatisfying answer. So the question is basically
how do we figure out what to build next? Here's my answer.
The reason why you have a product development cycle is that you
can work on multiple things. Usually there isn't a right answer.
Usually all of the things that you want to build won't work.
So what you need to do is you need to create a process in your
company to build things quickly so that you can actually see whether
they work or not and then you can iterate them from there. So it's far
more important to have a technically talented team
that can build MVPs quickly in a non frustrating
way and then measure the results than it is to be a
super genius who can imagine what's going to happen in the future without actually knowing
now. In the big picture, you have to have that imagination for
your vision for where it's going to be ten years from now. You have to
have that imagination for the little technical like tactical
move in the next three months.
It's really hard to nail those. If you have a process that can rip out
things quickly and then only iterate the things that are working,
that'll serve you far better. Our mistake was that at Justin TV
it was thinking, every time we've got the home run, let's only
swing for home runs. And of course it would take three months to do it
because we got to make it perfect, right? And then the whole spiral of death.
All right, the last thing I'll say is my email address is michaelycombinator.com
Strangely, I tell people that I answer every email and
people mostly don't believe me. And the ones who do email me
and I reply. And so everyone I talk to
and everyone online, there's really only two categories of people. The people who don't believe
me, in which case, great, continue your lives and the people
who will believe me. And if you need help, they'll email and I will try
to help you the best I can. It's really that simple. You don't need to
have networked with me. Y combinator is fairly easy to spell
and so is Michael. So you should be able to figure that out.