Building Your MVP

The $12 billion product that started with a video

In 2007, Drew Houston kept forgetting his USB drive. He was a MIT graduate, a competent programmer, and constantly losing files between his laptop and his desktop. One day, stuck on a bus from Boston to New York with no USB drive and four hours to kill, he started writing code for a file-syncing tool.

But Houston didn't spend two years building Dropbox in silence. Instead, he made a 3-minute screencast. The video showed a demo of the product — files dragging into a folder and magically appearing on another computer. It looked real. It wasn't. Most of the functionality shown was smoke and mirrors, pieced together to demonstrate the concept.

He posted the video to Hacker News. The waitlist jumped from 5,000 to 75,000 people overnight. That video was Dropbox's MVP — and it validated the idea without shipping a single line of production code.

Dropbox went on to IPO at a $12 billion valuation in 2018.

What an MVP actually is (and isn't)

The term "Minimum Viable Product" was popularized by Eric Ries in The Lean Startup (2011), building on ideas from Steve Blank. It's the most misunderstood concept in startups.

An MVP is not a half-baked product with bugs everywhere. It's not version 1.0 with fewer features. It's the smallest thing you can build or do to test your riskiest assumption.

The key question to ask: "What is the riskiest assumption in my business, and what is the cheapest way to test it?"

For Dropbox, the riskiest assumption wasn't "can we build file sync?" (Houston was a strong engineer). It was "do enough people care about this problem to switch from USB drives and email attachments?" A video answered that question for the cost of a few hours of work.

The MVP spectrum: from zero code to working product

Not every MVP requires coding. Here are the most common types, ordered from simplest to most complex:

No-code tools for building MVPs fast

You don't need to be a developer to build a functional MVP. Here are the tools that let non-technical founders ship in days:

There Are No Dumb Questions

"If my MVP is manual and doesn't scale, isn't that a waste of time?"

No — it's the most efficient use of your time. Paul Graham, co-founder of Y Combinator, literally advises startups to "do things that don't scale." Manual processes teach you exactly what your product needs to automate. Airbnb co-founders personally photographed apartments. Stripe founders manually installed their software on users' laptops. These "unscalable" actions built deep understanding of the customer.

"How do I know when my MVP is 'minimum' enough?"

If you're not embarrassed by your first version, you launched too late — that's often attributed to Reid Hoffman (LinkedIn co-founder), and it captures the spirit: your MVP should feel uncomfortably bare. Ask: "Can I remove one more feature and still test my core assumption?" If yes, remove it.

The art of scope cutting

The biggest mistake first-time founders make with MVPs is including too many features. Here's how to cut scope ruthlessly:

Step 1: List every feature you can imagine.

Step 2: For each feature, ask: "Does this test my core assumption?" If no, cut it.

Step 3: Of what's left, ask: "Can my first 10 users live without this for 2 weeks?" If yes, cut it.

Step 4: What remains is your MVP.

Getting your first 10 users

Your first users won't come from Google ads or viral growth. They'll come from hustle. Here's how successful startups got their earliest adopters:

There Are No Dumb Questions

"What if nobody wants to use my MVP?"

That's data, not failure. If you can't get 10 people to try your product for free, you have one of three problems: (1) you're targeting the wrong audience, (2) your messaging doesn't communicate the value, or (3) the problem isn't painful enough. Go back to customer interviews.

"Should I charge from day one?"

It depends on what you're testing. If your assumption is "will people pay for this?", then yes — charge immediately. If your assumption is "does this solve the problem?", then free or discounted access gets you faster feedback. But don't stay free forever. Price is the ultimate validation.

The build-measure-learn loop

Eric Ries's core framework from The Lean Startup is a simple cycle:

The goal is to complete this loop as fast as possible. Every day you spend building without measuring is a day you might be building the wrong thing.

What to measure after launching your MVP:

Iterating on feedback: what to listen to and what to ignore

Not all feedback is created equal. Here's how to filter:

The golden rule of iteration: Change one thing at a time. If you change the onboarding, the pricing, and the landing page simultaneously, you won't know which change caused the result.

Key takeaways

• An MVP is the smallest experiment that tests your riskiest assumption — not a crappy version of your product
• You don't need code to build an MVP — landing pages, videos, manual services, and no-code tools all count
• Scope cut ruthlessly — for each feature, ask "does this test my core assumption?" If not, cut it
• Your first 10 users come from hustle, not ads — personal outreach, communities, and your network
• The build-measure-learn loop is the engine of progress — complete it as fast as possible
• Filter feedback by patterns, not individual opinions — and change one thing at a time