Y Combinator CEO Michael Seibel provides concrete guidelines on what problems to solve, who your customers should be, and how to structure your product development cycle for a successful startup. Drawing on his own founding experience (Justin.tv, Twitch) and countless YC companies, he emphasizes that the essence of product development isn't crafting a perfect work of art, but solving customers' desperate problems and continuously iterating. His practical advice on setting metrics and running efficient development cycles is essential for founders looking to reduce early-stage trial and error.

1. Three Conditions for Survival and the Justin.tv Lesson

Michael opens by sharing the story of Justin.tv (which later became Twitch), which he co-founded. He identifies three critical reasons they survived despite breaking many rules.

First, they had a technically exceptional founding team. They weren't afraid of any technical challenge. Second, they barely spent any money. In their early twenties, they shared a two-bedroom apartment and lived on minimal expenses, which gave them room to recover from mistakes. Third, their egos were completely tied to the startup.

"We didn't do this startup to add a nice line to our resumes. It was the only thing we'd ever accomplished on our own. So when the company was on the verge of failing, it felt like our entire lives were failing -- like getting an F. That desperation is what kept us from giving up."

He emphasizes that without any one of these three elements, the company would have failed. Now, on to the real topic: Product.

2. What Problem Are You Solving?

Many founders start their investor pitches by describing their idea or product features rather than the problem. But Michael says the first step is to clearly articulate "What is the problem you're solving?"

Questions for Defining the Problem

Michael advises founders to understand the essence of their problem through these questions:

1. Can you explain the problem in one sentence? If you need an entire essay to explain it, you don't yet understand the problem well enough.
2. Have you personally experienced this problem? When solving a problem you've experienced yourself, you have the certainty of at least one confirmed customer: yourself.
3. Have you defined the problem narrowly? You can't build "live broadcasting for everyone" from day one. In the early stages, you need to narrow down exactly who you can help immediately.
4. Is the problem solvable? For example, Poppy, a babysitter matching service, found that the problem of caring for newborns had too high a trust barrier for parents to overcome.

"Many founders want to talk about huge problems like 'curing cancer.' But what matters is, 'Whose problem can we solve right now?'"

3. Who Is Your Customer?

Knowing the problem means knowing who the customer is. "Everyone is our customer" is the worst answer. Even Facebook and Google, which everyone uses today, started with a very specific, narrow customer base.

Problem Frequency and Intensity

To validate that you understand your customer, analyze the frequency and intensity of the problem they face.

• Frequency: How often does the user encounter this problem?
• Intensity: How painful or important is this problem?

Michael uses car-buying websites as an example. The average person buys a car once every seven years -- very low frequency. That's why most car sites are built for dealers (sellers) who need to sell cars every day.

"Think about the apps you use daily. Most of them are on your phone's home screen. The ones you rarely use are buried deep in folders. You need to solve problems with high frequency and high intensity to build a good business."

Consider Uber: getting around (hailing a taxi) happens very frequently, and the intensity is high because you can't afford to be late. On the other hand, problems with low frequency and low intensity make it extremely hard to attract customers.

Free vs. Paid

Many founders think, "Let's make it free first and build a user base." But Michael says charging a price is far more useful for product validation.

"To find out if your product is good, put up a paywall. If people still use it, you're solving a truly desperate problem. Going free contaminates your data with 'fake customers' who are just curious."

4. MVP and Finding Early Customers

Does the MVP Actually Solve the Problem?

In building an MVP (Minimum Viable Product), teams often drift away from the original problem. They finish building and then realize, "Wait, this doesn't solve that problem." That's why development periods should be as short as possible (2 weeks recommended).

Also, founders must not become "artists." A product is not a painting for admiration.

"A product is not a work of art. If users don't find it useful, it's just a waste of time. If nobody used the iPhone, Steve Jobs would have been remembered as a failure."

Who Should You Target First? (Answer: Desperate People!)

Many founders assume, "If we can satisfy the pickiest customers, the rest will be easy." But an MVP is inherently an incomplete product. The people willing to use such an imperfect product are the most desperate customers.

• Don't ask your friends: Friends and investors will either give fake praise to avoid hurting your feelings or provide irrelevant feedback.
• Fire bad customers: Michael's co-founder Justin actually "fired" a customer who kept making unreasonable demands.

  "Steve, Reddit's CEO, was a friend of mine. He was reluctantly using my app (Socialcam). When he heard we sold the company, the first thing he said was, 'Thank God, I can finally delete this app.' Friends don't give honest feedback."

5. Setting Metrics and the Development Cycle

Don't Use Google Analytics

Michael emphasizes that product teams should use event-based analytics tools like Mixpanel or Amplitude instead of Google Analytics.

• Google Analytics: Tells you who visited and how many pageviews you got.
• Event-based tools: Track which buttons users clicked and what actions they took.

Start by tracking only 5-10 core metrics. Too many become unmanageable. And measurement must be included in the product spec from the start -- not added later.

The Product Development Cycle

In the early days of Justin.tv, their development cycle was a mess. They deployed every 3 months, never documented specs, just talked about them verbally, and wasted time building different things. Michael introduces the ideal development cycle that fixed this:

1. Set goals (KPIs): Define clear targets like revenue or active users.
2. Brainstorm: Get the whole team together for ideas. Write every idea on the whiteboard so everyone feels respected.
3. Difficulty classification (Easy / Medium / Hard): Developers assess the implementation difficulty of each idea. This also helps non-technical founders learn about technical costs.
4. Prioritize: Select one high-impact "Hard" idea and several "Easy/Medium" ideas.
5. Write specs: This is the most critical step. Document specifically what you're building.
6. Sprint: Focus exclusively on development for 2 weeks (or 1 week) with no meetings.

   "As a non-coding founder, my main job during this period was to shut up. Even when a new idea popped into my head, I had to wait until the next meeting in 2 weeks. That's how you keep the team stable."

6. Pivoting and the Fake Steve Jobs

Pivot vs. Iterate

Many founders ask, "We tried for 2 weeks and it didn't work. Should we pivot?" Michael says that's crazy.

• Pivot: Changing your customer or the problem entirely. (Rare)
• Iterate: Keeping the customer and problem the same, but changing the solution. (Most cases)

When a product isn't selling, it's most likely because the solution is wrong. You need to persistently iterate on the solution.

Don't Be a Fake Steve Jobs

People mistake Steve Jobs for "an artist who conjured perfect products from his mind." But the real Steve Jobs was someone who iterated relentlessly.

"The fake Steve Jobs stubbornly says, 'Don't listen to customers, build what I want.' But remember the real Steve Jobs's first iPhone? No 3G, no App Store, no copy/paste -- it was a mess. But he iterated brilliantly every year to create today's iPhone."

Closing: Talk to Your Users

Michael closes with the pivotal moment that led to Twitch's success. During the Justin.tv era, 20% of total traffic came from gaming streams, but the company ignored them. Then at some point, they started talking to those users.

What gamers wanted wasn't grandiose -- "reduce the lag," "increase the resolution," that kind of thing. When the company listened and built those features, gamers were moved: "Wow, these people are building something for us!" -- and they started bringing their friends.

"Have you ever suggested a feature to Mark Zuckerberg and had it implemented? Probably not. The greatest superpower a startup can have is talking directly to users and building what they want. When you do that, users will love you."

In conclusion:

1. Define your problem narrowly and clearly.
2. Find desperate customers who need the product right now.
3. Stop arguing and start shipping in short cycles while measuring the data.
4. And above all, talk to your users. That is the only path to building a product people actually want.