Most founders build their MVP wrong.

Not slightly wrong — fundamentally wrong. And it usually goes one of two ways.

The first type builds something so stripped-down it doesn't actually work. No real user would touch it. They call it an MVP, but what they've built is an unfinished product that proves nothing except that they can ship something incomplete.

The second type spends six months building every feature they ever imagined, then calls that the MVP. By the time they launch, they've spent half their runway on assumptions they never tested.

Both of these are expensive mistakes. The good news: they're avoidable once you understand what a minimum viable product actually is — and what it's for.

---

What an MVP Actually Is (and Isn't)

The term "minimum viable product" was popularized by Eric Ries in The Lean Startup, but it's been misunderstood and misapplied ever since.

Here's the definition that matters: An MVP is the smallest version of your product that lets you test your most important assumption about your business.

That's it. Not the smallest product you can ship. Not v1.0 with features cut. Not a prototype. A learning tool designed to answer a specific question.

What an MVP is not:

• A half-built product that sort of works
• An excuse to ship something you know is broken
• A beta version of your full product vision
• Something you'd be embarrassed to show real users

The "viable" part is doing a lot of work in that definition. Your MVP has to be good enough that real users will engage with it honestly. If people are politely tolerating it rather than genuinely using it, you're not learning anything real.

The "minimum" part means you've ruthlessly cut everything that doesn't serve the core learning objective. Not because you're lazy, but because every extra feature you build delays the feedback you need.

---

The Purpose of an MVP: It's a Learning Tool, Not a Product Launch

This is the mindset shift that separates founders who use MVPs well from those who don't.

An MVP is not a launch. It's an experiment.

You are not trying to acquire customers, generate revenue, or build a brand with your MVP. You are trying to answer a question. Specifically: Is the core assumption underlying this business true?

Every business is built on a stack of assumptions. Some of those assumptions are low-risk — you can figure them out later. But there's usually one assumption that, if it's wrong, makes everything else irrelevant. That's your riskiest assumption, and your MVP's only job is to test it.

For a two-sided marketplace, the riskiest assumption might be: "Suppliers will list their inventory on a platform like this." For a B2B SaaS product, it might be: "Teams will change their workflow to use this tool." For a consumer app, it might be: "People actually want this enough to come back a second time."

The question your MVP answers determines what your MVP looks like. This is why there's no universal MVP template — the right MVP depends entirely on what you're trying to learn.

---

How to Scope Your MVP

Two frameworks that actually help:

1. The Jobs-to-Be-Done approach

Instead of asking "what features should I build?" ask: "What job is the customer hiring this product to do?" Be specific. Not "manage their tasks" but "know at a glance what they should be working on right now."

When you're clear on the job, it becomes much easier to separate features that serve that job from features that are just nice to have. Build only what directly enables the user to get the job done. Everything else waits.

2. The Riskiest Assumption Test

Write down every assumption your business depends on. Then rank them by two factors: how important is this assumption to the business, and how confident are you that it's true?

The assumption that's both highly important and least validated is the one your MVP should test. Build the minimum thing that gives you an honest answer to that single question.

A useful forcing function: complete this sentence before you build anything. "We will know our MVP succeeded if [specific, measurable outcome] happens within [timeframe]."

If you can't complete that sentence, you're not ready to build yet.

---

MVP Types: Which One Fits Your Situation

Not every MVP involves writing code. Some of the most valuable MVPs are entirely manual. Here are four common formats and when to use each:

Concierge MVP

You deliver the product experience manually, behind the scenes. The user gets the outcome; they don't see the process. This works well when you're testing whether users want the outcome at all, before you automate anything.

Best for: Services, data products, anything where the "magic" could theoretically be done by hand first.

Wizard of Oz MVP

Similar to concierge, but the user thinks they're interacting with a real product. A human is actually making the decisions. The famous early example is Zappos founder Nick Swinmurn photographing shoes at local stores and posting them online — if someone ordered, he'd go buy the shoes and ship them. No warehouse, no inventory system. Just a test of whether people would buy shoes online.

Best for: Validating demand before building infrastructure.

Landing Page MVP

Build a page that describes the product as if it exists. Drive traffic to it. Measure signups, clicks on a "buy now" button, or email captures. This tests demand signal — do people want this enough to take action?

Best for: Early demand validation, especially for consumer products or SaaS. Important caveat: you're testing interest, not retention or actual usage. Don't over-index on this signal alone.

Prototype / Clickable Demo

A non-functional (or partially functional) version of the product that users can interact with. Good for testing usability and whether the core experience makes sense to people.

Best for: Products where the UX is the core innovation, or when you need to show rather than describe what you're building to get meaningful feedback.

---

Common MVP Mistakes (And How to Avoid Them)

Building features instead of testing assumptions

The most common trap. You have a hypothesis — "users need X" — and instead of testing it, you build X, then Y and Z while you're at it. By the time you find out X wasn't actually the problem, you've built a product around the wrong insight.

Test before you build. Even a five-minute conversation with a potential user asking "how do you currently handle X?" teaches you more than a week of development.

Skipping the "viable" part

An MVP has to be good enough that users engage with it honestly. If your MVP is so rough that users are giving you polite feedback rather than real behavior, you're not learning. There's a minimum bar for quality — not aesthetic perfection, but functional integrity. The core thing your MVP does needs to actually work.

Not defining success metrics before you build

This is subtle but important. If you decide what "success" looks like after you see the results, you will unconsciously move the goalposts. Define your metrics upfront: what number needs to move, by how much, for you to consider this validated? Write it down before you start.

Confusing activity with validation

Users signing up is not validation. Users using the product every week is closer. Users paying for it is closer still. Users coming back after paying and telling their friends is validation. Be honest with yourself about what signal you're actually getting.

Treating the MVP as permanent

Some founders become so attached to their MVP that they keep patching it instead of rebuilding properly once they've validated the core idea. The MVP's job is to answer a question. Once it's answered, you move on — usually to a more complete build based on what you learned.

---

Before You Build, Validate the Market

One thing that often gets skipped in the MVP process: understanding whether the market itself is worth pursuing before you invest time building anything.

Knowing there's a problem is not the same as knowing the market is large enough, competitive enough to enter, or structured in a way that makes your business model work. This kind of market intelligence — total addressable market, competitive landscape, positioning — used to require a consultant or weeks of research.

DimeADozen.AI generates competitive intelligence and market sizing for a specific business idea in under an hour, for $59. It's worth doing before you scope your MVP, so you're building toward a market opportunity you understand rather than discovering the ceiling later.

---

Knowing what to build is the hardest part of being a founder. The MVP framework doesn't make it easy — but it makes it structured. Start with the riskiest assumption, build the minimum thing that tests it honestly, and let the evidence tell you what to do next.

That's the whole game.