MVPs: When Minimum = Meaningless

​
Almost every product manager has been told to “start with an MVP.” But what that means in practice is often a disaster. Most MVPs are just smaller versions of the thing you wanted to build anyway.

They’re scoped-down apps, stripped of value, and disguised as experiments. So instead of validating anything, you just build faster and fail slower.

They think MVP means “the cheapest version of the product you want to build.” But MVPs aren’t about launching faster. They’re about learning faster.

And if your MVP doesn’t help you learn something fundamental, then it’s not a Minimum Viable Product. It’s just a rushed product.

Your MVP should answer a question, not fulfill a roadmap item.

Let's dive deeper.

Takeaway 1: The “V” stands for viable. For the user, not the team

Let’s start with the obvious. “Viable” doesn’t mean “technically functioning.” It means that the user can extract some kind of value from the experience.

If it doesn’t deliver value, it’s not viable. If it doesn’t test your riskiest assumptions, it’s not worth building.

A fake signup flow that tests interest in a feature? That’s an MVP. A Google Form that helps customers get through a broken onboarding process so you can see where they drop off? MVP.

A half-baked version of your full product that frustrates everyone but technically “ships on time”? That’s just scope creep with lipstick.

Start by asking: what’s the riskiest thing we’re assuming here? Then figure out the smallest thing you can build (or fake) that helps you test that assumption. That’s the core of a real MVP.

Takeaway 2: Don’t confuse an MVP with a prototype

Prototypes are for clarity. MVPs are for evidence. A prototype is something you use internally to help the team align on interaction design, flow, or architecture. You don’t need a working backend. You might not even need code.

An MVP is external. It’s something you give to real users to test real behavior. It’s the thing that puts your riskiest bet in front of someone and helps you collect actual signal.

If your “MVP” is never going to be touched by a real user in a real setting, then it’s a prototype wearing an MVP costume.

This distinction matters because it changes how you measure success. A prototype is successful if it speeds up team alignment. An MVP is successful if it helps you kill a bad idea early.

Takeaway 3: Build it just enough to be believable

One of the hardest things about real MVPs is this: they’re usually fake. The best MVPs are Wizard of Oz experiments, concierge services, landing page tests, or hacked-together flows that simulate the future experience.

They look like the product. They feel like the product. But under the hood, it’s duct tape and elbow grease.

The goal is not to scale. The goal is not to ship. The goal is to answer: does anyone care enough about this to take action?

Too many product managers fall into the trap of building “the real thing” too early. They want it to scale. They want it to look polished. They want to feel like they’re making progress. But polishing the wrong thing isn’t progress. It’s waste.

Ask yourself: what’s the minimum amount of tech needed to make this test believable to the user? Then stop there. No more.

Takeaway 4: An MVP should make a decision easier

Here’s the real test of whether your MVP worked: Did it help you make a decision?

That might mean choosing which problem to solve. Or validating that a specific segment cares about the thing you’re offering. Or discovering that no one will pay for it, and moving on.

If your MVP didn’t give you new data that changed what you build or how you build it, you didn’t run an MVP. You just launched early.

This is where a lot of teams get tripped up. They run a “test” but then keep moving forward regardless of what they learn. They’ve already decided what they want to build. The MVP is just theater.

A real MVP will sometimes kill your favorite idea. That’s a feature, not a bug. If every MVP you run tells you to keep going, you’re not testing hard enough.

Takeaway 5: The business model is part of the MVP

One of the most commonly skipped questions in product development is “Will anyone pay for this?” Or even better, “Will anyone care about this enough to do anything at all?”

And yet, when teams build MVPs, they leave the value model out of it completely. No price. No commitment. No behavioral signal.

Your MVP isn’t complete unless it helps you test desirability and viability. That includes how people might buy, how you might deliver, and what kind of friction matters most.

That doesn’t mean you have to charge for your MVP. But you should be watching for signals of willingness to pay or adopt. Signups. Email replies. Demos booked. Time spent completing a flow.

The point is to stop fooling yourself. If your MVP only proves that people will click on a landing page, but not show up to the call or enter their credit card, then you’ve tested something. But not enough.

In Conclusion

Most MVPs fail to reduce risk. They’re often bloated, expensive, and too precious to abandon. But that’s not what Minimum Viable Products are for.

They’re not a shortcut to launch. They’re a tool for truth. A good MVP should tell you whether your idea is worth pursuing before you sink months into it. It should be painful to walk away from, and valuable if you do.

The sooner you treat MVPs as experiments instead of deliverables, the faster you’ll build the right thing. Not just something.

Thanks for reading. See you next week.