"Build an MVP" is advice so widely repeated that it's lost most of its meaning. Teams call things MVPs when they're actually prototypes, full products, or just features. The word has become a way to excuse shipping something underdone, or alternatively, a justification for never shipping anything.
Let's get concrete about what an MVP actually is, when it's the right approach, and when it's the wrong one.
What an MVP actually is
An MVP is the minimum set of features that delivers real value to real users and generates learning about whether the core assumption is correct.
Three words matter here:
Minimum. If you're arguing about whether to include a feature, the default answer for an MVP is no. Every feature you add increases build time, maintenance burden, and the complexity of interpreting what you learn.
Real value. An MVP is not a demo, a prototype, or a landing page with a waitlist. It's something users can actually use to do something meaningful. If there's no transaction of value — if users aren't solving a real problem with it — it's not an MVP.
Learning. An MVP exists to answer a specific question: "Does this core assumption hold?" If you can't articulate what you're trying to learn from shipping the MVP, you haven't scoped it correctly.
When an MVP is the right choice
Build an MVP when:
The core assumption is unvalidated. If you don't know whether users will pay for this, whether the problem is real, or whether your proposed solution is how people want to solve it — you need to validate before investing in a full build.
You're entering a market for the first time. Even experienced founders and product teams make wrong assumptions about new markets. An MVP limits the cost of being wrong.
You're resource-constrained. When budget and time are limited, an MVP prioritizes learning over feature completeness.
The feedback loop is short enough. An MVP only works if you can get it into users' hands and collect real feedback quickly. If your sales cycle is 6 months, "ship an MVP and learn" is a much slower loop.
When an MVP is the wrong choice
There are real situations where shipping an MVP is the wrong strategy:
Regulated industries. In fintech, healthcare, and other regulated sectors, the minimum viable product may still require significant compliance infrastructure. You can scope the feature set aggressively, but you can't skip the compliance layer.
Enterprise B2B with high switching costs. Enterprise buyers making a €50k+ annual commitment expect a certain level of product maturity. Shipping an MVP to enterprise prospects often results in "come back when you're more complete" — which means you've burned a prospect without learning much.
Safety-critical systems. Anything where a bug has real-world consequences (medical devices, financial infrastructure, autonomous systems) cannot be shipped as a "minimum viable" anything.
Reputation-sensitive launches. Your brand's first impression is the hardest thing to recover from. If the MVP is so minimal that users will judge the company as incompetent, it may cost more than the learning is worth.
What a "full product" actually means in this context
A full product (relative to an MVP) is one that:
- Handles the full range of use cases your target users will encounter, not just the happy path.
- Has the infrastructure to support growth (multi-tenancy, role-based access, integrations, performance at scale).
- Is production-grade in terms of reliability, security, and data integrity.
- Has onboarding that doesn't require manual intervention.
The decision between MVP and full product is not binary — it's a spectrum. The question is where on that spectrum to land for a given context.
A framework for the decision
Answer these four questions:
1. What is the riskiest assumption in this project? Not the most interesting one — the most likely to be wrong. The assumption, if false, that would invalidate the entire investment.
2. What's the simplest test of that assumption? Sometimes an MVP app. Sometimes a prototype. Sometimes a 5-person interview study.
3. What would a buyer of this product expect to see? Not every buyer, but your specific target buyers. What does "credible" look like to them?
4. What's the cost of being wrong at each level? If you build an MVP and it fails, you've lost €X and Y months. If you build a full product and it fails, you've lost more of both. Is the additional information worth the additional investment?
The answers will usually point clearly toward MVP (unvalidated assumption, patient buyers, limited resources) or full product (validated demand, impatient buyers, regulatory constraints, brand risk).
The best product strategy is the one that answers your biggest question with the minimum investment. Build what you need to learn what you need to know — then build more.
inviqon helps startups and scale-ups scope the right product for the right stage. See our product strategy service.
