How to Build An MVP with Michael Seibel | Startup School

The Midwit Meme and MVP Strategy

Understanding the counterintuitive nature of MVP development through the lens of founder intelligence levels.

The Three Types of Founders:

1. The Jedi (Super Intelligent) - Knows all the best practices and frameworks
2. The Idiot (First-Time Founder) - Has no idea what's going on
3. The Midwit (Really Smart) - Tries to do everything "right" but overthinks

The Surprising Truth:

Both the Jedi and the "Idiot" often reach the same correct decision before the overthinking "smart" founder. The best approach is actually the simplest:

• Launch something quickly and iterate
• Get a product into customers' hands immediately
• Learn whether it helps them or doesn't
• Iterate and improve over time

What NOT to Do:

• 100 surveys and 600 user interviews
• Contact every single competitor
• Spend a year fundraising
• Hire 100 people before validation
• Get distracted by activities that appear smart but don't advance learning

"You only really start learning about your user when you put a product in front of them. The thing you build in your MVP is probably not going to work - it's just the best way to start the conversation with the user about how you can solve their problems." - Michael Seibel

Timestamp: [0:08-1:49]

Pre-Launch Startup Goals

The essential framework for getting your startup off the ground and into customers' hands.

The Four-Step Process:

1. Get a product out into the world quickly - Build your minimum viable product
2. Talk to initial customers - Find people who will actually use what you've built
3. Figure out what makes your product useful - Care deeply about helping customers accomplish their goals
4. Iterate based on feedback - Change your product so it actually helps them succeed

The Iteration Cycle:

• Talk to users → Iterate product → Talk to more users → Iterate product
• After 3-6 iterations, your MVP will be completely different
• You'll have learned exponentially more than just talking to co-founders or theorizing

Why This Works:

• 10x more learning than internal discussions
• Users become more excited as they see the product evolve
• Higher likelihood customers will use and pay for your product
• Real conversation with users about their actual problems

"More often than not, after three, four, five, six iterations, your MVP is going to be very different. You have learned so much by having that conversation with users and by letting them see your product evolve, you can actually make them more excited, more likely to use your product, more likely to pay for your product." - Michael Seibel

Timestamp: [1:50-2:51]

The Modern Anti-MVP Movement

Understanding the current resistance to minimum viable products and why founders want to build "perfect" products from day one.

Current Trends Against MVPs:

• Minimum Lovable Products - Focus on emotional connection over learning
• Minimum Useful Products - Emphasis on immediate utility over iteration
• "God Level" Products - Steve Jobs-inspired perfectionism from launch

The Steve Jobs Misconception:

Many founders want to "make the iPhone and change the world" from their first release, believing that starting small is inherently bad.

Common Founder Fears:

• "If I give customers something small that doesn't work well, it's a bad idea"
• "If a customer doesn't like my product, I'll never be able to talk to them again"
• "I need to build something perfect or customers will reject me forever"

The Reality About Early Adopters:

• They're used to using products that don't work very well
• They have real problems and are open to trying new software
• They're willing to work with you if you're transparent about iteration
• They try new products all the time - they won't disappear after one bad experience

"The people who are interested in talking to a startup are early adopters. They're used to using products that don't work very well, and the reason why they're talking to you is not because they think your product's going to work great - it's because they have a real problem and they're open to using new software." - Michael Seibel

Timestamp: [2:54-4:26]

Founders' Biggest Fear

The non-specific terror that paralyzes founders and prevents them from launching, plus how to overcome it.

The Fear:

"If I give people my product and they don't like it, my company dies"

Reality Check Questions:

• Does your company actually die tomorrow?
• Is it really "game over"?
• Have you run out of money?
• Are all your co-founders going to quit?

Worst Case Scenario Analysis:

Let's imagine the absolute worst happens:

1. You demo your product to a customer
2. It doesn't work at all
3. They don't want to use it
4. You wake up the next day...

What Actually Happens:

• Nothing is different - you still have your startup
• You can reach out to someone else immediately
• You can contact that same customer a week later with improvements
• Your startup is not dead - you've just gathered data

The Mindset Shift:

• Feel the fear - it's natural and not bad
• Don't act on the fear - it's bad to spend a year building because you're afraid
• Lean into the fear - ask yourself if the fear is actually real
• Test your assumptions - will your company really die if this scary thing happens?

"It's not bad to feel the fear, but it is bad to act on it. It is bad to spend one year building your MVP because you're afraid the first customer might not like it." - Michael Seibel

