Your MVP is not validating anything: common mistakes and how to build a test that works

An MVP (Minimum Viable Product) is not the simplest possible version of the product you want to build: it is the minimum test needed to falsify the riskiest hypothesis in your business model. The difference is not semantic: it changes what you build, how long it takes, and above all what you learn. Most MVPs we see at Snowinch are not validating anything useful: either they are too complete to be truly minimal, too empty to produce a real signal, or, the most subtle case, they test the wrong thing.

The starting misconception

MVP is one of the most used and most misunderstood terms in digital products. It is used to describe very different things: a landing page, a Figma prototype, a product with ten features instead of thirty, a private beta, a manually delivered service.

None of these is necessarily an MVP, and all of them could be, depending on what you are trying to test.

The problem is not the form of the MVP. It is that in most cases there is no precise hypothesis behind it. There is a product someone wants to build, and the MVP is the initial version of that product: smaller, less polished, but fundamentally the same thing.

That is not an MVP. It is an incomplete product.

The difference is that an incomplete product is evaluated by how much is left to complete. An MVP is evaluated by what you learned, and that distinction changes everything, from build order to the threshold you use to decide whether to continue or change direction.

The three wrong MVP archetypes

Archetype 1: The finished mini-product

This is the most common MVP. The founder takes the product they want to build, reduces the number of features, and calls the result an MVP. The interface is polished, onboarding is designed, there are three pricing tiers, the landing page is optimized.

The problem is that this object is not a test: it is a product. It took months to build, has real cost, and by launch the founder is too emotionally and financially invested to interpret negative signals lucidly.

Also, and this is the subtle part, a product with these characteristics rarely produces a clean signal. If conversions are low, is it pricing? Copy? Onboarding? Missing features? Distribution channel? You do not know, because too many variables changed at once.

A useful test isolates variables. A finished mini-product accumulates them all.

Archetype 2: The empty shell

This is the reaction to the previous archetype, often suggested badly: "just make a landing page and see if people sign up". The result is a page with a headline, three bullet points, and an email field.

The problem here is the opposite: the test is so empty it says nothing useful. People sign up for anything if the copy is intriguing, not because they want the product, but because curiosity costs almost nothing. A list of a thousand sign-ups on a landing page with nothing behind it does not validate willingness to pay, usability, or retention. It only validates that the headline was interesting enough to type an email.

This is not a market signal. It is a copywriting signal.

Archetype 3: Testing the wrong hypothesis

This is the most expensive, because unlike the first two it produces a signal, but the wrong one.

It happens when the MVP is built around a secondary assumption instead of the primary one. For example, the central risk of a marketplace is whether both sides meet and transact. But the MVP is built to test whether the interface is usable, whether registration works, whether notifications arrive correctly. All of this produces data, data that does not answer the question that matters.

The result is a founder who has "validated" technical and UX aspects, feels reassured by the data, and keeps building, without ever testing whether anyone actually buys anything from anyone else on the platform.

How to build an MVP that works

Building an MVP starts from the hypothesis, not the product. The order is precise and not reversible: first define what you are testing, then decide what to build to test it.

Step one: identify the riskiest hypothesis.

Every product rests on a set of assumptions. Some are trivial: people use smartphones, have an email address, know what a digital cart is. Some are critical: people would pay X to solve this problem, this segment uses this channel, the transition from A to B happens at this frequency.

The riskiest hypothesis is the one that, if false, makes everything else irrelevant. That is what you must test first, not after building the full product.

Step two: define the signal that would tell you the hypothesis is wrong.

This is the part most founders skip, and it is the most important. Before building anything, you must know which result would change your direction.

Not "if things do not go well we will revisit". But: "if in 30 days fewer than X people complete this specific action, the hypothesis is false and we change approach". This number must be decided beforehand, not after seeing results, because afterwards, any number becomes reinterpretable.

Step three: build the minimum that produces that signal.

Here the right question is not "what is the smallest version of the product?". It is "what is the simplest artifact that lets me receive the signal I defined?".

Sometimes it is a landing page with real purchase integrated. Sometimes it is a manually delivered service, the so-called Wizard of Oz, where the founder does by hand what the product will automate. Sometimes it is an interactive demo, or a non-functional prototype concrete enough to produce a real reaction. Sometimes it is a commercial proposal sent to ten potential customers before anything exists.

The form depends on the hypothesis. There is no universally correct form.

Step four: distribute the test under the right conditions.

A test distributed to the wrong people does not produce a useful signal, even if the MVP is built perfectly. If you are testing willingness to pay for a specific segment, you must reach that segment, not your generic contacts, not page followers, not people who want you to succeed.

The right conditions are those where your ICP has access to the test, can respond independently, and a negative answer is possible and recognizable.

The learning threshold, not the success threshold

The criterion for evaluating an MVP is not "did it work?". It is "did I learn what I wanted to learn?".

An MVP that produces a clear negative signal (nobody completes payment, people drop off at a specific point, the hypothesis proves false) is an MVP that worked perfectly. It did what it was built for: reduce uncertainty before investing significant resources.

An MVP that produces ambiguity (some responded, some did not, it is unclear why) is an MVP to redesign. Not because the result is negative, but because it did not produce useful information.

The question at the end of each test cycle is not "should we continue or stop?". It is "what did we learn that we did not know before, and what must we test next?".

When to stop testing and start building

There is an opposite risk to building too early: testing indefinitely without ever moving to real construction. The test becomes a way to postpone the moment when the product must stand on its own.

The signal that it is time to stop testing and start building seriously is when you have a clear answer to the riskiest hypothesis, and that answer is positive. Not absolute certainty: a signal sufficient to justify investment in the real product, with awareness that secondary hypotheses will be tested during development.

At that point the logic changes. You are no longer trying to falsify; you are trying to build something that works for people who have already shown they want it.

And that is where development, done well, becomes a multiplier instead of a risk.

What this article does not cover

We do not cover full methodologies like Lean Startup or Design Sprint: useful frameworks, but this article stays on the operational principle. We do not cover MVPs for regulated products where market testing requires legal constraints before launch. Numeric thresholds cited (e.g. 30 days, X conversions) are illustrative examples: calibrate them for segment, channel, and hypothesis type.

Operational summary

• An MVP tests a risky hypothesis; it is not an incomplete product with fewer features.
• Three typical mistakes: finished mini-product, empty shell, testing the wrong hypothesis.
• Correct order: hypothesis → falsification signal → minimum artifact → distribution to the right ICP.
• Evaluate the MVP by how much you learn, not only whether "it worked".
• Move to serious building when the riskiest hypothesis has sufficient positive signal: not when you have absolute certainty.

Tell us your context, constraints, and goals: we will say whether working together makes sense and how to set up a first step.

Email hello@snowinch.com