Your MVP Is Probably Wrong (And It's Not Because You Can't Build)

Here’s a fun experiment: go to any startup community right now and count how many people are “building their MVP.” Now count how many of them have talked to an actual potential customer about the problem they’re solving.

The ratio will depress you.

The MVP used to mean something

When Eric Rios popularized “minimum viable product,” the insight was genuinely useful: don’t over-build, get something in front of users fast, learn, iterate. In a world where shipping software took months and cost tens of thousands of dollars, this was a radical idea.

The MVP was a constraint on building. You couldn’t afford to build the full vision, so you built the smallest version that could test your hypothesis. The discipline was in deciding what to cut.

That world is gone.

Now everyone can build everything

I can describe a product to an AI and have a working prototype in an afternoon. A real one. Not a wireframe — a functioning application with a backend, authentication, database, the works. So can you. So can your neighbor who doesn’t know how to code.

The barrier to building is effectively zero. And that means the MVP has lost its meaning.

When everyone can build anything fast, building an MVP is no longer a competitive advantage. It’s table stakes. The discipline isn’t in deciding what to build — it’s in deciding whether to build at all.

The validation gap

What I see over and over again — and I’ve been guilty of this myself — is the following pattern:

1. Have an idea
2. Get excited
3. Build an MVP
4. Launch to crickets
5. “Marketing problem”

Steps 1-3 now take days instead of months. Step 4 still takes forever. And step 5 is almost always wrong.

The problem isn’t the marketing. The problem is that you built something nobody asked for. And you could have learned that before building anything.

The MVP was supposed to be a learning tool. But somewhere along the way, “build fast and learn” became “build fast and ship.” The learning got optional. The shipping became the point.

What validation actually looks like

Real validation is uncomfortable. It means potentially discovering that your idea isn’t worth building before you get to do the fun part (building). Most founders skip it because building is more fun than rejection.

Here’s what it actually looks like:

Talk to people who have the problem. Not your friends. Not other founders. Actual potential users. Find them where they are — forums, communities, LinkedIn, wherever your target audience hangs out.

Listen for pain, not feature requests. If you ask “would you use a tool that does X?” everyone says yes. That’s not validation. Validation is when someone describes a problem unprompted: “I spend three hours every Monday doing Y and it’s killing me.” That’s a pain point. That’s something worth solving.

Look for existing behavior. The best indicator that a problem is real is that people are already trying to solve it — badly. They’re using spreadsheets, manual processes, duct-taped together tools. If nobody is attempting to solve the problem you’ve identified, it might not be a problem.

Test willingness to pay. Not hypothetically. Actually. “Would you pay for this?” is a useless question. “I’m building this, it’ll cost $50/month, here’s a sign-up page” — and then seeing if people sign up — is a useful test. Pre-sales, waitlists with deposit, Letters of Intent for B2B. There are ways to test real commitment before building.

Understand the market. Who else is solving this? Why are they succeeding or failing? Is the market big enough? Is the timing right? Is there a distribution advantage you can exploit?

None of this requires writing code. All of it is harder than writing code. That’s why people skip it.

The AI paradox

Here’s the irony: AI makes building easier but validation more important.

When building was hard and expensive, the MVP forced discipline. You couldn’t afford to build the wrong thing, so you had to think carefully about what to build. The constraint created clarity.

Now that building is cheap and fast, the constraint is gone. You can build ten MVPs in the time it used to take to build one. So people do. And they end up with ten products nobody wants instead of one.

The skill that matters now isn’t “can you build it?” It’s “should you build it?” And that’s a fundamentally different question requiring fundamentally different skills.

The new MVP: Minimum Validated Pain

I’ve started thinking about MVPs differently. Not Minimum Viable Product. Minimum Validated Pain.

Before writing any code:

1. Identify the pain. Who hurts? How much? How often? What does it cost them?
2. Validate the pain. Can you find 10 people who independently describe this problem? Can you get 3 of them to commit to paying for a solution?
3. Understand the existing solutions. What are they doing now? Why isn’t it good enough? What would make them switch?
4. Define the smallest possible intervention. Not the smallest product. The smallest thing that addresses the pain. Maybe it’s not even software. Maybe it’s a spreadsheet. Maybe it’s a service. Maybe it’s a two-line script.

Then — and only then — build. And build the absolute minimum that addresses the validated pain. Not your full vision. Not the feature-complete product. The smallest intervention that makes the pain go away.

The competitive advantage shifted

The founders who win in this era aren’t the ones who build fastest. They’re the ones who identify the right problem fastest. They’re not optimizing for shipping velocity. They’re optimizing for learning velocity.

How fast can you understand a market? How fast can you find real pain? How fast can you validate that your solution addresses it? How fast can you get from “I think this is a problem” to “I know this is a problem and here’s proof”?

AI can help with validation too — analyzing market data, synthesizing customer interviews, identifying patterns in user behavior. But the core skill is human: empathy, curiosity, and the willingness to be wrong early instead of wrong late.

Your MVP is probably wrong. Not because you’re bad at building, but because you built before you understood. And in a world where building is nearly free, understanding is the expensive, valuable thing.

Invest in that.