Introduction
Most founders think: "If we add a few more features, people will understand the product better." Usually the opposite is true.
Every extra feature increases complexity. Every extra feature delays feedback. Most MVPs are at least three times larger than necessary because founders try to prove too many things at once.
The purpose of an MVP is not completeness. The purpose is learning.
What it solves
What a small MVP actually delivers
-
Faster feedback loops
A small MVP reaches customers in weeks. A big MVP reaches them in months. The first one teaches you something; the second one teaches you what should have been built.
-
Real evidence of demand
Customers respond to what is actually in front of them, not to what is planned. A narrow product produces a clear signal, wanted or not, instead of an ambiguous reaction to a half-feature set.
-
Cheaper changes
Removing or rebuilding three features is reasonable. Removing or rebuilding twenty is a rewrite. Smaller scope keeps the cost of being wrong low enough to keep iterating.
-
A team that can ship
Small scope keeps engineering velocity high and decision overhead low. The team learns the product by shipping it, not by debating it.
-
A clearer story for customers
A product that does one thing well is easier to position, easier to demo and easier to refer. A product that does ten things badly is hard to describe in one sentence.
What it does not solve
What a small MVP does not fix
-
An unclear hypothesis
An MVP tests something. If you cannot say in one sentence what it tests, no amount of scope-shrinking will save it.
-
Wrong audience
Shipping the smallest possible version to the wrong customers still teaches you about the wrong customers.
-
Inexperienced founders avoiding decisions
MVPs are often inflated because the founder cannot decide what is core. Removing features without making the underlying decision just hides it.
-
Missing distribution
A perfect minimal MVP with nobody to show it to is still a project waiting for an audience. Distribution is a separate problem.
-
Engineering discipline
A small MVP built without tests, monitoring or basic operational hygiene is fast to ship and slow to maintain. Small is not the same as careless.
Decision tree
Six questions for sizing an MVP
Run every feature on the candidate list through these questions. The 'no's keep your MVP small enough to ship and learn from.
- Question 01
Can customer value be delivered through a single workflow?
No → Cut features until the answer is yes. Multiple workflows means multiple things to validate, design, build and support.Yes → Confirm the workflow has a clear start and end. Vague journeys produce vague MVPs. - Question 02
Can the first version solve one problem instead of five?
No → Pick the most painful problem. The other four become reasons to keep talking to customers, not reasons to keep building.Yes → Verify the one problem is acute. Mildly annoying problems do not produce strong feedback signals. - Question 03
Can the product launch without user accounts?
No → Accept the cost. Authentication, password recovery, email verification and account states add weeks of work, sometimes necessary, often not in v1.Yes → Skip them. A unique URL, a simple lookup or a CSV upload often replaces accounts in v1. - Question 04
Can the product launch without automation?
No → Automate the smallest piece that is operationally painful. Everything else can be a human in the loop for the first weeks or months.Yes → Keep it manual. Manual processes give you direct customer feedback that automation hides. - Question 05
Can the product launch without integrations?
No → Pick the one integration that is unavoidable. Each integration adds an API, a contract, a failure mode and a rate limit.Yes → Defer them. An export and an import are usually enough to test the value before integrations become real work. - Question 06
What is the smallest version that still creates value?
No → Keep cutting. If you cannot describe the smallest version, the scope is still unclear and the product is still too big.Yes → Ship that version. Whatever you build beyond it is being added before customers have asked.
Common mistakes
Five common mistakes founders make
- 01
Building for edge cases
Edge cases are real, but they are not the path to product-market fit. Build for the central use case until you have evidence; edge cases can wait for real customers.
- 02
Building for future customers
Designing v1 for the enterprise customer you might land in 18 months produces an MVP nobody wants today. Build for the customer you can reach in the next two months.
- 03
Building admin panels too early
Admin panels are quietly expensive: roles, permissions, audit logs, UI. Most early-stage admin work can be done in a database client or a spreadsheet for the first months.
- 04
Adding automation too early
Manual operational work is fast and informative. Automating it before you understand it codifies the wrong rules and creates technical debt you cannot remove without rewriting.
- 05
Adding integrations too early
Every integration is another moving part, and another team that does not work for you. Defer integrations until customers actually need them; you can usually validate the value with an export and an import.
Alternatives
Practical patterns for keeping v1 small
Four patterns that founders use to ship a smaller product without losing the point of it.
-
Single-flow MVP
Pick one path through the product, support it well, ignore everything else. Even very small products can produce strong signal when the path is sharp.
-
Wizard-of-Oz MVP
Run the back end manually behind a real-looking interface. Customers experience the product; you experience the operational cost, and learn what to automate first.
-
Concierge MVP
Deliver the value as a service before building it as a product. Slow, small, but it teaches you what to build before you have to build it.
-
Spreadsheet MVP
Run the early product in a shared spreadsheet for the first ten customers. Many startups have validated the core value of a product this way without writing a line of code.
Ronald's rule of thumb
If removing a feature does not destroy customer value, remove it from the MVP.
The default direction of scope is up. Founders, designers, engineers and stakeholders all have reasons to add. Removing is a discipline. Every feature you remove without destroying value is a feature you can build correctly later, once a customer asks.
, Ronald · YourStartup.Expert
Summary
Summary
The size of an MVP is a leading indicator of how fast you will learn. A small MVP delivers feedback in weeks; a large MVP delivers a debrief in months. Apply the six questions above to every candidate feature. The 'no's are what keep the product small enough to ship.
Once the smallest version is live and customers are using it, scope expansion becomes a response to evidence rather than a guess. That is the only kind of scope expansion worth doing.
Common questions
MVP sizing, answered.
The questions founders ask before they commit to a scope.
- What is an MVP?
- The minimum version of a product that delivers value to a customer and produces a learning signal back to you. The 'M' is minimum, the 'V' is viable, and both words matter. Minimum without viable is a demo. Viable without minimum is a product. The MVP is the smallest version that is still genuinely useful to the customer in front of you, nothing more.
- How long should an MVP take?
- Most MVPs should ship in six to twelve weeks. Anything longer usually means scope is too large or hypotheses are unclear. A short cycle keeps the team learning quickly and keeps the cost of being wrong low. If your estimate is more than three months, the most useful thing you can do is cut features rather than extend the schedule.
- How many features should an MVP have?
- As few as possible while still solving the customer's one problem. A useful test: if a feature could be removed without destroying value, it does not belong in v1. Most MVPs have one core workflow and three to five supporting features. Beyond that, every additional feature is borrowing time from validation and lending it to assumptions.
- Should an MVP be scalable?
- No. An MVP should be reliable, not scalable. Scalability addresses problems that only exist at volume; an MVP needs to work for the first 50 or 500 customers, not the first 50,000. Build the simplest stack that runs the product, monitor it, and rebuild for scale only after you have demand to justify the rebuild.
- When should I add more features?
- When you have evidence, not opinion, that the next feature matters. Evidence looks like multiple customers asking for the same thing, churn caused by a specific gap, or a clear pattern in usage data. Without evidence, every added feature is a guess, and each guess compounds. Wait until customers tell you what is missing.