The MVP Guide: Build Less, Learn More

The phrase "minimum viable product" has been so overused it's nearly meaningless. Most founders build something that's minimum in name only — a full product with fewer features, still months in development, still unvalidated.

Here's what an MVP actually is, and how to build one correctly.

What an MVP Actually Is

An MVP is not a beta. It's not version 0.1. It's the smallest possible thing you can put in front of customers to test your most important assumption.

Eric Ries defined it as: "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

The key word is "learning." Your MVP isn't about shipping — it's about answering a question.

Before you build anything, ask: what's the one thing I need to learn right now? Your MVP should answer that specific question, nothing else.

The Most Common MVP Mistake

Founders build too much. They confuse "viable" with "good enough to launch publicly." They add features because investors might ask about them. They polish things customers haven't seen yet.

This is a death trap. Here's why:

• Every week you spend building is a week you're not learning
• The features you think users want are usually wrong
• You can't course-correct if you haven't shipped
• You burn runway before generating any signal

The question isn't "is this good enough?" It's "does this answer our core question?"

How to Scope Your MVP

Step 1: Identify your riskiest assumption

Every startup runs on assumptions. Which one, if wrong, kills the business?

Usually it's one of:

• Do people have this problem?
• Will they pay to solve it?
• Can we solve it in a way that's meaningfully better than alternatives?

Your MVP tests the riskiest assumption first.

Step 2: Define the minimum to test it

Strip everything else away. If your assumption is "enterprise finance teams will pay for automated reconciliation," you don't need a beautiful UI, onboarding flow, or integrations. You need one thing that does reconciliation well enough to prove the value.

Step 3: Set a success metric before you build

What does success look like? Define it in advance. "10 people pay us $100/month" or "70% of beta users complete core action in first session." Without this, you'll rationalize bad results after the fact.

Types of MVPs

Not every MVP is software. Match the type to your question.

• Landing page MVP: Validates demand. Does anyone care enough to sign up?
• Concierge MVP: You deliver the service manually. Validates that the outcome is valuable before automating it.
• Wizard of Oz MVP: The product looks automated but isn't. Validates that users want the automated experience.
• Prototype/clickable mockup: Validates the UX and workflow before a line of backend code.
• Manual + spreadsheet: Often underrated. Stripe started by manually processing payments for their first customers.

Real MVP Examples

Dropbox: Before building anything, Drew Houston made a demo video explaining what Dropbox would do. Overnight signups went from 5,000 to 75,000. That was the MVP.

Zappos: Nick Swinmurn didn't build inventory systems. He took photos of shoes from local stores, listed them online, bought them retail when someone ordered, and shipped them himself. Pure concierge MVP.

Airbnb: The founders listed their own apartment on a simple website and took photos with a borrowed camera. The MVP was a single listing, manually managed.

None of these required months of engineering.

What "Viable" Actually Means

Viable means it delivers enough value that you can learn something meaningful from it. It doesn't mean polished. It doesn't mean scalable. It doesn't mean feature-complete.

A viable MVP:

• Solves the core problem, even clumsily
• Can be put in front of real users (not just friends)
• Produces observable behavior you can learn from

After Your MVP

The goal of an MVP isn't to ship — it's to decide what to do next. After launch, you should have a clear answer:

• Build more: Strong signal, clear demand, paying customers asking for more
• Pivot: Demand exists but for something adjacent to what you built
• Stop: The assumption was wrong, the market isn't there

Most founders resist the third option too long. That's what advisors are for — to tell you what you can't see yourself.