Michael Seibel - Building Product

Founder Mindset & Early Survival Factors (Justin.TV/Twitch Case Study)

• Michael Seibel identifies three critical factors that enabled Justin.TV and Twitch to survive despite breaking numerous product rules:
  • Technical Team Capability: The founding team (Justin Kan, Emmett Shear, Kyle Vogt) was extremely technical and un intimidated by technical challenges, allowing the company to execute solutions others could not.
  • Extreme Cost Control: The team lived in a two-bedroom apartment ($2,500/month) with minimal stipends ($500/month per founder), effectively below minimum wage, which provided a runway to fail and recover.
  • Ego Dependency: The founders' egos were entirely tied to the startup's success; failure was perceived as a personal life failure, creating an internal barrier against quitting.
  • Interdependency: Seibel notes that removing any one of these three factors would have likely resulted in the company's death.

Defining the Problem

• Clarity Requirement: Founders must be able to state the problem being solved in one to two sentences; if the answer is an "essay," the problem is not well-defined.
• Personal Experience: Founders who have personally experienced the problem they are solving provide a strong initial signal of validity.
• Narrowing the Scope: Startups cannot solve "mega problems" (e.g., "curing cancer" or "global childcare") immediately; they must address a specific, narrow use case first (e.g., infant babysitting specifically, not general babysitting).
• Solvability Assessment: Founders must validate if the problem is actually solvable with available supply; for example, on-demand infant babysitting failed at Poppy because the skill required for infant care contradicts the "replaceable labor" model required for rapid scaling.
• Measurement of Success: If the problem is well-defined (e.g., "can anyone broadcast live?"), success is easily measurable via user adoption metrics.

Customer Definition & Acquisition

• Targeting "Everyone" is a Failure: Every successful mass-market product (e.g., Facebook, Google) started with a specific, non-everyone user base.
• Frequency Analysis: Problems that occur infrequently (e.g., car buying, occurring once every seven years) are difficult to sustain as businesses unless the customer is the seller (dealerships) rather than the buyer.
• Intensity Analysis: High-intensity problems (e.g., needing a ride to work or the hospital) paired with high frequency create viable business models, whereas low-intensity/low-frequency problems struggle to generate interest.
• Willingness to Pay: Starting with a price is superior to starting free; charging a high price filters for users with intense problems and prevents "hobbyist" or "bad" customer acquisition that skews product feedback.
• Acquisition Channels: Founders must account for the ease of reaching customers; a product may be viable but fail if the channel to reach the specific customer (e.g., email in China for B2B) is blocked or nonexistent.
• Avoiding "Bad" Customers: Founders must identify and fire customers who exploit the system (e.g., unrealistic expectations, constant complaints) even if they pay, as they can hijack the product's direction.

MVP Development & Product Strategy

• Definition of MVP: The MVP must actually solve the defined problem; if it does not, it is a failure of product definition, not just execution.
• Speed to Market: Building an MVP slowly increases the risk of "product drift" and "customer drift"; two-week build cycles are recommended for web products to maintain focus.
• Art vs. Utility: Products are not art; they require utility for a broad user base to be successful, unlike art which only needs to be appreciated by one.
• Customer Selection for Beta: Startups should target the "most desperate" customers first (those who cannot function without the solution) rather than "impressive" or easy customers; desperate users will tolerate a "bad" product to solve their pain.
• Feedback Sources: Founders should explicitly avoid seeking feedback from friends, family, or investors, as they typically lack the specific problem or have a conflict of interest.
• Iterate vs. Pivot:
  • Pivot: Changing the customer or the problem; this is rare and often requires starting a new company.
  • Iterate: Changing the solution for the same customer and same problem; this is the standard path and can take years.
  • Timeline Expectation: Reaching product-market fit often takes a two-year process; declaring a pivot after two months is premature.

Metrics & Measurement Infrastructure

• Primary KPI: Every company must track one top-line metric: Revenue (if charging) or Usage (e.g., DAU, if free).
• Tooling: Google Analytics is insufficient for product metrics; startups must use event-based analytics (e.g., Mixpanel, Amplitude, Heap) to track specific user actions (clicks, screen transitions, cart abandonment).
• Implementation: Measurement specs must be written with the product release, not added later; a technical team is highly advantageous for implementing these tracking systems.
• Metric Selection: Startups should track 5–10 simple stats relevant to the core value proposition (e.g., "open app," "take photo," "share photo") and avoid over-tracking initially.
• Naming Conventions: Stats must be named consistently and clearly to ensure all employees, not just engineers, can interpret the data.

Product Development Cycle (The "Easy/Medium/Hard" Model)

• Bad Cycle Symptoms: Long release cycles (e.g., 3 months), lack of written specs, and relying on verbal arguments lead to wasted effort and "sunk cost" features.
• Recommended Cycle: A two-week cycle with a single, dedicated meeting where all requirements are written into a spec before development begins.
• Idea Prioritization Framework:
  • Brainstorming: Collect all ideas openly without judgment.
  • Categorization: Split ideas into "New Features," "Bug Fixes," and "A/B Tests."
  • Effort Estimation: Classify items as Easy (multiple per day), Medium (1-2 days), or Hard (full cycle).
  • Selection Logic: Prioritize "Hard" items that impact the KPI most, followed by Medium and Easy items; this removes ego from decision-making.
• Meeting Cadence: This is the only meeting allowed during the cycle; no changes should be made to the spec during the two weeks, even for "burning ideas," to prevent chaos.
• Team Composition: Technical teams are critical for accurately estimating effort and implementing measurement; non-technical teams struggle with these constraints.

Customer Interaction & "Fake" vs. "Real" Jobs

• Real Steve Jobs vs. Fake Steve Jobs: "Fake" Jobs claims to dream perfect products; "Real" Jobs released a flawed first iPhone (no 3G, no App Store) and iterated relentlessly based on user feedback.
• The Twitch Turnaround: Twitch succeeded only after ignoring gamers for five years, realizing the value of the "20% traffic" segment, and beginning to listen to their specific complaints (e.g., lag).
• Startup Advantage: Unlike large tech companies, startups can talk to passionate users, implement specific requests (even mundane ones like "chat on the right"), and build instant loyalty.
• Pre-Sales & Hardware: Pre-selling hardware is viable but risky; founders must avoid underpricing to cover costs, as discounting can lead to business failure.
• Lifestyle Management: Founders should delay "leveling up" their lifestyle (mortgages, cars) until they are ready for a startup, as high burn rates make pivoting or failing financially devastating.
• Beta Definition: There is no distinction between "beta," "alpha," or "MVP"; the only defining line is whether users are actively using the product to solve a problem.
• Future Building: Founders should not attempt to predict the next big feature; they should build a fast cycle to test what works and iterate only on what shows results.