- The misconception that a great idea is necessary to start a company is debunked.
- Starting with a problem rather than an idea is advised.
- Having a personal connection to the problem can be helpful.
- Keeping a "problem book" and brainstorming with friends can aid in finding a problem worth pursuing.
- Being uniquely qualified to work on the problem is important.
- Looking at previous attempts to solve the problem can provide insight.
- Building a minimum viable product (MVP) is the next step.
- It is important not to fall in love with the MVP and be open to change and improvement.
- Releasing the MVP quickly is crucial for learning if the problem is solvable.
- Initial users should be carefully chosen and should have a strong connection to the problem.
- The goal of the MVP is to see if it actually solves the problem for any group of customers.

Michael Seibel on getting and testing startup ideas.

Michael is CEO and a Partner at YC. He was the co-founder and CEO of Justin.tv and Socialcam. 

https://twitter.com/mwseibel

Learn more about YC and apply for funding here: https://www.ycombinator.com/apply/

Chapters (Powered by https://bit.ly/chapterme-yc)
00:00:52 Start with a Problem
00:01:26 Personal connection is helpful
00:02:07 Brainstorm with Friends
00:02:38 Once You've Found an Interesting Problem
00:02:45 Why Are You Uniquely Qualified to Work on This Problem?
00:03:43 Your MVP
00:04:55 Your Initial Users
00:05:49 In Conclusion
00:06:00 Outro

There's a common misconception that your idea has to be great in order to start a company.

And the first thing I want to do is destroy that misconception.

Personally, I was 1 of the co-founders of a company called Justin TV.

It later became a company called Twitch and sold to Amazon for almost a billion dollars.

Our original idea was to create an online reality TV show.

Clearly It's hard to draw a line between that and creating a live video site where people watch video gamers and chat with their friends, but that's exactly what it became.

And so don't fall into the trap of thinking that your initial idea has to be great by any definition.

This is what you should think about instead.

My first advice is to start with a problem.

I think that starting with ideas is tricky because immediately people want to grade your idea.

It's a lot easier to start with a problem and to think about how do you grade a problem.

When you think about a problem, you should be asking yourself, do I have any relationship with this problem personally?

Oftentimes having a personal connection to the problem is really helpful for 2 reasons.

1, you can tell whether the solution is even within the ballpark of solving the problem because you've got some connection with the problem.

And 2, when you're feeling discouraged and the solutions that you're building aren't working, you still have some personal connection to the problem that sees you through until you find a solution that does work.

And I think a lot of people keep little idea books with startup ideas.

I think they'd have a lot more success if they kept little problem books and wrote down notes on the problems that they encounter on a daily basis so that their friends complain about, their family complain about.

Another interesting thing to do when you're starting to think about problems is to brainstorm with friends.

This is the perfect time to start thinking about how do you recruit co-founders.

And a lot of recruiting co-founders is about having really good brainstorming sessions.

Sessions where you talk about a problem, they elaborate on it, and you kind of realize that you trade ideas well and that you can talk to each other well and you can build ideas together.

And so I really advise when you're doing this thinking about problem Do it with some friends friends that you might want to create a startup with 1 day Once you find a problem that's interesting enough to start pursuing further The next question I ask myself is why are you uniquely qualified to work on this problem?

Now by qualified, I don't mean in the classical resume sense, like, oh, you've had 25 years experience in this area or something like that.

But what I do mean is that, like, is there some angle on the problem that you understand that you don't think others understand?

Is there some way of attacking the problem?

Is there some perspective on the problem?

Is some personal experience for the problem that you have that you don't feel is generally used or understood in other solutions to the problem.

In this phase, it's often helpful if you're solving a common problem to look at some of the people who've tried to solve the problem before and look at some of the products that are trying to solve the problem or have failed to solve the problem, just so you can get a basic understanding of what other people thought their unique insight was and whether it was the same or different than yours.

The next step is to start thinking about how do you want to build your MVP, your minimum viable product.

What's the first product, what's the first solution you're gonna build and release to your users to see if maybe you can try to help them solve this problem?

The most important thing to think about your MVP is don't fall in love with it.

Your MVP is most likely not going to solve the problem or is going to solve the problem very poorly.

And really it's the first step in the learning process of whether the problem is solvable at all, let alone whether you can solve it.

A lot of people fall in love with their product and are not in love with their problem or their customer.

Be in love with your problem, be in love with the customer, and treat your product in a way that it can change, it can develop, it can improve.

Don't be too in love with your initial product.

The most important thing to not fall too in love with the initial product is to release it quickly.

Oftentimes an MVP can be built and released in days or weeks.

It's not gonna be perfect, it might not be something you're proud of, but it can be the beginning of learning about whether or not you can actually solve the problem.

The last thing I would consider once you have an MVP is be very careful who your initial users are.

I actually believe that your initial users should almost be hand-picked.

But certainly, you should have a strong opinion about who your initial customer is.

And you shouldn't try to solve this problem for someone who, 1, isn't willing to try a startup, or 2, the problem you're trying to solve is not a really important problem in their life.

So your goal here with your MVP is not to see how many people want to use your product, is to see whether for any group of people, does this actually solve the problem?

For any group of your customers, excuse me, Does this actually solve the problem for any group of your customers?

Does this actually solve the problem that you're trying to solve?

And so the best startups actually very heavily filter the people who are able to use the initial product and make sure that they're the right type of initial customer.

So those are the steps that I would take from thinking about a problem, to building the first version of the product, to getting feedback on it.

That's how I would think about this problem.


Speaker 0: There's a common misconception that your idea has to be great in order to start a company. And the first thing I want to do is destroy that misconception. Personally, I was 1 of the co-founders of a company called Justin TV. It later became a company called Twitch and sold to Amazon for almost a billion dollars. Our original idea was to create an online reality TV show.

Clearly It's hard to draw a line between that and creating a live video site where people watch video gamers and chat with their friends, but that's exactly what it became. And so don't fall into the trap of thinking that your initial idea has to be great by any definition. This is what you should think about instead. My first advice is to start with a problem. I think that starting with ideas is tricky because immediately people want to grade your idea.

It's a lot easier to start with a problem and to think about how do you grade a problem. When you think about a problem, you should be asking yourself, do I have any relationship with this problem personally? Is this a problem that I have? Is this a problem that my friends have? Is this a problem that my family has?

Is it a problem that exists with work? Is it a problem that's in my community? Oftentimes having a personal connection to the problem is really helpful for 2 reasons. 1, you can tell whether the solution is even within the ballpark of solving the problem because you've got some connection with the problem. And 2, when you're feeling discouraged and the solutions that you're building aren't working, you still have some personal connection to the problem that sees you through until you find a solution that does work.

So that's the first place I would start. Thinking about problems. And I think a lot of people keep little idea books with startup ideas. I think they'd have a lot more success if they kept little problem books and wrote down notes on the problems that they encounter on a daily basis so that their friends complain about, their family complain about. Another interesting thing to do when you're starting to think about problems is to brainstorm with friends.

This is the perfect time to start thinking about how do you recruit co-founders. And a lot of recruiting co-founders is about having really good brainstorming sessions. Sessions where you talk about a problem, they elaborate on it, and you kind of realize that you trade ideas well and that you can talk to each other well and you can build ideas together. And so I really advise when you're doing this thinking about problem Do it with some friends friends that you might want to create a startup with 1 day Once you find a problem that's interesting enough to start pursuing further The next question I ask myself is why are you uniquely qualified to work on this problem? Now by qualified, I don't mean in the classical resume sense, like, oh, you've had 25 years experience in this area or something like that.

But what I do mean is that, like, is there some angle on the problem that you understand that you don't think others understand? Is there some way of attacking the problem? Is there some perspective on the problem? Is some personal experience for the problem that you have that you don't feel is generally used or understood in other solutions to the problem. In this phase, it's often helpful if you're solving a common problem to look at some of the people who've tried to solve the problem before and look at some of the products that are trying to solve the problem or have failed to solve the problem, just so you can get a basic understanding of what other people thought their unique insight was and whether it was the same or different than yours.

This is kind of your gut check. Hey, is this a right fit for me? The next step is to start thinking about how do you want to build your MVP, your minimum viable product. What's the first product, what's the first solution you're gonna build and release to your users to see if maybe you can try to help them solve this problem? The most important thing to think about your MVP is don't fall in love with it.

Your MVP is most likely not going to solve the problem or is going to solve the problem very poorly. And really it's the first step in the learning process of whether the problem is solvable at all, let alone whether you can solve it. A lot of people fall in love with their product and are not in love with their problem or their customer. I advise the opposite. Be in love with your problem, be in love with the customer, and treat your product in a way that it can change, it can develop, it can improve.

Don't be too in love with your initial product. The most important thing to not fall too in love with the initial product is to release it quickly. Oftentimes an MVP can be built and released in days or weeks. It's not gonna be perfect, it might not be something you're proud of, but it can be the beginning of learning about whether or not you can actually solve the problem. The last thing I would consider once you have an MVP is be very careful who your initial users are.

I actually believe that your initial users should almost be hand-picked. But certainly, you should have a strong opinion about who your initial customer is. And you shouldn't try to solve this problem for someone who, 1, isn't willing to try a startup, or 2, the problem you're trying to solve is not a really important problem in their life. So your goal here with your MVP is not to see how many people want to use your product, is to see whether for any group of people, does this actually solve the problem? For any group of your customers, excuse me, Does this actually solve the problem for any group of your customers?

Excuse me. Does this actually solve the problem that you're trying to solve? And so the best startups actually very heavily filter the people who are able to use the initial product and make sure that they're the right type of initial customer. So those are the steps that I would take from thinking about a problem, to building the first version of the product, to getting feedback on it. That's how I would think about this problem.

Thank you. You

See all Y Combinator transcripts on Youtube

How to Get and Test Startup Ideas - Michael Seibel