Michael Seibel - How to Plan an MVP

### TL;DR An MVP is the simplest product you can give to your first target users to test whether you can create any value for them. Ship something crappy fast, then iterate. ## What is an MVP? MVP stands for "Minimum Viable Product." Michael Seibel, who runs Y Combinator's accelerator and previously founded two YC startups, emphasizes that an MVP should be extremely simple – just something you can hand to your first target users to test whether you can create any value for them. That's it. Before building an MVP, it's best to talk to some users. If you are the user yourself, it's even easier to judge whether the product works. The way to get your first users is to talk to people you know have that problem; if you are the user, it's even simpler. ## The goals of a startup before launch ### 1. Ship fast This has been YC's philosophy for a decade: ship something crappy fast. If you only learn one thing from this talk, this is it. ### 2. Get some initial customers Anyone starting to use your product counts. You don't need everyone to use it from the start, just that some people get value from it. Many founders' journeys end before the first user actually uses the product – this is a very common mistake. ### 3. Talk to users and get feedback Most founders have a complete idea in their head, so they think getting feedback from a crappy initial version is useless. But the reality is that the complete version in your head might not be what customers want at all. Remember: hold tightly to the problem you're solving and your customers, but be flexible about the solution. ### 4. Iterate (not pivot) Once many founders learn how to build something, they fall in love with it. If it doesn't work for one type of user, they think "what else could this thing solve?" It's like a screwdriver that's bad at screwing things, and you try to use it for cooking. The right approach: keep your users and problem (e.g., "I need to screw something"), then fix the damn screwdriver. ## How minimal should an MVP be? Most people's MVP should be built quickly in a few weeks, not months. Extremely limited in features, focused only on a small initial set of users and their highest priority problem. Have a vision for everyone, but make the MVP very small – it's just a starting point for iteration. ### Classic examples - **Airbnb (2008)**: The first version had no payments – users had to exchange cash with the host in person; no map view; code was written part-time by Nate. - **Twitch (then called Justin TV)**: Only one channel (Justin), very low video resolution, no video games (unless Justin himself played). - **Stripe (initially called slashdev/payments)**: No bank partnership agreements, very few features, and the founders even went to customer offices in person to help integrate payments. These companies are now worth billions of dollars, but all started with extremely simple MVPs. ## When might you need a "heavy MVP"? If you're in a heavily regulated industry (insurance, banking), hard tech (rockets, biotech), moonshot projects, etc., you might not be able to build a product in a few weeks. In that case, your MVP could start as a simple website explaining what you do. Having something to reference when talking to people is very helpful. This website can be built in a few days, which is actually faster than a "lean MVP". ## Misconceptions about "launch" Many founders think that launching a startup should be like a big company launch with lots of media attention. But in reality, no one remembers the launch dates of Google, Facebook, or Twitter. The launch itself is not special. Define "launch" as "getting any customer," and postpone "media launch." Getting customers as early as possible is more important than anything. It's hard to learn when customers have no product to play with. All research is good, but only by putting something in front of people can you know if it works. ## Tips for building an MVP quickly 1. **Time-box the spec**: If you plan to launch in three weeks, only put features on the spec that you can build in three weeks. 2. **Write down your spec**: Many people never write it down, so they easily change direction before launch. Writing it down keeps you honest. 3. **Cut the spec**: A week into the sprint, if you find you've added too much, ruthlessly cut out the unimportant, or even the important. The goal is to ship something first. 4. **Don't fall in love with your MVP**: Falling in love with a first draft is dangerous. The final form of all successful products is different from the initial vision. Your MVP's importance is often akin to a first-grade essay – just the first step of the journey. --- Source: Michael Seibel - How to Plan an MVP (https://www.youtube.com/watch?v=1hHMwLxN6EM)