Minimum Viable Product explained for startup founders
MVP (Minimum Viable Product) is the simplest version of your product that can be released to early adopters to validate a core business hypothesis. The term was popularised by Eric Ries in The Lean Startup. The key word is "viable". It must deliver enough value that someone would use it. It is not a prototype, a demo, or a broken version of your full vision.
An MVP is not the cheapest thing you can build. It is not a landing page with an email form (that is a smoke test, which is different). It is not your full product with half the features missing. It is the smallest thing that solves a real problem for a real user. If your product is a project management tool, the MVP is not a to-do list. It is the specific workflow that your target users struggle with most, executed well enough that they would choose it over their current workaround. The bar for viable is higher than most founders think.
List every feature you think your product needs. Now remove 80% of them. What remains should be the one core workflow that delivers the primary value. Ask yourself: if a user could only do one thing in my product, what would it be? That is your MVP. Everything else is a future iteration. The hardest part is not building it. It is deciding what to leave out. Founders are emotionally attached to their feature ideas. The discipline to ship without them is what separates companies that learn fast from companies that build in isolation for months. Ship the core, measure the response, then decide what to add.
Wizard of Oz MVP: the product appears automated to the user but you do the work manually behind the scenes. Great for validating demand before building the technology. Concierge MVP: you personally deliver the service to each customer. No software needed. Single-feature MVP: one feature, done well, shipped as a standalone product. Piecemeal MVP: combine existing tools (Typeform, Zapier, Airtable) to simulate the product experience. Each type tests a different hypothesis. Pick the one that answers your most critical question with the least effort.
The MVP is not the end. It is the beginning of a learning loop. Ship it, put it in front of real users, and watch what happens. Do they complete the core action? Do they come back? Do they tell others about it? The answers determine your next move. If users love the core but ask for specific additions, iterate. If they do not complete the core action, the problem is fundamental and more features will not fix it. The purpose of the MVP is not to impress people. It is to learn whether you are building something people want. That answer is worth more than any amount of polish.