Timestamp: [4:27-5:38]

The Perfectionist Founder Trap

Why thinking you know the perfect product leads to massive misconceptions about great product development.

The "Fake Steve Jobs" Mindset:

"I know what the perfect product is, and I know it's going to take a year to build. Why would I build shitty versions of it?"

The Real Steve Jobs vs. The Myth:

Most people think Steve Jobs could "just imagine great products in his mind and bring them out into the world" - but this is completely wrong.

iPhone Reality Check:

When people praise the "amazing first iPhone," they forget:

• No App Store initially
• Couldn't take video with the first version
• Only had 2G, not 3G - really bad internet
• Most people think of the 3rd or 4th iteration when they remember "the iPhone"

iPod Evolution:

• First version had a physical scrolling device
• Sand would get stuck in the mechanism
• Broke all the time due to mechanical issues

The Truth About Great Products:

Even Steve Jobs needed multiple iterations to get his products right. The products we remember as "perfect" were actually the result of continuous improvement over time.

"Even the great Steve Jobs iterated his products over time. So if you find yourself being a fake Steve Jobs thinking 'I know exactly what the customer needs, I just need to raise 10 million dollars and spend a year building it and then launch it' - think again. If Steve Jobs needed multiple tries to get his products right, maybe you need to as well." - Michael Seibel

Timestamp: [5:40-7:15]

Essential Insights:

1. The smartest approach is often the simplest - Launch quickly and iterate rather than over-analyzing and over-planning
2. You only learn when customers use your product - All the surveys and interviews in the world can't replace real user interaction with your actual product
3. Early adopters expect imperfection - They're used to broken products and will work with you if you're transparent about improving

Actionable Insights:

• Challenge your fears with specific scenarios - Ask "what would actually happen" in your worst-case situation
• Study how successful products actually evolved - Even the iPhone and iPod went through multiple iterations before becoming "perfect"
• Focus on the iteration cycle - Talk to users, improve product, repeat - this is where real learning happens

Timestamp: [0:01-7:15]

People Mentioned:

• Steve Jobs - Used as example of how even legendary product builders needed multiple iterations to create successful products
• Michael Seibel - Y Combinator Group Partner presenting this MVP framework

Companies & Products:

• Y Combinator - Startup accelerator providing this MVP guidance to founders
• Apple - Company behind iPhone and iPod examples used to demonstrate iterative product development

Technologies & Tools:

• iPhone - Demonstrated how even "perfect" products started with limited features (no App Store, no video, 2G only)
• iPod - Example of how first versions had mechanical issues that were improved over time

Concepts & Frameworks:

• Midwit Meme - Framework for understanding how intelligence level affects decision-making in startup contexts
• Minimum Viable Product (MVP) - Core concept of building simple initial versions to start customer conversations
• Early Adopter Theory - Understanding that initial customers expect imperfection and are willing to work through issues

Timestamp: [0:01-7:15]

Software MVP Examples

Three proven patterns that successful companies used to launch fast and learn quickly from real users.

The Three Universal Patterns:

1. Fast to Build - All products could get to market quickly
2. Very Limited Functionality - Bare minimum features only
3. Small User Base - Appealed to a specific, small set of users

The Key Insight:

Making something that a small group of people absolutely loved was far more important than making something that could address all the needs of all potential customers from day one.

Real Examples:

Airbnb's First Version:

• No payments - Users had to arrange payment some other way
• No map view - Couldn't see where places were located in the city
• Air beds only - Couldn't rent whole houses or individual rooms
• Conference-only - Only worked when conferences were happening in a city

Twitch (originally Justin.TV):

• One page only - The single page you see in the example
• One streamer - Just Justin with a camera on his head broadcasting 24/7
• No video games - Except randomly playing Guitar Hero sometimes
• Ridiculously expensive streaming - Paying a CDN without their own video system

Stripe (originally /dev/payments):

• No fancy bank deals - Working with a tiny bank
• No direct APIs - Had to call the bank and file manual paperwork every night
• Almost no API features - So basic that even Twitch couldn't use it initially
• Simple credit card payments only - Just what early YC startups needed

"The first version of Stripe was so basic that even us back in the day at Twitch couldn't use it because it didn't have enough features. But the folks who could use it were early stage YC startups who all they wanted to do was accept simple credit card payments from their customers. That's all Stripe did in the beginning, and that was more than enough to get started." - Michael Seibel

