Michael Seibel - Building Product

**TL;DR:** Michael Seibel’s YC lecture covers the core method of building product: first clearly define the problem, narrow the scope, validate solvability, then test whether the need is real through customer frequency, intensity, and willingness to pay. He also emphasizes that a team with strong technical skills, low costs, and self-esteem tied to the startup is critical for survival. --- ## Introduction Michael Seibel, CEO of Y Combinator and former co-founder of Justin.tv, Twitch, and Socialcam, dives deep into a framework for building product in this talk. He starts by explaining the three pillars that kept his own startup alive, then systematically walks through the "problem-customer-solution" triangle using case studies (both his own and YC company Poppy). --- ## What Makes a Founding Team Succeed During the different phases of Justin.tv and Twitch, we broke almost every rule we’re about to cover. The only reason we survived is these three things — and you need all of them. ### A Technically Strong Team The founders — Justin, Emmett, and Kyle — were excellent collaborators who never shied away from any technical challenge. Seibel believes he wouldn’t be standing here today without the privilege of working with them. Many founders and companies don’t truly grasp this — it was our technical ability that let us break so many rules. ### Low-Cost Operations We were 21, 22, 22, and 23 years old, moved out, and lived in a two-bedroom apartment for $2,500 a month. Each of us had only $500 per month as pocket money, strictly below minimum wage (illegal, but nobody cared). Emmett had one bedroom, Kyle and Justin shared bunk beds, I slept on the couch, sometimes on the balcony. This extreme low cost gave us enormous room for error — we could make mistakes without it being fatal. ### Self-Esteem Tied to the Startup We weren’t starting a company to pad our résumés — this was pretty much the only thing we were doing with our lives at the time. When the company was failing, it felt like failing at life itself — if you’re only doing one thing and you can’t make it work, you fail at life. That internal feeling made quitting simply unimaginable. > If you’re missing any one of these, the company dies. This isn’t a “pick two and you’re fine” situation — you need all three, or it’s game over. --- ## Core of Building Product: Define the Problem “What problem do you solve?” is the starting point for every conversation. Founders often talk only about their idea, what they’re building, or the product features — but they avoid the “why” and what problem they expect to solve. ### State the Problem Clearly in One Sentence If someone asks what problem you solve and you write a long paragraph, you’re doing it wrong. You need to be able to say it in two sentences (or even one). If you can’t articulate the problem, you can’t judge whether you’ve solved it. ### Have You Experienced This Problem Yourself? Not always necessary, but definitely helpful. Many founders try to solve problems for people they’ve never met or talked to — they don’t even know if that person exists. All else being equal, having experienced the problem yourself is a strong signal. ### Narrow the Problem Definition In the beginning, you can’t solve the problem for everyone who has it. Justin.tv couldn’t let anyone stream video right away — you needed a laptop, fast internet, a webcam, etc. The problem went from “we want to provide live video for everyone” to “who can we help first?” Founders often want to skip this step and talk about the grand vision of “curing cancer” without asking, “What can we solve right now to get the first sign that our solution works?” ### Is the Problem Solvable? (Poppy Example) Poppy was an “Uber for baby sitters.” Parents need sitters for all sorts of reasons: full-time weekday care, emergency medical situations, schedule mishaps, needing care for infants or teenagers, etc. If you just say “help people find sitters,” you can’t figure out which scenario to prioritize. Once narrowed down to “help parents find sitters for their infants,” you can ask: Is this problem solvable? In practice, getting parents to trust a complete stranger to watch their baby is extremely hard — you need to be really good at it. Uber works because the pool of capable drivers has generic, interchangeable skills. But people who can watch an infant and make a parent feel safe often already have a steady nanny job, get paid well, and don’t want to take on sporadic gigs. So the supply side falls apart — the problem may actually be unsolvable. > You need to think in real time: Who do I want to talk to first? Then keep asking yourself: Is it solvable? A lot of founders don’t want to think about this because it’s hard — and it’s even harder to accept, “Oh, I might not be able to solve that problem, I need to switch to a different one.” --- ## Understanding the Customer You don’t truly understand the problem until you understand who you’re solving it for. ### Identify Who Your First Customer Is Saying “everyone is a customer” is meaningless. Almost every product used by everyone today once had a period where almost nobody used it. The creator must figure out, “Who is my ideal first customer?” Without that answer, you don’t know who to talk to to confirm whether the problem exists, and you don’t know who the product is for. > Don’t be the founder who builds a product like they’re writing creative fiction — a pure product of their own brain, with no outside interaction, not even a problem they’ve experienced. ### Problem Frequency and Intensity Many people pick a problem without understanding frequency. Example: car shopping websites — consumers buy a car once every seven years on average. That’s extremely low frequency. Even if you serve a buyer perfectly, they won’t come back for seven years. The real customers of a car shopping site are dealers: they have a daily need to hit their sales numbers. So by analyzing, you need to find out “who gets the most value from the product” and focus on high‑frequency, high‑intensity customers. Reference chart: the sweet spot is **high intensity + relatively high frequency**. Uber: when you need to get somewhere (work, hospital, pick up a kid), the problem is intense enough that you might spend $20,000 buying a car to solve it; frequency-wise, you need to move distances beyond walking range multiple times a day. Even though the taxi market wasn’t huge before, the customer’s problem itself was intense and frequent. ### Are They Willing to Pay? Many founders think they have to give it away for free to get users. But a better signal is to make it slightly harder for users — like asking them to pay $100 — and see if they still use it. If the problem is strong, users will feel it’s worth it; if not, free users will be a flood of “trying it out” people who don’t really have the problem, and their feedback will mislead product direction. > Starting with a higher price or a fee is almost always better than free. If you must be free, deliberately seek out users who use the product frequently in real-world production, not hobbyists. Talking to the wrong customers can be very dangerous — you can even get “hijacked” by bad customers, especially when there are real costs involved (like Poppy needing to recruit and manage sitters — if customers exploit the system, the consequences are severe). --- ## Summary Building product can’t rely on inspiration alone. You need to: define a clear, narrow problem; confirm your own experience; validate solvability; lock onto high‑frequency, high‑intensity customers; and use willingness to pay as a litmus test for real demand. And remember, a technically strong team, ultra‑low operating costs, and self‑esteem tied to the company are the foundation that lets you survive the trial and error. **Source:** Michael Seibel – Building Product (YouTube) (https://www.youtube.com/watch?v=C27RVio2rOs)