- Michael Seibel, CEO of Y Combinator, discusses his experience at Justin.tv and Twitch.
- The three things that saved their company were having a technical founding team, not spending a lot of money, and having their ego tied to the success of their startup.
- He will share stories from Justin.tv, Twitch, and a YC company named Poppy to discuss product.
- He emphasizes the importance of understanding the problem you are solving and being able to state it clearly.
- It is helpful to have experienced the problem yourself and define it narrowly.
- Lastly, it is important to determine if the problem is solvable.

- The video discusses the importance of understanding the problem and the customer when building a startup.
- It emphasizes the need to identify the ideal first customer and understand the frequency and intensity of the problem they face.
- The video suggests that founders should consider charging for their product and focus on reaching the right customers.
- It also highlights the importance of ensuring that the minimum viable product (MVP) actually solves the problem and suggests building the MVP quickly.

- Products are not art, they need to be useful to users
- Startups should focus on finding desperate customers who have a pressing need for their product
- Don't rely on friends or investors for feedback, they may not be the target audience
- Identify and avoid bad customers who constantly complain or exploit the value of your product
- Discounting can be used strategically to speed up the sales process, but don't give away your product for free out of fear
- Use events-based metrics products like Mixpanel to track user actions and gain insights for product improvement
- Technical teams have an advantage in implementing metrics tools like Mixpanel

- It is a mistake to track too many analytics when setting up Mixpanel
- Start by picking 5 to 10 simple stats to track
- Naming conventions for stats are important as the number of stats will increase over time
- Measurement should be incorporated into the product spec from the beginning
- Bad product development cycles can lead to wasted time and unproductive features
- Have a clear KPI that reflects how well the company is doing
- Run brainstorming sessions to improve the KPI, with everyone's ideas considered
- Categorize ideas into easy, medium, and hard to prioritize development
- It is important to understand the difficulty of implementing an idea if you don't know how to code.

- It is difficult for non-coders to determine if their idea is easy or hard to build
- Easy ideas are built faster than hard ideas
- Hard ideas can often be simplified by removing useless and difficult elements
- Educating the team on the difficulty of ideas helps with decision making
- Prioritize hard ideas that will have the most impact on key performance indicators (KPIs)
- Medium and easy ideas are addressed after the hard ones
- The process removes ego from the debate and creates objective measures
- Writing a spec is crucial to ensure everyone understands the implementation of the idea
- Tasks are distributed to the team after the spec is completed
- Running these cycles every 2 weeks is ideal, but can be done once a week for web products
- The only meeting held during the 2-week cycle is the planning meeting
- It's important for non-coders to not disrupt the process and wait for the next meeting to share ideas
- The cadence of the cycles creates a sense of accomplishment and progress
- Pivoting should be rare, while iterating on the solution is more common
- Identifying and solving a problem is more important than the solution itself
- Steve Jobs iterated on the iPhone, starting with a subpar first version
- Talking to customers and understanding their needs is crucial for success
- Twitch's success came from finally listening to and building for gamers
- Building something for a specific group of users who are often ignored can lead to success

- Startups have the advantage of being able to build what their users want and gain their loyalty
- It is helpful to charge users as soon as possible to see if they are willing to pay
- Tracking revenue as a KPI, even if it is 0, is important
- Pre-sales can be tricky, avoid discounting and reach out to founders who have done it before for tips
- Adjusting lifestyle and not leveling up expenses is important for a slow burn startup
- Going from beta to early MVP is not as important as getting people to use and solve their problems with the product
- Have a process to quickly build and iterate on features rather than trying to perfect everything
- Michael from Y Combinator is open to emails and willing to help those who reach out to him

- Michael Seibel, CEO of Y Combinator, shares his experience at Justin.tv and Twitch
- Three things that saved their company were having a technical founding team, not spending a lot of money, and having their ego tied to the success of their startup
- Importance of understanding the problem being solved and stating it clearly
- Emphasizes the need to understand the customer and identify the ideal first customer
- Suggests founders should consider charging for their product and focus on reaching the right customers
- Highlights the importance of ensuring the minimum viable product (MVP) solves the problem and building it quickly
- Startups should focus on finding desperate customers with a pressing need for their product
- Use events-based metrics products like Mixpanel to track user actions and gain insights for product improvement
- Prioritize hard ideas that will have the most impact on key performance indicators (KPIs)
- Pivoting should be rare, while iterating on the solution is more common
- Identifying and solving a problem is more important than the solution itself
- Talking to customers and understanding their needs is crucial for success
- Charging users as soon as possible to test willingness to pay and tracking revenue as a KPI is important
- Adjusting lifestyle and not increasing expenses is important for slow burn startups
- Have a process to quickly build and iterate on features rather than trying to perfect everything
- Michael from Y Combinator is open to emails and willing to help those who reach out to him.

