Product bloat is killing digital experiences.

On this episode of The Frictionless Experience, Chuck Moxley and I explore why MVP culture often reinforces the problem, how product bias misleads teams, and why continuous measurement (not one-and-done validation) is the only path to truly additive product value.

When "Validated" Features Become Bloat

In product teams everywhere, MVP culture and product bloat are quietly conspiring against the customer experience. Not intentionally but inevitably.

Because when you validate each new feature in isolation, you rarely pause to assess what you displaced to make room for it. That's how product bloat happens.

Maybe you validated the recommendations carousel at the top of the page. Great. You proved it was "super valuable." But then sponsored products performed better in an A/B test, so you moved recommendations down the page.

You got the win. But your results are no longer additive because you removed the original value of recommendations.

Which begs the real question: Is that carousel at the bottom still doing anything? Or is it just sitting there, validated once, forgotten forever?

This is the philosophical core of our latest episode of The Frictionless Experience, "The MVP Myth That's Breaking Product Teams."

And the conversation took us to three interconnected truths:

1. MVPs aren't the problem.
2. Product teams misuse MVPs because of product bias.
3. Product bloat is the downstream symptom of teams that stop measuring.

Let's break down how we got here and more importantly, how we fix it.

The Real MVP Problem: We've Prioritized "Minimum" Over "Viable"

In the episode, I said something that frames this whole debate:

"It's the definition of the MVP that matters the most here because you're really thinking about what is minimum viable. Define that." 

And the truth is, most teams define "minimum" based on what's fastest for developers, not what's most meaningful for customers.

As I told Chuck: "The minimum is going to be defined by the developer pretty much exclusively."

Why? Because at most organizations:

• Developers define what is feasible quickly
• product trims scope to meet deadlines
• Leadership wants velocity
• and "minimum viable" becomes "it works, ship it."

Which leads to MVPs that are "done" but never actually viable.

In another episode of The Frictionless Experience, our guest, Nakul Goyal from Carfax, reframed MVP as a Minimum Lovable Product, which sounds great. But as I put it:

How Product Bias Turns MVPs Into Permanent Half-Products

Even worse than poor definitions is the psychological trap product teams fall into: product bias.

As I explained on the show:

One of my favorite real-world examples came from a conversation with a director at a major brand who described A/B testing like this:

"He said that the concept of AB testing is called finding the green. You're literally looking through the data for any indicator that says this is green." 

That's product bias in its purest form.

You're not validating whether the product is truly valuable. You're validating whether you can justify launching it.

And this is how MVPs become permanent. Not intentionally, but because the story around them becomes more valuable inside the organization than the product value itself.

Product Bloat: The Inevitable Outcome of Misused MVPs

When teams stop reassessing older features, product bloat becomes the natural byproduct of constant "wins."

On the podcast, I summarized this dynamic:

"Product bias allows itself to create product bloat, when you have feature over feature over feature that exists on a page or a site or a platform."

Here's the scenario I broke down which mirrors countless real product orgs:

1. You validate a recommendations carousel at the top of the page.
2. Later, sponsored products perform better — so you move recommendations down.
3. Sponsored products get the credit for winning.
4. The recommendations feature stays deployed, taking up space.
5. Nobody re-measures whether it still adds value.

As I said in the episode:

"Is the recommendations carousel that's now at the bottom still taking up time, still adding to the page weight, adding to the bloat? Is it as valuable or is it less valuable or is it more valuable?" 

This is where product bloat comes from — not from adding features, but from never removing or reassessing them.

And the root cause is simple:

Teams don't continuously measure old features because the culture rewards launching new ones.

The Culture Problem Behind MVP Misuse

A lot of criticism of MVPs is actually criticism of culture.

In the episode, Chuck read a popular LinkedIn post from a CMO, Clark Barron, who said:

"I hate the very concept of producing a minimum viable product with every fiber of my being. When a company builds an MVP, they force marketing to make unfinished things look finished."

To which I responded:

"I think it's missing the point. This is like the difference between shipping CDs and shipping a website nowadays. I can iterate on a website very easily."

The problem is organizations that don't iterate after the MVP ships.

And as I explained: "Value goes to where value exists. If the MVP carries value, effort will stay there. And if it is not, effort will shift."

Meaning:

• If leadership only celebrates new launches, they'll get more new launches
• If leadership rewards improvement, teams will refine the MVP
• If nobody prioritizes measurement, features stagnate
• If stories win over data, product bloat grows

Bad storytelling + ignored data = MVPs that stay broken.

Good storytelling + real measurement = MVPs that become exceptional products.

Why Data Does Guide Vision — The Rebuttal That Matters

In the episode, Chuck read a line criticizing MVP culture:

"Data doesn't guide vision. It documents hesitation."

My response: "I completely disagree with that. If you're telling me that data doesn't guide vision, what's he even saying?" 

And I stand by it.

Vision without data is ego.

If you want to build lovable experiences (like Duolingo or Revolut), you need continuous measurement not perfection before launch.

As I put it later in the episode:

That's the philosophy that prevents product bloat, not fuels it.

Duolingo and Revolut: Proof That Iteration Builds Lovable Products

Chuck brought up Duolingo's approach, summarized like this:

• Ship early
• Test quickly
• Iterate constantly
• Don't wait for perfection
• Use the right metrics

Which aligns exactly with my stance. As I said:

"You're giving me a softball to agree with Duolingo. If you are effectively using iteration, that's how everything needs to be functioning." 

Revolut takes this even further, focusing on small UX details that create an emotional connection. But as I pointed out:

"Lovable is an opinion. Define it. How do I measure the data?"

Lovable still requires measurement. You can't guess your way into delight. You iterate into it.

So What Actually Causes Product Bloat?

It's not MVPs, speed, or aggressive testing. Product bloat happens when:

• Teams celebrate deployment instead of refinement
• Nobody revisits older features
• The data is misread or manipulated
• wins matter more than impact
• Culture rewards quantity over quality
• Product bias pushes features live that shouldn't be
• Validated features never get validated again once the environment changes

As I told Chuck:

How Product Teams Can Fix the MVP Problem (Without Abandoning MVPs)

Here's what healthy product teams do that unhealthy ones don't:

1. They redefine "minimum viable" as a floor, not a loophole.

MVPs must prove something real, not simply launch something fast.

2. They re-measure older features regularly.

If you don't reassess the value of legacy features, you're shipping blind.

3. They treat data as a guide, not a justification.

Data should challenge assumptions — not support biases.

4. They reward improvements, not just launches.

Refining a feature from "2% lift" to "4% lift" is just as valuable as launching a new one.

It's all about the storytelling.

5. They hold features accountable over time.

Every feature should have ongoing KPIs, not one-time validations.

6. They avoid product bias by welcoming negative results.

Product maturity means being comfortable saying: "We tested seven features. Only one worked. We're shipping the one."

Final Thought: MVPs Aren't the Villain — Culture Is

At the end of the episode, Chuck summarized the conversation by saying:

"Your bottom line is it's all about the culture, less about the MVP."

Exactly.

Whether you produce product bloat or continuous improvement depends entirely on:

• What you measure
• How you interpret data
• What your culture rewards
• and whether your storytelling reflects reality

The MVP isn't broken but the myth around it is.

When you iterate, measure, refine, and prioritize high-minimum, high-value features, your product grows stronger over time.

When you don't?

Well, you wake up one day with a page full of forgotten carousels.