What "MVP" actually means, and why most first versions are still too big

"MVP" gets thrown around in almost every early client conversation we have, and it rarely means the same thing to the person saying it as it does in the original definition. Most of the time it's shorthand for "the cheap version we build first," which misses the actual point of the concept and tends to produce a first version that's still far too large.

The original idea, minimum viable product, was never really about minimum effort. It was about the smallest thing you can put in front of real users that lets you learn whether your core assumption holds. Those are very different design briefs, and confusing them is the single most common reason early-stage products take three times longer to ship than planned.

Founders tend to over-invest in the "viable" half of the phrase and under-invest in the "minimum" half, adding features because a competitor has them or because they seem obviously necessary in the abstract. Every one of those additions delays the moment you actually learn whether anyone wants the core thing at all, which is the only question an MVP is supposed to answer.

We push back hard on features justified by "users will expect this," because that claim is almost never tested, just assumed. The response we give is simple: if you're not sure whether they'll expect it, that's exactly the kind of thing an MVP should be finding out, not guessing at in advance and building for.

Every product idea rests on one assumption that, if wrong, makes the rest of the plan irrelevant. Usually it's some version of "people will pay for this" or "this actually saves someone meaningful time." We ask founders to name that assumption explicitly before we scope anything, because the whole point of the first build is to test it as cheaply and quickly as possible.

Once that assumption is named, most of the feature list falls into two piles: things required to test it, and things that would be nice once it's proven. Only the first pile belongs in version one. Everything in the second pile is a reasonable roadmap item and a bad reason to delay the launch that actually answers the question that matters.

User accounts with full profile management, when a simple email capture would answer the same early question. A custom admin dashboard, when a spreadsheet or an off-the-shelf tool would do the job for the first fifty users. Multiple user roles and permission levels, when there's exactly one type of user on day one and the rest is speculation about a future that might look nothing like the plan.

None of these are bad ideas forever. They're bad ideas for a version whose entire job is to be built and shipped fast enough to still be useful as a test. We keep a running list of "good idea, wrong stage" items for every MVP project, and it's usually longer than the actual feature list we build.

Viable doesn't mean polished. It means a real user can complete the core action without a member of your team walking them through it personally. That's a lower bar than most founders assume, and hitting it exactly, rather than overshooting it with unnecessary polish, is what keeps a first build small enough to actually ship on a useful timeline.

We test this directly before calling anything done: can someone outside the founding team, with no special instructions, use the product to do the one thing it exists to do. If the answer requires an explanation, the product isn't viable yet regardless of how many features it has, and if the answer is yes with a rough interface, it's often more viable than founders give it credit for.

Founders tend to associate a fuller feature set with lower risk, as if more functionality means fewer ways for the launch to fail. In practice the opposite tends to be true: more scope means more time before any real user sees the product, more surface area for bugs, and a slower feedback loop on the one question that actually matters, whether the core idea works.

We push founders to notice this instinct when it shows up, because it usually isn't really about the product. It's about discomfort with shipping something incomplete-looking, which is an emotional cost, not a strategic one. Naming that difference out loud has talked more than one founder into a smaller, faster first version.

We ask founders to write the sentence they hope to be able to say after the first thirty days: "users who tried this came back a second time," or "people were willing to pay before we built anything else." That sentence becomes the scoping document, more than any feature list, because everything we build has to serve proving or disproving it.

Anything that doesn't move that specific sentence closer to true or false gets set aside for later, no matter how reasonable it sounds on its own. This reframing is usually the single biggest lever in getting an MVP down to a size that can actually ship on a useful timeline.

If the core assumption holds, the second pile of features, the ones set aside as "good idea, wrong stage," becomes the actual roadmap, now informed by real usage data instead of guesses made before a single user touched the product. That data usually reorders the list significantly from what it looked like at the start.

If the assumption doesn't hold, the founder has spent weeks, not months, finding that out, with enough runway left to try a meaningfully different approach. That outcome, while disappointing in the moment, is the entire point of building minimum first: a fast, cheap wrong answer beats a slow, expensive one every time.

The founders who ship the fastest and learn the most aren't the ones with the smallest ambitions. They're the ones willing to separate what needs to be true from what would merely be nice, and build only for the former in the first pass.

That discipline is uncomfortable, because it means launching something that visibly isn't the full vision yet. It's also the only reliable way we've seen to get real answers before running out of runway trying to build the whole thing at once.