Building an MVP That Actually Validates Your Business

The term MVP has been diluted to the point where it means different things to different people. Some founders use it to mean 'version 1 with fewer features.' Others use it to mean 'quick and ugly prototype.' Both miss the point.

An MVP is the smallest thing you can build to test your riskiest assumption. That is it. If your riskiest assumption is 'will people pay for this,' your MVP needs a payment flow. If it is 'will people use this daily,' your MVP needs retention tracking. Everything else is noise.

Identifying your riskiest assumption

Every business idea has a stack of assumptions. 'People have this problem,' 'they will pay to solve it,' 'they will find us,' 'we can build it,' 'we can support it profitably.' Your MVP should test the assumption that, if wrong, kills the entire idea.

For most B2B products, the riskiest assumption is 'will people pay for this?' For most consumer products, it is 'will people use this repeatedly?' For most marketplace products, it is 'can we solve the chicken-and-egg supply problem?'

What to include and what to skip

Include: the core value loop (user does X, gets Y), payment if you are testing willingness to pay, basic analytics to measure behavior. Skip: user settings, admin panels, notification preferences, social features, anything your users did not ask for.

A good rule of thumb: if a feature does not directly test your riskiest assumption, it does not belong in the MVP. You can add it later once the assumption is validated.

The 'one more feature' trap

The most common failure mode I see is founders who keep adding 'just one more feature' before launching. This is almost always a way to avoid the vulnerability of putting something imperfect in front of real users.

Launch before you are comfortable. If you are not a little embarrassed by your first version, you waited too long.