The MVP Trap: Build an Experiment, Not a Product

An MVP (minimum viable product, a simple first version to test) is not supposed to contain every feature the founder imagines. It should answer one dangerous question before the company spends months building the wrong thing.

The MVP trap starts when a founder says "minimum viable product" and hears "small product." The better translation is "small experiment."

The Lean Startup principles frame the work as build, measure, learn, with a minimum viable product used to learn quickly. Harvard Innovation Labs also emphasizes demand validation through customer discovery, active search for solutions, budget, and tests that show behavior rather than polite approval.

Name the riskiest assumption before building

Before choosing features, write the assumption that can break the startup fastest.

Maybe the risk is not technology. Maybe the risk is that small businesses do not feel the pain often enough. Maybe the user likes the idea but the budget owner will not pay. Maybe the manual process looks painful, but customers are already solving it with a spreadsheet that is good enough.

If you do not name the assumption, you will build what feels impressive instead of what needs proof.

What overbuilding looks like

Picture a founder who spends most of a year building a platform for small businesses: reports, automations, task management, integrations, analytics, and several admin screens.

When users finally see it, many are confused. The product looks complete, but most potential customers wanted one recurring function. Worse, that core function is now harder to use, because it is surrounded by features that do not matter yet.

The money spent on extra features is only part of the damage. The bigger loss is that the main learning question has become harder to answer.

The fix is painful but useful: cut the product down to one core scenario, watch users try it, and offer a paid pilot around the specific job they actually want done.

Manual tests can be more honest than software

A real MVP does not always require code. A manual service, concierge process, prototype, demo, spreadsheet, or landing page can test demand faster.

If the question is whether customers will pay to save three hours per week, you may not need automation first. You may need five target customers, a simple offer, and a paid pilot where you do the work manually behind the scenes.

That is not cheating. It is learning before scaling (business growth).

Measure behavior, then decide

After the MVP, do not ask only whether people liked it. Ask:

• did they pay?
• did they return without reminders?
• did they use the key function?
• did they invite a colleague?
• did the buyer and user agree on value?
• did the result matter enough to continue?

If the answer is weak, the decision may be iterate, narrow, pivot, or stop. The goal is not to protect the first version. The goal is to avoid protecting a mistake.

For the next steps, read how to validate a startup idea, from idea to first customer, and business pivot timing.

Scoping the smallest test worth building is one of the first things consulting for early stage founders covers.

If you want a practical MVP scope before building for months, talk it through with me.