#5 – Why I Don't Always Build MVPs (And What I Do Instead)

This post is part of my series From Vision to Value, where I explore the strengths and blindspots of popular product approaches through a systems lens.

Today’s focus: the MVP. A powerful concept when used well — but one that too often ends up too minimum to be truly viable.

The MVP Gospel

The Minimum Viable Product has become product scripture.

If you’re a founder or product manager, you’ve heard it ...

What’s the minimum amount of features for an MVP? We just need to get something out, and we’ll add to it later.

There’s truth in that.

MVPs can save time and money.

They can get you into the market earlier.

But here’s the trap I’ve seen again and again:

Just because it’s minimum doesn’t mean it’s meaningful.

The MVP Culture Problem

Lean methods encourage teams to move quickly and test market adoption beyond the lab conditions of a PoC.

But in practice, many MVPs aren’t testing anything real.

I’ve watched founders pour effort into “minimum” products that still burned through cash, only to discover the system they were entering would never adopt them.

Research from Pendo found that

80% of features in the average software product are rarely or never used — representing nearly $30 billion in wasted development spend .

The shadow side of MVP culture is products launched fast, with lots of “minimum” features, never create lasting value.

Here’s the problem:

• The “V” in MVP is supposed to mean viable.

• Yet by chasing minimum features, teams often strip away the very qualities that would make the product viable in the first place.

Too often, MVPs are designed in isolation.

They validate a feature, not the experience.

They measure usability, not survivability.

They ignore the friction of the wider system they’re meant to fit into.

Why I Use MVJs Instead

Instead of MVPs, I help teams build MVJs — Minimum Viable Journeys.

A MAP is:

• Minimum → enough to test behaviours, blockers, and adoption dynamics.

• Viable → grounded in system clarity, not just user preference.

• Journey → least amount of steps to 'conversion'.

MVPs ask: Does this work?

MVJs ask: Does this fit?

Case in Point

A client I worked with had been circling the idea of a digital membership product for years. They had research, feedback, and insights piled high.

But they couldn’t move forward because

• Audience segment too broad.

• Needs too vague.

• No clear sense of what an MVP should look like.

• Every attempt went too big, too fast.

When we zoomed out to the wider system, the answer was already in front of them, existing tech inside the company that could be pivoted cheaply and quickly.

We honed in on a specific persona, cut back to a stripped-down journey, and focused on the minimum journey

• Get them through checkout.

• Enrol them in a bare-bones membership.

• Use that touchpoint to have real conversations.

• Gather feedback, shape the next steps.

The result?

A low-cost, high-learning MVJ that didn’t just validate the idea of membership, but showed the right way to build it inside their system.

That wasn’t an MVP in the Lean sense. It was a MVJ.

MVP vs MVJ

	MVP	MVJ
Definition	Minimum Viable Product	Minimum Viable Journey
Focus	Functionality	Flow to conversion
Tests	Usability	Conversion & Survivability
Validation	Assumptions	System Fit
Measure of Success	Early usage	Adoption signals & repeatability

An MVP is a product-led test.

A MVJ is a system-led journey test.

Why This Matters

On paper, MVPs look like progress.

You can point to something shipped, features released, users clicking.

It feels like momentum.

That’s why product culture gravitates to them - speed becomes a proxy for success. Executives love the optics of “we’re in market,” teams love the adrenaline of shipping, and investors love to see something tangible.

But speed without adoption is wasted effort.

An MVP might prove you can build something.

An MVJ proves you can take someone somewhere - through the messy system of choices, frictions, and behaviours - and get them to value.

• Founders: MVPs can give you false confidence that people want what you built. MVJs reveal whether people will actually complete the journey.

  
  

• Product teams: MVPs drive iteration on features. MVJs drive iteration on flow, which is where adoption lives or dies.

  
  

• Innovation leaders: MVPs are attractive because they show output. MVJs show outcomes.

Innovation rarely fails because the product didn’t “work.”

It fails because the journey didn’t fit the system people live in.

Final Word

I’m not against MVPs. Used well, they’re powerful. But they’re incomplete.

MVPs test if something works.

MVJs test if it works in the world.

And in the end, journeys beat features every time.

If you’re planning an MVP, let’s pause and look at the journey instead.

Book a Systems Discovery Call and we’ll test whether you need an MVP, an MVJ, or something else entirely — before you commit your resources.