Timestamp: [7:17-10:01]

Solving Hair On Fire Problems

Understanding the psychology of early adopters and why desperate customers will use imperfect solutions.

The "Hair On Fire" Customer:

Imagine your hair is literally on fire right now. What would you want me to sell you?

The Perfect Solution:

• Bucket of water - Solves the problem immediately
• Hose - Professional-grade solution
• Fire extinguisher - The "iPhone" of fire solutions

The MVP Reality:

• I'm selling you a brick - Not perfect, but available now
• You'd buy the brick - Because you're desperate
• You'd hit yourself with it - To smother the fire
• It works - Not perfectly, but it solves the immediate problem

Why This Works:

• Desperate customers can't wait - They need a solution now, not later
• Non-perfect solutions still solve problems - Better than no solution at all
• Early adopters expect imperfection - They're used to working with startups

Customer Segmentation Strategy:

• Go after desperate customers first - They'll use imperfect solutions
• Non-desperate customers can wait - Don't focus on them initially
• This makes your life easier - Clear target market with urgent need

"That's an MVP - it's not the perfect solution, but you are in so much pain as a customer you will use a non-perfect solution to solve your problem. That's the customer you should be going after. For customers who are not desperate, you can wait. You don't have to go after them now - just go after the desperate ones first." - Michael Seibel

Timestamp: [10:03-11:52]

The Limitation of Customer Research

Understanding why surveys and user interviews can't replace actually building and testing real products.

The Business School Approach:

"I can skip building an MVP. Instead of building and iterating, why don't I just survey 100 users and they'll tell me what to build?"

Why This Doesn't Work:

• Customers are experts in their problem - They know their pain points intimately
• Customers don't have the solutions - That's the job of the product builder
• Surveys help understand pain - But never help figure out how to solve that pain
• Product conversations require actual products - You need something tangible to discuss

The Real Learning Process:

1. Put a product in front of customers - Preferably a crappy MVP
2. Start the solution conversation - "Does this solve your problem?"
3. Iterate based on real usage - Not hypothetical feedback
4. Continue the cycle - Build, test, learn, repeat

Universal Truth:

• No shortcuts exist - Even enterprise software companies started with imperfect first versions
• All successful products were minimum initially - They were the least customers were willing to use
• Large companies follow the same pattern - Their first versions were far from perfect

"The only time that you start having that conversation with the customer is when you can put a product in front of them, preferably a crappy MVP, and start saying 'does this solve your problem?' I haven't really seen a shortcut to this step." - Michael Seibel

Timestamp: [11:53-13:26]

Learning-Focused Mindset

Understanding that the pre-product-market-fit phase is fundamentally about discovery, not execution.

The Fundamental Truth:

You don't start your startup with all the answers.

The Pre-Product-Market-Fit Phase:

• All about learning - Not about perfect execution
• Take initial insights - Bring them to market for testing
• Discover through interaction - Learn from real user behavior
• Iterate based on findings - Adjust based on actual data

Where Great Products Come From:

• Most solutions are discovered after launch - Not planned in advance
• Best product features - Were found through user interaction
• Founders learned from users - After getting products in their hands
• MVP enables the learning process - Fastest way to start discovering

The Speed Advantage:

• Faster learning = better outcomes - The quicker you learn, the better your product becomes
• Time to market matters - Learn before competitors do
• First-mover learning advantage - Build something people love before anyone else

"Building a startup, especially the first phase of building a startup pre-product-market-fit, is all about learning. Most of the solutions, most of the best parts of products you use today were discovered after those products were launched when those founders were learning from their users. Building and launching an MVP is the fastest way to start the process of learning." - Michael Seibel

Timestamp: [13:28-14:11]

Build an MVP Quickly

Four practical strategies to ensure you launch fast and avoid the perfectionist trap.

The Four-Step Quick Build Process:

1. Set a Specific Deadline

• Two weeks, one month, or month and a half maximum
• Forces minimum viable decisions - Easier to cut features when time-constrained
• Prevents endless development - No deadline = no launch

2. Write Down Your Spec

• List all 5-10 features you think are required for launch
• Prevents constant debate - No more "should we have this feature?"
• Eliminates decision fatigue - Focus on building instead of continuously debating
• Clear reference point - Everyone knows exactly what needs to be built

3. Cut That Spec Back

• Review each feature and ask: "Does a truly desperate customer need this to start?"
• Leave features for versions 2, 3, or 4 - You'll be surprised how much you can cut
• Focus on basic functionality - Get the core value out first
• Prioritize ruthlessly - Only include absolute essentials

4. Don't Fall in Love with Your MVP

• It's going to change - Prepare for massive iteration
• Get very different over time - Your final product will look nothing like this
• Fall in love with your customer - Not with your initial product
• Focus on user learning - The product is just a vehicle for understanding users

The Mindset:

• Build fast - Speed is more important than perfection
• Expect change - Your MVP is a learning tool, not the final product
• User-focused - Care about solving customer problems, not building beautiful features

"Don't fall in love with your MVP. It's gonna change, you're going to iterate it, it's going to get very, very, very different over time. You want to do it fast and you don't want to fall in love with it. You want to fall in love with your customer, with your user - not in love with the crappy initial product that you're building to start learning from that user." - Michael Seibel

Timestamp: [14:12-15:50]

Quality Over Quantity Focus

The counterintuitive approach to early customer acquisition and why doing things that don't scale is essential.

The Core Philosophy:

"It's far better to have a hundred people love your product than a hundred thousand who kind of like it."

Why This Matters for MVPs:

• Deep love beats broad acceptance - Passionate users become advocates
• Small dedicated user base - Easier to understand and serve well
• Quality feedback loop - Passionate users give better feedback
• Foundation for growth - Love spreads faster than mild interest

The "Don't Scale" Strategy:

When Releasing Your MVP:

• Do things that don't scale - Recruit initial customers one at a time
• Personal attention - Care deeply about each early customer
• Individual relationships - Work directly with users to solve their problems
• Manual processes - Handle things personally that will eventually be automated

The Customer Care Promise:

• They will talk to you - If you genuinely care about solving their problems
• Collaborative relationship - Work together to figure out solutions
• Product development partnership - Help each other build something great
• Mutual benefit - You learn, they get their problems solved

Long-term Benefits:

• Strong product foundation - Built on real user needs
• Customer loyalty - Users who helped build it will stay with you
• Word-of-mouth growth - Passionate users become your best marketing
• Product-market fit - Deeper understanding leads to better fit

"When you're releasing that MVP, it's totally okay to do things that don't scale and recruit those initial customers one at a time. If you care about those customers, I promise you they will talk to you, that you can work with them and you can help them figure out how to solve their problems, and as a result help figure out how to build a great product for them." - Michael Seibel

Timestamp: [15:53-16:39]

Essential Insights:

1. Successful MVPs follow three patterns - Fast to build, limited functionality, small user base focused on people who absolutely love the product
2. Target "hair on fire" customers first - Desperate customers will use imperfect solutions, while non-desperate customers can wait for polished products
3. Surveys can't replace building - Customers know their problems but can't design solutions; real learning happens when you put products in front of users

Actionable Insights:

• Set specific deadlines and write detailed specs - Then ruthlessly cut features by asking "does a desperate customer need this to start?"
• Don't fall in love with your MVP - Fall in love with your customers and expect your product to change dramatically through iteration
• Focus on 100 people who love your product - Rather than 100,000 who kind of like it; do things that don't scale to build deep relationships with early users

Timestamp: [7:17-16:44]

People Mentioned:

• Justin Kan - Co-founder of Twitch, originally Justin.TV where he broadcast 24/7 with a camera on his head
• Michael Seibel - Y Combinator Group Partner presenting this framework; co-founder of Twitch

Companies & Products:

• Airbnb - Example of MVP starting with air beds only, no payments, no map view, conference-only availability
• Twitch - Started as Justin.TV with one page, one streamer, expensive CDN costs before building their own video system
• Stripe - Originally /dev/payments with manual bank processes, basic API, serving only simple YC startup payment needs
• Y Combinator - Startup accelerator whose early companies used Stripe's basic payment processing

Technologies & Tools:

• CDN (Content Delivery Network) - Expensive streaming solution Twitch used before building their own video system
• API (Application Programming Interface) - Stripe's early version had very limited API features compared to today

Concepts & Frameworks:

• Hair On Fire Problem - Framework for identifying customers desperate enough to use imperfect solutions
• Minimum Viable Product (MVP) - Core concept of building fast, limited functionality products for small user bases
• Product-Market Fit - The pre-fit phase focused on learning rather than scaling
• Don't Scale Strategy - Intentionally doing manual, unscalable things to build deep customer relationships

Timestamp: [7:17-16:44]