MVP · Minimum Viable Product
Minimum Viable Product
What is an MVP?
- A product as the minimum experiment for testing a core hypothesis
- Landing pages and manual services make great MVPs too
- The standard: do less, but do that one thing reliably
Adopting an MVP changes the questions asked in the meeting room. Instead of 'Won't it sell only if we include this feature?', teams first ask 'If this business fails, which assumption will have been wrong?' and attach budget and schedule only to that one assumption. In organizations that use MVPs well, the unit of a plan shifts from a feature list to a hypothesis list. The scorecard shifts too, from 'Did we build it on schedule?' to 'How much did we spend, and what do we now know for certain?'.
In practice, MVPs take roughly four forms. The landing page type opens only an introduction page, with no product, to measure the sign-up rate. The concierge type has a person deliver the service by hand. The Wizard of Oz type looks like automation on the surface while people handle the work behind the scenes. The single-feature type keeps just one core function. The boundaries with neighboring concepts are also clear. A PoC asks 'does it work technically?', a prototype asks 'is it easy to use?', and a pilot asks 'does what we built work when applied at a few sites?', but an MVP asks 'will anyone pay for this?'. That is why setting the pass mark as a number before the experiment starts is half of the design. You also have to write down the criterion for stopping if results fall short, such as '3 paid conversions out of 20 pitches within 4 weeks,' or the experiment proves nothing.
The most common misconception is treating an MVP as a 'cheap, fast official launch.' If you issue a press release for a half-featured product and sales presents it to existing accounts as a finished product, you erode the trust built over a decade or more before you have validated anything. That is why, especially in B2B, experiments should be limited to a few friendly customers and clearly labeled as test versions. The opposite trap is self-deception in validation. A friendly contact says 'Looks good, we'll use it when it's out,' and the team reports that demand is confirmed, but goodwill without payment or a signed contract is not data. The last pitfall is organizational: if failed experiments count against people in performance reviews, owners pick only hypotheses with obvious outcomes to stage a 'successful MVP,' and the experiment becomes a formality.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”Frank Robinson first used the term in 2001. It passed through Steve Blank's customer development methodology, and Eric Ries formalized it in his 2011 book The Lean Startup as a core tool of the build-measure-learn loop, which spread it worldwide.
Consider a hypothetical case. Company A, an industrial parts manufacturer with 320 employees and KRW 78 billion (≈ US$58,357,000) in annual revenue, was pursuing a 'predictive maintenance subscription service for equipment failures' as a new business. A proposal for KRW 600 million (≈ US$448,900) and 14 months, covering platform development and sensor deployment, had reached the executive committee just before final approval. Yet nowhere in the materials was there an answer to 'which plant will pay, and how much.'
- In a meeting just before sign-off, the head of the new business team said, 'We can attach sensors ourselves. The real question is whether the plant manager who controls the maintenance budget will approve a monthly subscription fee,' and proposed delaying development kickoff by three months.
- The team set '3 or more of the 20 factories we pitch sign a paid contract at KRW 1.5 million (≈ US$1,120) per month' as the pass line, and even wrote a condition to shut the business down if it fell short into the approval memo to win executive sign-off.
- Without writing a single line of code, they ran a concierge-style MVP across 8 plants for 4 weeks: two production engineers analyzed the vibration and current data received from clients in Excel once a week and sent the results as PDF reports.
- In 5 of the 8 plants, the reaction was 'the report just tells us what our maintenance foreman already knows.' The other 3 raised an entirely different problem: 'tell us the lead time for ordering replacement parts, not when the equipment will fail.'
- The team lead dropped the predictive maintenance hypothesis, pivoted to 'parts supply forecasting,' and ran a second report within 2 weeks. This time, 4 of the 6 plants approached signed a contract at KRW 900,000 (≈ US$675) per month.
- The KRW 600 million (≈ US$448,900) development budget was never spent, and the three-month experiment cost KRW 24 million (≈ US$18,000) including labor. Backed by validated demand, Company A started a scaled-down build costing KRW 180 million (≈ US$134,700) and launched with KRW 43.2 million (≈ US$32,300) in annual subscription revenue.