Read time: 7–9 min
The minimum viable product is not a half-built version of your full product. It is the smallest thing you can build that tests your most important assumption. That distinction sounds subtle. It is not. Building a bad MVP wastes months. Building the right one can change everything in a week.
What MVP Actually Means
The term was popularized by Eric Ries in The Lean Startup, building on Steve Blank's customer development methodology. The core idea: before you invest in building the full product, build the smallest possible version that lets you test whether your core assumption is correct.
The key word is not minimum. It is viable — meaning real enough to generate real feedback. A landing page that collects email addresses is not an MVP if your assumption is about whether people will actually use the product once they have it.
A paper sketch is not viable if what you need to test is whether the user can navigate the interface without confusion. The fidelity of your test must match the specificity of what you need to learn.
People believe what they can see. Ideas described in words are filtered through the listener's imagination — they hear what they expect to hear, not what you are trying to say. Prototypes, mockups, and demos are filtered through the thing itself.
The feedback is more honest, more specific, and more useful. Every hour spent making something tangible is an hour spent trading speculation for evidence.
"The best thing about a prototype you built overnight is that you are not attached to it. When a customer dismisses it in three minutes, you start again tomorrow. A six-month project is much harder to kill."
The One-Night Build Principle
When I was running Kulina, we used a technique that came from Google Ventures' Design Sprint methodology. The principle: build the minimum testable version in the shortest possible time, then put it in front of real users before your attachment to it grows.
The Design Sprint framework — developed at Google Ventures and described in the book Sprint by Jake Knapp — compresses the entire product development cycle into five days: understand the problem on day one, sketch solutions on day two, decide on day three, prototype on day four, test with real users on day five.
The insight is not the specific schedule. It is the logic behind it: the longer you spend building something before testing it, the more invested you become in the outcome, and the less honestly you will interpret the feedback.
At Kulina, we designed what we thought was a complete and elegant ordering mechanism. We were proud of it. We put it in front of users in a test. They skipped the whole thing. Not because it was broken — because it was solving a problem in a way that made no sense to them. We had spent real time on something that, from the user's perspective, simply did not need to exist. The Design Sprint logic had caught this before we spent the whole month building.
The 5-User Test — When You Have Enough
Jakob Nielsen's foundational research on usability testing established something counterintuitive: you do not need a large sample to find the most important problems with your product. Testing with five users will typically surface around 85% of the usability issues in your design.
The logic: the first user shows you things you had not seen. The second user shows some of the same things and some new ones. By the fifth user, you are largely seeing patterns that have already appeared. The marginal value of an additional user drops sharply after five. The better use of limited testing time is three rounds of five users with redesigns between rounds — not one round of fifteen users in a row.
For a venture at an earlier stage, this means your MVP does not need hundreds of testers. It needs five representative members of your target segment sitting with the thing you built. Watch what they try to do first. Watch where they hesitate. Listen to what they ask about that you never thought to explain. That feedback is worth more than any survey you could design.
What Good Enough Looks Like
The threshold for "good enough to test" is simple: can a person who did not help you build it interact with it and give you real feedback without you explaining what it is supposed to do first?
If you find yourself saying "imagine this part does X" during a test, you have not built enough yet. If the prototype requires a tutorial before it can be evaluated, you are testing your tutorial, not your product.
The question at every stage is the same: what is my most important assumption, and what is the smallest thing I can build to test whether it is true? Answer that honestly and build accordingly.
"Build to learn, not to impress. The impressive version can come after you know what you are actually building."
A Note for GVP Students
Your MVP or prototype concept for Block E does not need to be polished. It needs to be real enough to test.
The 5-user test principle is worth applying literally: find five people who match your target customer profile, put your prototype in front of them, and watch what they do without coaching them. What you observe in those five conversations will reshape your assumptions more than any amount of additional desk research.
If you are struggling to build anything testable, ask yourself: what is the single most important assumption underlying my business model? Then ask: what is the cheapest and fastest way to find out whether that assumption is correct? The answer to that second question is your MVP.
