Why Your MVP Is Probably Three Times Too Big

When I ask ten founders to describe their MVP scope, nine of them land on something closer to a product vision than a minimum. The tenth is usually someone who has already been through one round where something got added back in.

That pattern is not a coincidence. Every choice in an early product feels important, every feature feels urgent, and every “we may as well put that in too” feels reasonable. The result is an MVP two to three times the size of what is needed to test the actual question.

This article looks at what an MVP should actually be, why features feel safe, and how to get back to one workflow that tests the real decision.

MVP as a decision test

An MVP is not a smaller version of the final product. An MVP is an instrument to sharpen one decision.

Which decision? Usually one of these:

• Do customers understand what this is about?
• Do they find the problem genuinely urgent?
• Are they willing to change their behaviour to use it?
• Are they willing to pay for it?

Every feature in your MVP scope should make one of those questions sharper. Features that do not help answer any of those questions do not belong in your MVP. They belong on a “later” list, and you have to keep that list explicit, not hide it away.

What absolutely does not belong in v1

A few things I run into in almost every too-big MVP scope:

A settings page. Customers do not yet know whether they want to use the product. You do not yet know what they want to configure. Build one setup for now that works for most customers.

Multiple user roles. Unless your product is fundamentally about collaboration. Otherwise: one role, one type of user, one view.

An admin panel with statistics. Build instead a report you run manually once a week. Automation only becomes cheaper than manual work around customer 20 at the earliest.

Localisation. For your first 50 customers it is rarely the bottleneck. English or Dutch, pick one and stick to it.

Mobile native alongside desktop. A mobile-friendly web version covers 95% of cases. Read why a mobile website often beats an app.

Advanced analytics dashboards. In the first months you know every customer personally. If they call, you know why. No dashboard needed.

None of these features is wrong. They just do not belong in v1, because none of them sharpen any of the four decision questions.

Why features feel safe

Building features feels productive. Every feature is a concrete thing you can point at. Every feature can be explained. Every feature has a name, a ticket, a definition of done.

Making decisions feels different. Decisions are intangible. A finished decision looks like a conversation that ended, not a feature that shipped. So founders tend to skip the decision work and jump to features.

The pattern works like this: something is unclear. Instead of putting that uncertainty on the table and talking it through, the team adds a feature that “works in all cases”. What was actually an open question becomes a production decision that has to come back in six months to be simplified.

Every safe feature is an avoided decision. A growing number of avoided decisions is your growing MVP scope.

Why scope grows

Besides safety, three forces almost always push scope up:

The friendly “yes”. A co-founder, an investor, a customer makes a reasonable suggestion. It looks small. It looks cheap to include. It gets added. Ten suggestions in, the scope is unmanageable.

“As long as we’re at it”. “While we’re building all those screens, we may as well do this one too.” That sounds efficient. It is usually the opposite, you add complexity to something that was supposed to stay simple.

The future customer. You build for “companies of 50 people later”, “the healthcare sector eventually”, “tablets at some point”. They are reasonable ambitions. They are just not versions of the product your first five customers use.

None of these forces is wrong. They just do not get discussed explicitly. Without that conversation, scope has no brake.

How to get back to one workflow

The exercise: write down the three to five things the first customer actually needs to answer the central question for you. Often that is not even logging in. Often it is just: “can someone perform one action and come back afterwards?”.

For every planned feature, ask: does this help answer one of the four decision questions? If not, on the “later” list. No discussion, no “let’s just add it on”.

The cynical version of this rule: your v1 is allowed to look unfinished. It is allowed to look strikingly simple. It is allowed to lack things people will later ask for. It is allowed all of that, as long as it sharply answers the central question of an early customer.

An MVP that looks polished but does not answer the question is not an MVP. It is a premature product launch drama.

The difference between credible and complete

Credible means: a customer can see this is becoming a serious product. It works where it has to work. The flow being tested feels finished.

Complete means: everything a user could expect from a mature product is there. No loose ends, no missing screens, no “coming soon” text.

An MVP needs to be credible. It does not need to be complete. Many founders mix these two and build for completeness, while credibility is enough to test the underlying decision.

Why smaller usually learns faster

A smaller MVP is faster to build, faster to launch, faster to change and faster to throw away if the assumption does not hold. Every week of earlier delivery is a week of additional learning.

That learning rhythm is the real advantage. Not the financial saving on building work, though that is real too. The most important thing is that you can complete three cycles in the time a too-big MVP takes to do one. Three cycles of customer feedback almost always produce more than one cycle of polish.

If you are uncertain about scope, you can always check it with a short independent perspective, often you will find that half of your MVP scope is actually a v2 conversation.

---

Facing this decision?

Send me the context or book a free call. We will look at the most sensible next step before you commit time, money or focus.

Book a free call → · Email directly: hello@yourstartup.expert