How to Avoid the 5 Biggest MVP Mistakes

The Minimum Viable Product is so misunderstood, but so important to get right.

I’m a fan of the MVP. Heresy, I know. 🤯

Many people have given up on MVPs. They’ve bastardized its meaning, and mangled the definition beyond recognition.

Concepts like the MVP should evolve (and they do!) New variations emerge that add valuable context to building products & creating value. Should we throw the baby out with the bathwater? Of course not.

There's Nothing Wrong with MVPs

I recently did a webinar on the 5 biggest MVP mistakes and how to avoid them (it’s at the end of the post). You can watch it (maybe at 1.5-2x speed!) and/or read on.

Mistake #1: Not Understanding the Definition of MVP

To be clear: MVP does not mean build the minimum shitty product. It never did.

Through the years, people have come up with numerous alternatives:

• MLP (Minimum Lovable Product) or SLC (Simple Lovable Complete): These added something important to the discussion—products shouldn’t suck. But lovable? I use a decent amount of software (daily!) that I don’t love (but I pay for). Love isn’t always part of the equation. 💔

• MMP (Minimum Marketable Product): Also important, because a product alone doesn’t guarantee success. Distribution is key. But “marketable” doesn’t necessarily mean valuable (i.e. you can still market crap). 📉

• SMURFS (Specifically Marketable, Useful, Releasable Feature Set): Goddamn it people! Enough already. (Nothing against Smurfs.) 😰

The term MVP has been massively misused and misunderstood, which is too bad, because it still holds merit.

Here’s my definition:

An MVP is the smallest version of a product needed to prove that you’ve solved a user’s or customer’s problem.

Let’s break this down:

• Smallest: Don’t over-build! It happens too often. But “smallest” doesn’t mean crappy.

• Product: It needs to be an actual product that’s usable (an MVP is not a landing page, newsletter signup or other experiment—those are prototypes or concepts).

• Prove + Solved: You have to quantitatively and qualitatively demonstrate your MVP is good, by validating that you’re solving a problem that actually matters. It’s a high bar.

If you use this definition of an MVP, it works.

---

Mistake #2: Not Understanding the User or Customer Problem Deeply Enough

There’s no amount of semantic Twister or creative rebranding of the term MVP that’ll matter if you can’t find a real, painful problem and solve it. Simple as that.

Doing so remains really, really hard.

You will almost certainly fail if:

• You only understand an industry superficially (how users/customers buy, budgeting, social/emotional dynamics, etc.)

• You only understand the problem superficially (you haven’t really dug into the “why”)

• You try to solve a “universal truth” (a high-level problem that everyone can see / generally knows about; i.e. “people don’t exercise enough” or “higher education is too expensive” or “everyone is taking too many medications”)

How Do You Know You're Solving a Problem that Matters?

Here’s the breakdown (but I hope you read the above post too!)

• User: Identify a narrow user/customer (generic, big markets are useless)

• Need: Identify a functional need (fairly easy to do because you can see the problem)

• Deeper Need/Tension (leading to an insight): Tough to do, but absolutely necessary. This is the “why” behind the “what.” If you only look at the functional need you’ll miss all the underlying reasoning (rational or not!) and most likely not solve the problem (or go-to-market) successfully.

Unfortunately, I’m seeing this mistake happening more and more. I blame AI (more on that later). But also too many founders don’t want to do the hard, nitty gritty work to dig in and really understand problems in a meaningful way—they just wanna build, raise money, capture some fleeting glory and … 🤷

---

Mistake #3: Not Defining the Right MVP Scope

Your MVP is meant to deliver the shortest path between a validated problem and value creation.

1. Identify your riskiest assumptions: Do this systematically, with intellectual honesty (founders love lying to themselves!)

How to Apply the Scientific Method to Startups Without Being a Zealot

2. Define the core use case: What’s at the heart of your product? What’s the core behavior loop you’re driving that will create value and encourage users/customers to repeat the behavior again and again?

Every successful product has a (relatively) small set of core features that solve the major pain point, connect perfectly with the value proposition (that you’re promoting/pitching) and generate repeat usage/value creation.

Next: Define the expected frequency of usage (i.e. how often do people need to use your product to get value?)

• Note: Usage = Value (i.e. if people are using your product it’s safe to assume they’re getting value)

• Remember: What you leave out is as important as what you include.

What is Truly at the Heart of Your Product?

