Startup Building Mastery

"A startup is not a smaller version of a large company. It's a temporary organization designed to search for a repeatable, scalable business model."

The Startup Philosophy

code

STARTUPS ARE ABOUT:
✓ Learning what customers want
✓ Finding product-market fit
✓ Validating assumptions quickly
✓ Iterating based on evidence

STARTUPS ARE NOT ABOUT:
✗ Building perfect products
✗ Following a fixed plan
✗ Scaling before validating
✗ Guessing what works

The Startup Stages

code

╔═══════════════════════════════════════════════════════════════════╗
║                    STARTUP STAGES                                  ║
╠═══════════════════════════════════════════════════════════════════╣
║                                                                    ║
║   1. PROBLEM/SOLUTION FIT                                          ║
║      Do we have a problem worth solving?                           ║
║      Do we have a solution people want?                            ║
║                                                                    ║
║   2. PRODUCT/MARKET FIT                                            ║
║      Does our product satisfy the market?                          ║
║      Do users love it enough to pay/recommend?                     ║
║                                                                    ║
║   3. SCALE                                                         ║
║      Can we grow efficiently?                                      ║
║      Is growth sustainable?                                        ║
║                                                                    ║
╚═══════════════════════════════════════════════════════════════════╝

Stage 1: Problem/Solution Fit

Validating the Problem

code

BEFORE BUILDING ANYTHING:

1. TALK TO USERS
   - Interview 20+ potential users
   - Ask about their current pain
   - Understand their workflow
   - Never pitch your solution

2. VALIDATE THE PAIN
   Questions to ask:
   - "How do you currently solve this?"
   - "How much does this problem cost you?"
   - "Have you tried other solutions?"
   - "Would you pay to solve this?"

3. ASSESS MARKET SIZE
   - TAM: Total Addressable Market
   - SAM: Serviceable Addressable Market
   - SOM: Serviceable Obtainable Market

The Mom Test

code

BAD QUESTIONS:
"Would you use a product that..."
→ People say yes to be nice

GOOD QUESTIONS:
"Tell me about the last time you..."
→ Gets real behavior, not hypotheticals

RULE:
Talk about their life, not your idea.
They should not know what you're building.

Problem Hypothesis

markdown

## Problem Hypothesis Template

### Customer Segment
[Who specifically has this problem?]

### Problem Statement
[Specific description of the pain]

### Existing Solutions
[How they currently solve it]

### Why Now?
[Why is now the right time to solve this?]

### Evidence
[What evidence supports this problem exists?]

Stage 2: Building MVP

The MVP Philosophy

code

MVP = MINIMUM VIABLE PRODUCT

NOT: The smallest product you can build
BUT: The smallest thing that tests your hypothesis

PURPOSE:
Learn whether your solution solves the problem
for the people you're targeting.

MVP Types

code

LANDING PAGE MVP:
Describe the product, capture signups.
Tests: Is there interest?

CONCIERGE MVP:
Manually do what software would do.
Tests: Does the solution work?

WIZARD OF OZ MVP:
Looks automated, but humans behind it.
Tests: User experience and workflow.

SINGLE FEATURE MVP:
Build one feature well.
Tests: Core value proposition.

Build-Measure-Learn Loop

code

       ┌─────────────────────────┐
       │         IDEA            │
       └───────────┬─────────────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │         BUILD           │
       │     (Minimum effort)    │
       └───────────┬─────────────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │        PRODUCT          │
       └───────────┬─────────────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │        MEASURE          │
       │   (Validated learning)  │
       └───────────┬─────────────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │          DATA           │
       └───────────┬─────────────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │         LEARN           │
       │  (Pivot or persevere)   │
       └───────────┬─────────────┘
                   │
                   └──────────────→ [NEXT LOOP]

Stage 3: Product-Market Fit

Measuring PMF

code

THE 40% RULE (Sean Ellis):
Survey users: "How would you feel if you could
no longer use [product]?"

If 40%+ say "Very disappointed" → PMF achieved

OTHER PMF INDICATORS:
• Users promote without asking
• Growth happens organically
• Retention is strong
• Users complain if it breaks

PMF Survey Template

code

1. How would you feel if you could no longer use [product]?
   □ Very disappointed
   □ Somewhat disappointed
   □ Not disappointed

2. What type of person do you think would benefit most?
   [Open text]

3. What is the main benefit you receive?
   [Open text]

4. How can we improve [product] for you?
   [Open text]

Before vs After PMF

code

BEFORE PMF:
• Talk to users constantly
• Change direction frequently
• Minimize spending
• Focus on learning, not scaling

AFTER PMF:
• Start scaling operations
• Build team
• Increase spending on acquisition
• Optimize funnel

Metrics That Matter

The Pirate Metrics (AARRR)

code

ACQUISITION:  How do users find you?
ACTIVATION:   Do users have a good first experience?
RETENTION:    Do users come back?
REVENUE:      Do users pay?
REFERRAL:     Do users tell others?

Focus on ONE metric per stage.
Don't optimize acquisition before retention.

The One Metric That Matters

code

At any given time, there's ONE metric that matters most.

Early stage: Activation rate
              Are people using the product?

Growth stage: Retention rate
               Are people coming back?

Scale stage:  Unit economics
              Is each customer profitable?

Common Startup Mistakes

Mistake 1: Building Too Much

code

SYMPTOM: "We need more features before we can launch."
TRUTH: You're afraid of feedback.

FIX: Launch with one feature that solves one problem.

Mistake 2: Not Talking to Users

code

SYMPTOM: "We know what they need."
TRUTH: You don't.

FIX: 20 user conversations before building.
     20 more after MVP.
     Weekly conversations forever.

Mistake 3: Scaling Before PMF

code

SYMPTOM: "We need more users to prove the model."
TRUTH: If users don't retain, more users won't help.

FIX: Fix retention before scaling acquisition.

Mistake 4: Falling in Love with Solution

code

SYMPTOM: "The product is great, users are wrong."
TRUTH: Users are never wrong about their own needs.

FIX: Fall in love with the problem, not the solution.

Quick Reference

Startup Checklist

code

PROBLEM VALIDATION:
□ Interviewed 20+ potential users
□ Confirmed problem exists and is painful
□ Understood current solutions
□ Validated willingness to pay

MVP DEVELOPMENT:
□ Defined smallest testable product
□ Set clear success metrics
□ Built in days/weeks, not months
□ Launched to real users

PMF SEEKING:
□ Measuring user satisfaction (40% test)
□ Tracking retention
□ Iterating based on feedback
□ Ready to pivot if needed

Key Questions at Each Stage

code

PROBLEM STAGE:
"Are people actively looking for a solution?"
"Are they paying for inferior alternatives?"

MVP STAGE:
"Do users understand what this is?"
"Do they use it more than once?"

PMF STAGE:
"Would users be disappointed if it disappeared?"
"Do they recommend it unprompted?"

"The goal isn't to build what you imagine. It's to discover what users need."