Every successful product started as a question: "Will anyone pay for this?" An MVP — Minimum Viable Product — is the cheapest, fastest way to answer that question with real evidence rather than assumption. But most founders either build too much (making the MVP indistinguishable from a full product) or too little (building something that doesn't actually test the core value proposition). Here's how to get it right.
Step 1: Define the Core Hypothesis
Before writing a single line of code, write down the one sentence that describes what you believe to be true about your market. "I believe that [target customer] will pay for [solution] because [reason]." This hypothesis is what your MVP tests. Every feature decision should be evaluated against this question: "Does this feature help us prove or disprove our hypothesis?" If the answer is no, the feature doesn't belong in the MVP.
Step 2: Identify the Riskiest Assumption
Your hypothesis contains multiple assumptions. One of them is the riskiest — the one that, if wrong, invalidates the entire business idea. For most startups, the riskiest assumption is whether customers will pay (not whether you can build the product). Your MVP should be specifically designed to test this assumption. Building a feature-rich product that avoids testing the riskiest assumption is one of the most common and expensive startup mistakes.
Step 3: Choose the Right MVP Type
Not every MVP needs to be software. The right MVP format depends on your hypothesis and what you're testing. A landing page MVP tests whether people are interested enough to sign up before you build anything. A concierge MVP (delivering the service manually at first) tests whether customers value the outcome before you automate it. A Wizard of Oz MVP (where customers think they're using software but you're doing things manually behind the scenes) tests willingness to use and pay for the service. A working prototype tests the core user experience. Choose the format that tests your riskiest assumption with the least investment.
Step 4: Set Your Success Criteria Before You Build
Decide before you launch what "success" looks like. Specific, measurable targets: 10 paying customers within 60 days, a conversion rate above 3%, an NPS score above 40, or 5 customers who use the product daily. Without pre-defined success criteria, you'll rationalise ambiguous results into premature confidence. "A few people signed up but nobody paid" means the hypothesis was wrong. Knowing this quickly is the entire point of an MVP — not something to explain away.
Step 5: Build the Smallest Possible Version
Write a feature list for your MVP, then cut it in half. Then cut it in half again. The features that remain are your actual MVP. Every feature you add is additional risk — more time, more cost, more complexity — before you've validated your hypothesis. Focus on the one or two interactions that constitute your core value proposition and build only those, built very well. Ship everything else after you've proved people want what you're building.
Step 6: Launch to a Real Audience Fast
An MVP launched to real users in 4 weeks teaches you more than a polished product launched in 6 months. Speed of learning is the startup's primary competitive advantage in the early stages. Use your network, LinkedIn, WhatsApp groups, local business communities, and cold outreach to find your first 10-20 users. These early users are your most valuable source of feedback — treat access to them as the most precious resource your early company has.
What Comes After the MVP?
If your MVP validates the hypothesis, you have signal to invest further. If it doesn't, you have information — either customer feedback that tells you what they actually want (pivot), or clear evidence that this market isn't viable (move on before losing more time and money). Either outcome is valuable. The only failure is building for months without learning anything from real customers.