A short transcript of Michael Seibel explaining core goals for pre-launch startups: launch quickly (even a bad MVP), acquire initial users, solicit their feedback, and iterate the product rather than pivoting away from the core problem. Emphasizes holding the problem and customer tightly while keeping the solution flexible and improving the product until it truly solves users’ needs.
Chapters
Okay, so the goal of a pre launch startup is extremely simple. Step one, launch quickly. This is something that's been part of the YC ethos from the very beginning and it's been great advice for 10 years and it continues to be great advice. If you can walk away from one thing, from this presentation, it's launch something bad quickly. That's it. Like literally the rest of what I'm going to say is basically going to be re summarized versions of that same thing. The second thing that an early stage startup needs to do is get some initial customers, get anyone using your product. You don't have to have a vision of how you get everyone using it, but just anyone interacting and seeing if they can get value out of the product. You'd be surprised at how many founders journeys end before a single user has actually interacted with a product they've created. It's very, very common. So please get past this step. It's extremely important. The next one is talk to your users, any of them, after you've launched this MVP and get feedback. This is one that's also extremely common mistake because most founders in their heads have an idea of what they want to build and so they kind of have this weird feeling that if I haven't built the full thing yet, getting feedback on the shitty initial thing is kind of useless. Of course it's not going to work. It's not the full thing. The full thing is going to take three years, $10 million, a whole team. So feedback on the little thing is useless. The reality is that in some ways the full thing is this really awesome idea in your head that you should keep in your head, but it should be very, very flexible because it might turn out the full thing that you want to build isn't what your customers want at all. So I have this saying, hold the problem you're solving tightly, hold the customer tightly, hold the solution you're building loosely, and last but most important, iterate. And I like to kind of distinguish between iterating and pivoting. A lot of founders, once they figured out how to build something, fall in love with it. And so if it doesn't work for a certain set of users, they start thinking, well, I wonder what other problems this thing can solve. Well, you know, the screwdriver is not actually good at screwing in anything, but I wonder what other problems it could solve. And they're like, oh, maybe you can use it to cook, maybe you can use it to clean. And it's like, no, like the problem was I need to screw something in. The user was like a mechanic. And if your screwdriver doesn't help the mechanic solve the problem, keep the mechanic. Keep the problem. I need to screw something in. Fix the fucking screwdriver. Like that's the thing that's broken, right? The broken thing is not the mechanic. And. And it's not the fact that they need to screw something in. So iterate. Continue improving on your solution until it actually solves a problem.
