Your MVP Is a Test, Not a Tiny Product

Most teams treat the MVP as a shrunken version of the real product. They cut a few features, ship a smaller thing, and call it lean. Then they spend two quarters building it and still learn nothing they could not have learned in two weeks. The word "product" is the trap. An MVP is a test. Its job is to answer one risky question about whether people want what you are making. Once you see it that way, the whole timeline changes, and so does what you choose to build.

Name the one assumption that could kill you

Before you build anything, write down the belief your whole idea rests on. Not ten beliefs. One. The riskiest one. If that belief is wrong, nothing else matters, so test it first.

Sergey Krasotin, who has mentored over 100 startups, is blunt about this in his piece on testing an MVP in two weeks: teams drag out testing because they misdefine their value proposition, underrate the risks in their hypothesis, and pile on extra features. His rental app case makes it concrete. Instead of building full 1% cashback into the platform, they emailed 100 users a $20 credit for paying rent early. Over 80% took it. One risk, one cheap test, real signal.

Your Monday move: pick the single assumption that, if false, sinks the idea. That is what your MVP tests. Everything else waits.

Match the test to the question, and go small

Once you know the question, you rarely need to write much code to answer it. There is a whole menu of ways to get signal, and the cheap ones often work best. Netsolutions splits them into low-fidelity and high-fidelity methods, and the low end is where the two-week timeline lives.

Think landing pages, explainer videos, and manual work behind the curtain. Dropbox posted a video showing how the product would work and went from 5,000 to 75,000 signups overnight, before the software was done. Zappos founder Nick Swinmurn bought shoes from local stores by hand to prove people would buy footwear online. Appinventiv catalogs 21 ways to test an MVP, including the manual-first "Wizard of Oz" run and the single-feature test. The lesson repeats: fake the backend, test the demand.

Don't build automation to answer a question you can answer with a spreadsheet and your own hands.

Cut features until it hurts, then cut one more

The fastest way to blow your timeline is to treat every idea as essential. James Zhao calls this idea paralysis in his piece on getting to an MVP faster, and his fix is a workshop, not a meeting. Dump every feature idea on a board. Give people a limited number of voting dots so no one can vote for everything. Then plot each feature on an ease-and-impact chart.

You are hunting for the features with the most impact for the least effort. That short list is your MVP. When a core feature is too costly to build, put a landing page where it would go and count the signups. Duolingo launched with four languages and simple translation drills, not the app it is today. That was enough to move.

The point Zhao makes is worth sitting with: you cannot build the "right" MVP because there are too many unknowns. You are setting up a feedback loop between users and your decisions. Ship it sooner, learn sooner.

Decide what a yes looks like before you ship

A test with no threshold is just a vibe check. Before you launch, write down the number that means keep going and the number that means stop. Krasotin's rental team had it: over 80% took the offer, so scaling was a safe bet. Dropbox had it in signup counts.

Pick your signal to match your method. A landing page gives you signup rate. An ad campaign gives you clicks and cost per lead; Appinventiv notes you can start with $100 and see if anyone bites. Customer interviews give you honest talk you cannot get from a survey, since people sugarcoat online but open up face to face. Pre-orders and crowdfunding give you the strongest signal of all, money, because a pledge is a vote of confidence.

Write the pass and fail numbers down before the test starts. Otherwise you will read whatever result you get as good news.

The deep cut

Easy to miss: the MVP is not the thing you are validating. The assumption is. The build is disposable. Zhao says it plainly, the goal is not the "right" product, it is an effective feedback loop. That reframe changes what you build on Monday. You stop asking "how do we make a smaller version of our product" and start asking "what is the cheapest thing that answers our riskiest question." Often that thing is a video, an email, or a person doing the work by hand. The team that internalizes this ships tests in weeks and keeps its runway. The team that skips it builds a small product for two quarters and learns nothing until the money runs low.

Three questions for your team

• What is the single riskiest assumption our idea depends on, and could we test it this week with a landing page, an email, or manual work instead of code?
• How small can this MVP actually be? Run the dot-vote and ease-and-impact exercise, and cut anything that is not testing our core question.
• What exact number means we continue, and what number means we stop? Write both down before we ship, so we cannot talk ourselves into a false yes.