I once spent six months building a product that had everything. A dashboard, customizable reports, role-based permissions, an API, email digests. We launched it to three enterprise customers. They looked at it and said, “This is nice, but can it just send us a weekly CSV?”
Six months. They wanted a CSV.
That was the moment I truly understood what a Minimum Viable Product is — and more importantly, what it is not. It is not a cheap version of your final product. It is the smallest thing you can build to learn whether you are solving a real problem. And that distinction changes everything about how you approach the Product phase of building.
What Is an MVP?
Eric Ries introduced the term in The Lean Startup. His definition: an MVP is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The key phrase is “validated learning.” An MVP is not a product strategy. It is a learning strategy. You are not trying to impress customers. You are trying to answer a question: does this problem matter enough that someone will change their behavior to solve it?
This is a subtle but critical point. If your MVP is designed to wow people, you have already missed the purpose. It is designed to teach you something you did not know.
The Three Components of a Good MVP
In my experience, a good MVP has three qualities:
1. It Tests a Specific Hypothesis
Before you build anything, write down what you believe. “We believe that busy professionals will pay $15/month for automated meal planning because they spend too much time deciding what to cook.” That is your hypothesis. Your MVP exists to prove or disprove it. Nothing else.
2. It Delivers Real Value (However Small)
An MVP is not a mockup or a slideshow. It must do something real for a real person. A landing page that collects email addresses is a test, not an MVP. A spreadsheet that generates a weekly meal plan based on dietary preferences — that is an MVP. It is small, but it solves the problem.
3. It Has a Feedback Mechanism
If you build something and nobody uses it, you have learned nothing. Your MVP needs a way to observe behavior. Do people come back? Do they share it? Do they complain about specific things? Build the feedback loop into the product from day one.
A Concrete Example: MealPlan
Let me walk through a fictional example. Imagine you are a PM at a startup called “MealPlan.” Your thesis is that working parents waste hours each week deciding what to cook and shopping for ingredients.
You have already done your customer segmentation and identified your primary persona: dual-income parents with kids under 10, living in urban areas, ordering takeout three or more times per week because they are too tired to plan meals.
You have also run customer interviews and confirmed that the pain is real. People say things like, “I know I should cook more. I just can’t deal with the planning part.”
So what is the MVP? Here is what it is not: a full app with recipe search, grocery integration, nutritional tracking, and family preference profiles. That is a product roadmap. That is six months of work. And you do not yet know if anyone will actually use a meal planning tool.
Here is what it could be: a simple web form where a user enters their family size, dietary restrictions, and budget. Every Sunday, MealPlan emails them a plan for five dinners and a consolidated grocery list. That is it. No app. No login. No recipe photos.
This version tests the core hypothesis: will busy parents use a tool that removes the “what should we cook?” decision? If they do, you know you are on to something. If they don’t open the emails, you have learned something equally valuable — and you spent weeks, not months, finding out.
The “Minimum” Trap
The biggest mistake I see teams make with MVPs is arguing about “minimum.” Someone says, “We can’t launch without onboarding.” Someone else says, “We need a proper design, or nobody will take us seriously.” Before you know it, the “minimum” viable product has 40 features and a six-month timeline.
Here is the test I use: if you are comfortable with your MVP, it is probably too big. Ries was not exaggerating when he wrote that the MVP should feel embarrassing. Reid Hoffman, co-founder of LinkedIn, put it this way: if you are not embarrassed by the first version, you launched too late. (He shared this on a Stanford lecture as part of Sam Altman’s startup course.)
The point is not to ship garbage. The point is to ship the smallest thing that generates real learning. Polish does not generate learning. Features do not generate learning. Putting something in front of a real human and watching what happens — that generates learning.
Common MVP Formats
There is no single right way to build an MVP. The format depends on your hypothesis:
- Concierge MVP: You do the work manually for a small group of customers. MealPlan’s founders could create meal plans by hand for 20 families and email them personally. No technology required.
- Wizard of Oz MVP: The customer sees a product, but behind the scenes, a human is doing the work. The interface looks automated, but it isn’t yet.
- Single-Feature MVP: You build one feature and ship it. Not the full product — just the one thing that tests the hypothesis.
- Pre-order MVP: You describe the product, set a price, and see if anyone pays before you build it. Crowdfunding platforms like Kickstarter are essentially MVP machines.
Each format has trade-offs. A concierge MVP gives you the deepest customer insight but does not scale. A single-feature MVP scales but might not reveal whether the core problem resonates.
Why MVP Matters for Product Managers
In the 5Ps framework, MVP sits at the heart of the Product phase. It is the bridge between understanding a problem (the Problem phase) and building a scalable solution.
Without an MVP mindset, teams fall into two traps. The first is building too much — investing months in features nobody asked for because they assumed they knew what customers wanted. The second is building too little — running surveys and collecting opinions but never putting a real product in front of anyone.
An MVP forces you to commit. You have to pick a hypothesis, build something real, and face the market’s reaction. That is uncomfortable. But it is also the fastest path to a product people actually want.
How to Use With AI
AI is a strong companion for MVP work. It can help you move faster through the early stages without cutting corners on thinking.
1. Sharpen Your Hypothesis
Before writing a line of code, test your thinking. Describe your target customer and the problem, then ask the AI to poke holes.
Prompt: “I believe busy parents will pay for automated meal planning. Here is my customer segment and interview insights. What assumptions am I making that I haven’t validated? What could go wrong?”
2. Generate MVP Scope Options
Once you know what to test, ask for multiple ways to test it — not just the one you already thought of.
Prompt: “Here is my hypothesis: [hypothesis]. Suggest 5 different MVP formats I could use to test this, ranging from no-code to a simple coded prototype. For each, estimate the effort and what I would learn.”
3. Write User Stories for the MVP
With your MVP scope decided, generate the user stories to build it. AI is excellent at catching edge cases you miss.
Prompt: “Here is my MVP: a web form that generates a weekly meal plan. Write 8 user stories in the standard format. Include the ‘so that’ clause. Focus only on the MVP — do not add features beyond the core flow.”
The Guardrail: AI can generate options all day. But it cannot tell you which hypothesis matters most. It does not know your market, your budget, or your team’s strengths. Use AI to expand your thinking, then apply your judgment to narrow it down. The decision is yours.
Conclusion
Building an MVP is an act of discipline. It is the discipline to stop adding features and start learning. It is the discipline to ship something small and watch what happens, even when your instinct is to make it perfect first.
The goal is not to build the smallest product. It is to find the fastest path to the truth about your customers. Sometimes that is a web form. Sometimes it is a spreadsheet. Sometimes it is you, manually doing the work for 20 people and seeing if they come back for more.
Start with one hypothesis. Build the smallest thing that tests it. Watch what people do, not what they say. Then decide what to build next.
What has your experience been with MVPs? I would love to hear about it. Comments are gladly welcome.