How to Get and Test Startup Ideas - Michael Seibel

There's a common misconception that your idea has to be great in order start a company, and the first thing I want to do is destroy that misconception. Personally, I was one of the cofounders 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. 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 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 it a problem that my friends have? Is it a problem my family has? Is it a problem that exists through the work? Is it a problem that's in my community?

Oftentimes, having a personal connection to the problem is really helpful for two reasons. One, you can tell whether this solution is even within the ballpark of solving the problem because you've got some connection with it. And, when you're feeling discouraged and the solutions that you're building are not 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. I think a lot of people keep little idea books with start-up 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 or that their friends complain about, their family complains 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: How do you recruit co-founders? 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; you can build ideas together.

So, I really advise when you're doing this, thinking about problems, do it with some friends—friends that you might want to create a start-up with one 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, if I 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: 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 there some personal experience with the problem that you have that you don't feel is generally used or understood in other solutions to the problem?

In this case, it's often helpful if you're solving a common problem to look at some of the people who 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 going to 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 cause. 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 going to 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 to be very careful here. 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, one, isn't willing to try a start-up, or two, 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; it's 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 that you're trying to solve?

And so, the best start-ups 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 problems to building the first version, apart from getting feedback on it. That's how I would think about this problem. Thank you.