What Is an MVP (Minimum Viable Product) in Software Development

Q: "What is an MVP minimum viable product in software"

"An MVP (minimum viable product) is the simplest version of a product that delivers enough value to real users to generate meaningful feedback — not a prototype, not a demo, but something a real customer would actually use. The 'minimum' part is consistently misunderstood: it means minimum features, not minimum quality."

An MVP — minimum viable product — is the smallest version of a product that solves a real problem for real users well enough that they’ll actually use it and give you meaningful feedback. Eric Ries popularized the concept in The Lean Startup, and it’s been the most misunderstood term in product development ever since.

The core idea is sound: instead of spending 18 months building everything you think customers want, build the smallest thing that tests your most important assumption, put it in front of real users, and learn. Then iterate. This is genuinely good product strategy. The problem is in the execution.

Why the Term Gets Misused

There are two common failure modes, and they’re opposites:

Failure mode 1: The MVP is too minimum. A landing page with a sign-up form is not an MVP. A clickable prototype is not an MVP. A demo that only works when the founder is driving it is not an MVP. These are validation tools, and they’re useful, but they’re not products. An MVP has to deliver enough value that someone would use it repeatedly — or better yet, pay for it. If your “MVP” requires you to explain away all the things it doesn’t do, it’s not viable.

Failure mode 2: The MVP is too maximum. The team adds “just one more feature” for six months until the MVP has 40 features, took a year to build, and no user has touched it. This defeats the entire purpose. The point of an MVP is to learn fast with minimal investment. If you’re building for a year without user feedback, you’re not building an MVP — you’re gambling.

What Minimum Actually Means

Minimum means minimum features, not minimum quality. This distinction matters enormously. Your MVP should do fewer things, but the things it does should work well. Users will forgive a product that doesn’t have a feature they want. They won’t forgive a product that has the feature but it’s broken, slow, or confusing.

A good MVP has: one core workflow that works end-to-end, enough polish that users can figure it out without hand-holding, and enough reliability that it doesn’t crash during the demo. It does not need: every edge case handled, a beautiful onboarding flow, admin tools, analytics dashboards, or a mobile app.

What It Means Practically for Your Business

It’s a learning tool, not a product launch. The MVP exists to test your riskiest assumption. If your assumption is “small businesses will pay $50/month for automated bookkeeping,” your MVP needs to automate bookkeeping well enough for a small business to actually use it. It doesn’t need to support every accounting standard, integrate with every bank, or handle multi-currency transactions. Those come later — if the core assumption proves true.

It should be scoped in weeks, not months. If your MVP will take more than 8-12 weeks to build, you’ve included too much. Go back to the assumption you’re testing and strip everything that isn’t essential to testing it.

It requires honest feedback loops. The whole point is learning. That means putting the MVP in front of real users (not your friends, not your investors, not your team) and watching what they actually do — not just what they say. If users sign up and never come back, that’s data. If they use one feature obsessively and ignore the rest, that’s data. If they ask for something you didn’t build, that’s data.

How to Tell If Someone Is Misusing the Term

“Our MVP will take 12 months.” That’s not an MVP. That’s a V1.

“We’ll build the MVP and then launch.” The MVP is a launch — to a small, targeted group of users. If you’re treating the MVP as a step before the real launch, you’re thinking about it wrong.

“We need to add X before we can show it to anyone.” This is the most dangerous sentence in product development. Unless X is “basic functionality that makes the core use case work,” you’re over-building.

“Our MVP just needs to look good enough.” Design matters, but an MVP doesn’t need to be beautiful. It needs to be functional and clear. Spending three weeks on visual polish before you know if anyone wants the product is a misallocation of resources.

The Verdict

The MVP concept is one of the most valuable ideas in modern product development — and one of the most frequently butchered. Done right, it saves you from the two most expensive mistakes in startups: building something nobody wants, and building too much of something before you know what “right” looks like. Done wrong, it’s either an excuse for shipping garbage or a label slapped onto a full product that took way too long to build. Keep it simple: what’s the riskiest assumption, what’s the smallest product that tests it, and how fast can you get it in front of real users?