YC CEO: How to Build a Product?
TechFlow Selected TechFlow Selected
YC CEO: How to Build a Product?
Having a technically skilled team is crucial for quickly building an MVP and measuring results.
Navigating Web3 tides with focused insightsCompiled by: TechFlow
Note: This article is included in the TechFlow special series "YC Startup School Chinese Notes" (updated daily), dedicated to collecting and organizing Chinese versions of YC courses. This fourth installment features an online course titled "Building a Product" by YC CEO Michael Seibel.
Experiences from Justin.tv and Twitch
During our company's development, we broke many rules. Fortunately, we survived thanks to our highly capable founding team—Justin, Emmett, and Kyle worked together exceptionally well. What amazed me most was their refusal to back down when facing significant technical challenges.
Secondly, we spent very little money, which gave us ample room for mistakes and experimentation. At the time, we were just a group of 20-somethings living in a two-bedroom apartment costing $2,500 per month. Each of us had only $500 in monthly spending money—technically below minimum wage—but we didn’t care about legalities. Emmett had his own bedroom; Kyle and Justin slept on bunk beds, while I stayed in the living room and sometimes even on the balcony.
Finally, our sense of self (ideology) was deeply intertwined with our startup. We weren't building a startup merely as a "cool" addition to our résumés—we were pursuing something we genuinely wanted to do.
Therefore, I believe that at every stage of the company, even if it seemed like failure was imminent, our entrepreneurial failure felt like personal failure. Giving up was simply not an option—we all shared this internal conviction.
How to Define the Problem Your Startup Needs to Solve?
From early on, I advised Poppy, a YC company founded by Aviv. I noticed some founders talk only about what they're building or how their product works, without clearly identifying the core problem. For certain businesses, this may be acceptable temporarily, but eventually, knowing exactly what problem you’re solving becomes critical.
At Justin.tv, our initial goal was to solve entertainment—specifically, enabling anyone to livestream video content online. If you can't clearly articulate the problem in simple terms, you’ve likely lost your way.
It helps to ask whether you've personally experienced the problem, though it’s not mandatory. Founders often try to solve problems for strangers whose existence they can't confirm. You can't start by solving problems for everyone—you must define a narrow, solvable issue. For example, when Justin.tv launched, we couldn’t support real-time video streaming for everyone—only a subset. Similarly, Poppy offers babysitting services but must clarify specific use cases based on babysitters’ skill sets and assess whether those needs are addressable.
Uber succeeded because there was a large pool of interchangeable drivers with identical skills. Babysitting, however, faces mismatches between supply and demand. When defining the problem, consider your target users and whether the problem is truly solvable.
Who Is Your Customer?
You need to understand both the nature of the problem and who your user is. Many founders want to serve everyone, but not everyone is a target customer. You must identify your ideal first customer—if you can't answer this clearly, you'll lose direction. Talk directly to real customers to learn who they are and how frequently and severely they experience the problem. To judge whether you have a good product, ask: Is it easy to use yet hard to give up? Also, avoid talking to the wrong customers and find effective ways to reach your true target audience.
Why Is It Important to Understand Target Users and Problem Frequency?
In startup creation, many focus on solutions rather than understanding their users and the frequency of the problem. For instance, many car shopping websites are built for sellers, not buyers. You need to identify who gains the most value from your product and help them solve recurring issues. Successful products live on the home screen—they’re intuitive and become extensions of the user. In contrast, apps buried on the third page or inside folders are rarely used; if users need them regularly, such apps likely lack strong business potential.
Many founders assume they have a great idea without considering how frequent or intense the problem is. But if you’re solving a low-frequency or low-intensity problem, you’ll struggle to retain interest. Instead, tackle high-frequency, high-intensity problems—ones people are willing to pay to resolve.
For example, Uber solved the urgent need for fast transportation—a serious, high-frequency problem. Rather than targeting users without problems, focus on those who truly suffer from them and are willing to pay for a solution.
When pricing your product, it’s generally better to charge from the beginning—or start higher—rather than offering free access. Before launching a free product, conduct user research to identify those facing high-intensity problems, not just hobbyists or indifferent users.
Talking to the wrong customers can create real costs and management headaches. Some companies get hijacked by problematic customers who abuse the system and harm the business. Therefore, engage only with users who genuinely need your solution—this greatly increases your chances of success.
What Should B2B Companies Watch Out for When Finding Customers?
I recently saw two B2B startups—one in the U.S., where finding customers is easier (e.g., sending emails to 1,000 prospects via LinkedIn); the other in China, where email isn’t effective, so new outreach methods are needed. The key point: if customers are hard to find, plan ahead. Don’t expect them to come to you. Some founders build products for hypothetical users who can’t actually use them—that logic doesn’t work.
Does Your MVP Actually Solve the Problem You Intend to Solve?
Building an MVP often leads to confusion and missteps. After starting development and talking to users, you might launch something—only to realize it fails to deliver on your promise or lacks essential functionality. That’s why taking preparatory steps before building is helpful: it forces introspection—can you actually solve the problem?
These steps also accelerate MVP development. The longer it takes to build an MVP, the more likely you are to face issues or customer drift. If you commit to building within two weeks, you’re more likely to finish quickly and ensure you’re solving a real customer problem.
By the way, the best way to test your product is to let customers use it. This is non-negotiable. Many think of their product like a painting—an artwork to be admired—even if only one person appreciates it. But products aren’t art. If users find no value in it, then by definition, it has no value—and you’ve wasted your time building it.
Many wish to be artists, but in startups, that mindset is merciless. Ironically, after people like Steve Jobs are described as magical artists, we forget: if only one person bought an iPhone, it would be considered a failure. Art can be appreciated by just one person—or none. That’s not how successful products are defined. So always check whether your product truly solves a problem.
Can your MVP solve the problem? This question may make you uncomfortable—the answer could be “no.” Many founders face this dilemma.
Some know their MVP doesn’t work but avoid discussing it, hoping others won’t notice. This is common.
But first, clarify who your target customer is—a source of confusion for many founders. Many instinctively pursue the hardest customers first, but I suggest seeking the most eager ones—the most desperate.
Why Seek the Most Desperate Customers?
When I talk to founders, I push them toward the most desperate customers and urge direct, simple engagement. If your product is a simple software tool priced at $1,000/month, don’t enter a six-month partnership with a stable enterprise.
In early-stage enterprise sales, seek desperate customers—they need your product and will invest time to understand it. Targeting indifferent customers often leads to mistakes. Ask yourself: whose business would collapse without your product? Who can’t go to work or care for their kids?
Once you find these people, talk to them and shape your product around their needs. Don’t rely on advice from investors or friends—they likely don’t face your problem.
Also, identifying bad customers is crucial. These users complain constantly, make unrealistic demands, or try to exploit your product without paying.
Why Is Setting a Metric Important?
Finally, setting a metric early is vital. It’s one of the top sources of new product ideas and insights into usage. Google Analytics isn’t sufficient—it can’t capture detailed user behavior. You need an event-based analytics tool like Mixpanel. Without such tools, you cannot mature as a product builder. It’s a prerequisite for success.
For technical teams, implementing Mixpanel is easy. For non-technical teams, it’s nearly impossible. This highlights one advantage of having a strong tech team: you actually know what users are doing. Without it, you miss most of what matters. Teaching your employees and co-founders to use Mixpanel is essential—it should be a tool everyone in the company knows how to use.
To start with Mixpanel, pick 5 to 10 simple metrics. For Instagram, examples include opening the app, creating an account, taking a photo, applying filters, sharing a photo, etc. Name these metrics consistently—you may track hundreds or even thousands later. Treat measurement as part of product specs and consider it during planning. Otherwise, you’re flying blind.
Product Development Cycle
Justin.tv faced challenges involving three Yale graduates and one MIT graduate. At Yale, debate is a prized skill, so the three became dominant debaters. This prolonged the development cycle until Kyle changed his sleep schedule to avoid pointless arguments.
In Justin.tv’s early days, a classic debate lasted about three months—over the website’s background color. The site had only one page. Justin wanted black; another team member proposed wood grain. After three months, they compromised with five background options. Looking back, they felt foolish—having failed at proper product development cycles for nearly five years before learning how.
They made many early mistakes, the worst being long release cycles. Releasing once every three months was disastrous for a web product. Another issue: no decisions or specifications were documented in product meetings. By the first month of development, team members were already building slightly different versions, wasting time. After two months, much time and productivity were lost, yet less than a third of goals were achieved, and enthusiasm waned.
Eventually, they abandoned the original plan and restarted. During this process, if someone proposed a good, new, or interesting idea, they’d hear: “We’re already working on something else—your idea has no value. Write it down somewhere.” Their workflow was clearly immature.
Our work should be goal-oriented, planned, and tracked—not like before, spending three months with nothing to show. If our product team still centers on debates, lacks specs, and has long cycles, we’ll keep failing.
Most of Justin.tv’s past product decisions were terrible because we lacked proper processes and accurate metrics. We need to establish tracking numbers reflecting company performance—like revenue or user return frequency—so everyone knows the goal.
In product meetings, discuss how to improve that metric and ensure full participation. Only then can we boost efficiency and succeed.
How Did SocialCam Gather Ideas?
SocialCam set DAU (Daily Active Users) as its top KPI, recognizing that new users, retained users, and new content creation contributed to DAU growth.
To gather ideas, we held open brainstorming sessions. True brainstorming meant writing all ideas on the board so everyone could review metrics and assess feasibility. Whether new features, iterations, bug fixes, maintenance, or tests—everyone participated. We categorized ideas as easy, medium, or hard to better manage development workload.
The CEO’s role isn’t to shoot down ideas but to empower employees, removing fear and encouraging confidence to propose more. We discussed all three categories fully on the board, then classified each idea accordingly. “Hard” meant requiring an engineer’s full attention for days; “medium,” one to two days; “easy,” completable multiple times in a day. Our cross-functional team wasn’t all coders, but through this process, they learned to distinguish ease of implementation and established evaluation standards.
We found easy ideas got built faster, and most complex ideas could be simplified. This process educated the entire team on what’s easy, medium, or hard, providing objective criteria and reducing debates and personal biases. Ultimately, we selected the ideas with the biggest impact on KPIs and sorted them into difficulty tiers. Through this, everyone saw their ideas realized and learned how to simplify or scale them.
Next came writing specs—a step where everyone tends to slip up. Meetings could last four hours—something nobody enjoys. To ensure clarity, we specified technical terms precisely—e.g., “add video filters to SocialCam” or “enable chat between users on Justin.tv.” Once clear, tasks could be assigned.
At SocialCam, we ran biweekly cycles because App Store submissions took longer. For pure web products, weekly cycles are feasible. Though long meetings are unpleasant, this was our only meeting. So we had to make them bearable. If I had a good idea, I’d stay quiet for those two weeks—it might derail everything. We remembered to repeat the process every two weeks.
Pivot vs. Iterate
Pivoting and iterating are topics many YC companies and founders discuss. They often say: “Our thing isn’t working—after two months, it’s time to rethink.” That makes me think: you’re building a new product for customers who may never have used the old one.
You only know this somewhat, or perhaps only from personal experience. But what makes you think two months is enough to know if you’ve found anything? What impressive product was built in just two months? If you think solving problems takes only two years, you’re mistaken.
- A pivot, to me, means changing either the customer or the problem. This should be rare—almost never happens. Often, it means you should start a new company.
- An iteration means changing the solution. You have the right customer and the right problem, but your MVP is flawed or ineffective—so you need a new solution.
Sometimes, your MVP is great but fails to solve the problem—so you need a new solution. Eventually, you show it to customers, but they don’t want to use it—even if they have a burning need. Then you need a new solution.
I often see the opposite: people start with a solution, and when customers reject it, they search for random new users or entirely different problems. They shop their solution around because they believe the solution itself is the genius part.
The real creativity lies in identifying unseen problems and crafting solutions—this kind of creativity deserves study.
Facebook wasn’t the first social network, nor was Google the first search engine. But they understood problems previous players missed and executed better—thus building massive companies. Their creativity wasn’t: “We built this cool thing—let’s see who wants it.”
How to Avoid Pretending to Be Steve Jobs in Your Company?
Many think Steve Jobs is someone to emulate, but their perception is wrong. They imagine he conjured perfect ideas in his mind and brought them into reality. Interestingly, I think people view the iPhone as a perfect example. But what they see today is their current iPhone.
The first iPhone was far from perfect—no 3G, poor battery life, fragile screen, no App Store. Everyone forgets that version. If you pretend to be Steve Jobs in your company, you might adopt an arrogant attitude—believing your will alone matters, ignoring customers and others.
But that only makes you a fake Steve Jobs. The real Steve Jobs launched a revolutionary MVP and improved it yearly until reaching perfection.
He repeatedly engaged customers, iterated, and ensured products met market needs. In contrast, those who merely fantasize and create art are just pretending to be Steve Jobs.
Therefore, avoid impersonating Steve Jobs. Instead, leverage your own strengths to drive company growth.
How to Communicate Effectively With Users to Make Your Product More Successful?
Both Justin.tv and Twitch had strong technical teams confident in their product, yet maintained low burn rates. Gamers began streaming on Justin.tv almost from day one, accounting for 20% of traffic at any given time. Even without special features built for them, they kept using the product.
When the company started developing Twitch, one of the most important changes was engaging directly with the gaming community. Gamers felt the company was now building for them and began telling their friends.
For startups, communicating effectively with users is crucial. By talking to users and building what they want, you make your product more successful. When users get what they need—even if features are basic—they fall in love with your product. In Justin.tv’s history, dealing with the right customers from the start transformed the company from nothing to ~$24 million in value, then to $1 billion over the next three years. Without a strong tech team, low costs, or ego getting in the way, such success would never have happened.
If Your Final Product Idea Is Free, Should You Offer It for Free?
If your users were never intended to be charged, then yes—offer it for free.
But if you plan to monetize eventually, starting to charge early is extremely helpful. It reveals willingness to pay and allows timely strategy adjustments.
If their business depends on your service, charging early is especially beneficial. In such cases, begin charging as soon as possible.
In my metrics, I prioritize these considerations. While every situation has nuances, at a high level, ask: Do you plan to charge? And when should you start?
If you never intend to charge users, consider ad-based monetization. This is typical when offering free services without direct user fees—ads generate revenue.
If you don’t want ad revenue, you should probably start charging users instead.
If Your KPI Is Revenue, But the Number Is Zero, Should You Still Track It as the Top KPI?
Short answer: Yes. You should track revenue as your primary KPI.
But let me elaborate. As I told SocialCam, key metrics should be actionable. DAU was our top metric, driven by new content, new users, retention, and other measurable factors.
If you’re a sales-driven business, your top KPI is revenue. Even if it’s zero, take action to change it.
But also ask: besides revenue, what three other metrics reflect your business health? Examples: number of calls this week, contracts signed, new hires. These influence revenue—they matter too.
These numbers keep you motivated, but your headline KPI must never be meaningless.
As a hardware company, before launching our product, our users and target market encounter five to nine hundred product-related questions daily. Despite financial pressure, we want to offer pre-sales support to promote market entry. Any advice?
Do we provide pre-sale tips? I’d say yes—there’s plenty of pre-sale advice we can give.
One of my best suggestions: email previous founders and ask what they did during pre-sales.
The biggest mistake in pre-sales is discounting. Hardware makers often misunderstand pricing and hesitate to sell at a loss. But this pricing strategy can kill your company.
So we must avoid that.
What’s the Hardest Part of Slow Burn?
When we were young, living like college students wasn’t hard. Now it’s tougher. I have a child, wife, apartment, and car—more responsibilities and challenges.
The hardest part of slow burn is adjusting if you’re already used to a comfortable lifestyle. Also, if you’re still working, haven’t upgraded your lifestyle, are young, and earn well at a high-paying job—this is a prime time to prepare for entrepreneurship.
But if you have a mortgage, car loan, or vacation expenses, the challenge grows. Many can’t go back, missing the chance to start independently.
From Beta to Early MVP
From beta to early MVP, you need people using your product. If no one uses it, push harder to get users.
Once users start using it, labels like beta, pre-launch, alpha don’t matter.
What matters is whether you’re truly solving user problems. Most YC companies launch multiple versions—this progression isn’t that significant.
Ultimately, the key is getting people to use your product—call it whatever you want.
How to Decide What to Build Next?
There’s usually no single correct answer. You need a rapid iteration process to test different approaches and discover what works. Having a technically skilled team is crucial for quickly building MVPs and measuring results.
Over the next three months, small actions won’t achieve long-term vision—you need imagination spanning ten years. To deliver better service, you need a process of rapid iteration that keeps only what’s useful.
At Justin.tv, we fell into the trap of “perfectionism”—spending too long building perfect products, which led to a death spiral.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