YC CEO Michael Seibel outlines how successful startups think about building something people want. Startup School is YC's free online program for founders. Sign up to access the full curriculum and over $100k in deals! https://www.startupschool.org/

Chapters (Powered by https://bit.ly/chapterme-yc) -
00:00:00 Introduction
00:00:53 What allowed us to survive?
00:03:50 What problem are you solving?
00:10:11 Who is your customer?
00:18:39 Does your MVP actually solve the problem?
00:21:10 Which customers should you go after first? (the easy ones!)
00:25:46 Should you discount or start with a super low price? (no!)
00:27:58 How to setup metrics
00:32:02 Product Development Cycle (v1)
00:43:44 Pivot vs Iterate
00:46:09 Fake vs Real Steve Jobs
00:48:04 Summary
00:51:06 Q&A

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.

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 1, 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 privileged 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 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?

Emmett got his own bedroom, Kyle and Justin slept in bunk beds, I slept in the living room and sometimes on the balcony.

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.

It was like, well, this is the only thing you've done so far.

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 3 things that saved our company, made our company work.

And strangely, I don't even think if you take 1 of those things away, any 1 of them, we would have died.

So this isn't 1 of those things where it's like, oh, you can grab for 1 or 2, and that's pretty good.

So as I get into product I'm gonna 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 like, 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.

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.

Justin was the first 1 to broadcast his life 24-7.

So actually pretty easy for us to understand whether that was working or not is anyone watching, right?

No 1 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?

That was the problem we were 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, was anyone using it?

But I think 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 2 sentences?

If you can't, you don't know the problem, right?

In fact, it should really only take you 1 sentence.

So if someone asks you a 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 1 person has had this problem before.

The next one's 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 were 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.

And I think oftentimes founders kind of want to skip that step.

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 that this thing is working?

And then the last 1 is the problem solvable.

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's a very interesting company because you need babysitters for a lot of different types of things.

Some people need a babysitter 5 days a week when a parent's at work, right?

Some people need a babysitter when it's an emergency.

Oh, 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 gonna be here this time and it wasn't.

I thought I was gonna be here this time, it wasn't.

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, you know, 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.

Which 1 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 1 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.

And so the idea that you're gonna have a rotating set of people you haven't met watch your little baby?

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 for moms, but that talent pool who can solve the problem, the supply of babysitters, they might not exist.

And So going through this exercise in real time like with your product 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.

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.

She was really pissed she couldn't solve this problem because it was her problem.

But it's turned out to be a very, very hard problem to solve, young infants, on-demand babysitters.

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.

And that seems like it makes sense in some cases, right?

If you're building a social network or a search engine, right?

What I will say is that in almost all of the products that everyone uses now, there was a time when almost no 1 used them.

And 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've experienced themselves.

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.

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 5 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 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 7 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 gonna come back 7 years from now.

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.

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 the 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.

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 businesses.

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 gonna have a problem getting a lot of customers even interested in talking to you.

All things being equal, 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?

And then when you think about frequency, how often do you move more than a mile, more than walking distance every day?

And so if you think about that, even though you look at the taxi market and you say, oh, taxis, 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.

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 gonna get users.

1 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 an extremely intense problem and you say, well, it's gonna cost 100 bucks, for the person with the extremely intense problem, they're probably gonna think, that's a deal.

If you have an extremely, If you don't have an extremely intense problem, you charge $0.

You're gonna get 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 free.

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, 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 customers trying to basically take advantage of that system, being late, being non-responsive, being rude to the babysitters, that's not gonna help you run your business.

And you'd be surprised at how many hijacked 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 gonna need to reach them.

And what's interesting, I look at the last batch.

1 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.

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 up front.

You can't build the whole thing and expect for them to find you.

And so, oftentimes you're in 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.

But you'd be surprised at how many people just don't think through those logical steps.

Does your MVP actually solve the problem that you want to solve?

This 1 is so hilarious how often it comes up.

Because in the process of building an MVP, things just go weird and squirrelly.

So you have this problem and then you start 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 2 weeks.

It's a lot easier to stay on task and make sure you're actually solving that problem for that customer.

The way you test this, by the way, is you give your product to customers.

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 1 person is special.

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?

And the other day, he had to figure out how to make a phone that millions of people would buy.

If only 1 person bought the iPhone, he would be seen as a failure.

So the definition of art is it only has to be appreciated by 1 or maybe even none.

That's not the definition of a successful product.

So this is what you should always be gut checking.

The number 1 problem with this question is that it hurts, the answer hurts.

You're gonna 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.

See all Y Combinator transcripts on Youtube

Michael Seibel - Building Product