The MVP is a Process Not a Point in Time

Scoping the right size MVP doesn’t end with version one. In fact, your MVP will require many iterations before you can definitively declare that you’ve solved a problem worth solving (remember the definition of MVP from earlier).

The goal of your MVP is to get to Problem-Solution Fit.

That’s when you know that you’ve:

1. Validated a real problem; and,

2. Solved it in a way that’s creating value.

This is NOT Product-Market Fit (that comes much later).

Moving From Problem-Solution Fit to Product-Market Fit

---

Mistake #4: Assuming AI Solves Every Problem

The mobile phone changed a lot (for good and bad). But many of us still have computers with big screens (I’m running 3 screens at the moment). The mobile phone didn’t destroy the computer.

AI is changing everything and quickly. It’s not the answer to every problem.

1. Vibe coding is amazing, but has plenty of rough edges

It’s amazing what you can now build with zero to little technical know-how. It’s a huge unlock. Anything that allows more people to build more things is good.

But recognize the risks. Bad habits emerge when people are handed such powerful tools with few constraints. I often hear people say, “We can build so quickly, we don’t need to interview or understand users.” Or, “Let’s add more features to the product, because we can.” 😬

AI unlocks build mode in an insane way. But it doesn’t eliminate the need for the fundamentals.

2. AI can increase efficiency in many places, but humans are still…humans

We’re in the age of AI startups. Companies are spawning like crazy that claim to fix inefficient processes through AI. Totally get it. But again, the fundamentals hold true. If you don’t understand the customer deeply and why things are the way they are, you’ll still fail, despite all your slick AI.

Replacing inefficient processes / old systems (and/or the associated humans) with AI is in the very early innings. Many startups will fail because they’re too early. Anyone remember the dot com crash? Grocery delivery in 1999 sounded insane (and it was). The infrastructure wasn’t there and people weren’t ready for it. Land grab greed caused startups to spend tens of millions to acquire fickle users that didn’t change their behavior as quickly or significantly as needed.

We won’t see an AI crash similar to the dot com bubble bursting, but some of these AI startup valuations are too high. Meanwhile more competition emerges daily, because AI is making it insanely easy to build AI startups.

Hype has a tendency to reduce common sense

With AI hype at full throttle, people are proclaiming AI as the solve for everything:

• Every company should be built faster & better with AI

• Every product should be AI-first and replace some legacy “nonsense”

Good luck flying into all of that blindly…

---

Mistake #5: Not Tracking the Right Data

Track the wrong data and you’re lying to yourself.

Here are a few common mistakes related to MVPs:

• Focusing exclusively on quantitative data. That’s a huge mistake. Quantitative data tells you what is happening, qualitative data tells you why. You need both. Never stop talking to users.

• Focusing on vanity metrics. They’re easy to track, especially after launch when there’s usually a little (or big) spike in acquisition. Sign-ups & social media mentions are common vanity metrics people promote. Even early usage may be vanity if you don’t see repeat usage. “We had 1000 people try the app!” Cool…how many are still using it a week later?

• Pretending you’re further ahead than reality. You do not have product-market fit immediately after you launch. You should focus entirely on Stickiness and the value you create (measured through repeat usage) versus anything else. It’s tempting, especially if you have a “hot startup” to focus on scale prematurely.

If you defined the MVP properly and have an “ideal usage pattern” you’re targeting, measuring value creation through usage is fairly straightforward. This takes time. You’re seeing it with AI companies now—grow fast, lots of hype, vanity metrics off the charts and then…churn. Oh oh.

---

How to Define and Build the Right MVP

Here’s a visual for how to avoid the biggest MVP mistakes. It may feel slow, but it’s not—or think about it this way, “Slower to go faster, later” (once you’ve figured a lot out).

You should:

1. Talk to users before you build (you need to understand them deeply)

2. Focus on your riskiest assumptions first and resolve those

3. Run experiments pre-MVP building (use AI to do more testing, faster)

4. Define the smallest MVP scope that you believe will solve the problem

5. Define the frequency of usage (what’s the bar you want to hit for Stickiness?)

6. Run more experiments with concepts + prototypes if need be

7. Then build the MVP

8. Then measure usage / Stickiness / value creation quantitatively and qualitatively

9. Iterate over and over and over

10. Get to Problem-Solution Fit

Feel free to skip steps. You might figure it out, but…

If you’d like to watch the full presentation and Q&A, it’s below: