It’s a Great Metaphor, But It’s Still Not an MVP

Why the “skateboard-to-car” image keeps confusing product teams and how we can do better

Every few months, that now-famous image resurfaces. The one that shows a “product evolution” from:

skateboard → scooter → bicycle → motorcycle → car

It spreads quickly. It’s easy to explain. It feels like a smart way to show progress.

And to be fair, it has value:

• It shows how user experience can improve over time
• It promotes incremental delivery
• It’s visual and easy for stakeholders to get behind

But here’s the catch:

It’s not an MVP. And confusing it as such can quietly derail your product process, especially in complex environments.

What MVP Really Means

Let’s go back to the source.

A Minimum Viable Product is not about shipping value early. It’s not about progress. It’s not version 1.

It’s about learning - testing your riskiest assumption with the smallest possible experiment.

The term MVP was first coined by Frank Robinson in 2001, emphasizing building the minimum needed to validate your riskiest assumption. It was later popularized by Eric Ries in The Lean Startup, but its roots go further back, into the work of Steve Blank and the early concepts of customer development.

Ries defined it as “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

An MVP isn’t a "first version." It’s a learning tool - the simplest version of your product that enables you to test your key hypotheses.

In practice, an MVP might be:

• A fake door test or clickable prototype
• A “Buy Now” button with no backend
• A manual concierge service
• Even just a storyboard or pitch deck

If it helps you validate what matters before you commit to building - it counts.

This is the foundation of Agile methodology as well. Validating assumptions early and building on those insights aligns with core Agile principles: responding to change, embracing iterative development, and learning through real-world feedback.

It’s less about getting everything right on the first try - more about testing, gaining insights, and pivoting when necessary.

MVP ≠ First Release

Over time, especially in enterprise teams, “MVP” has become a catch-all for first working product.

And yes, that version might:

• Work for real users
• Deliver some value
• Show progress

But by the time you ship, key decisions - what to build, for whom, and why - are already in and hard to reverse.

At that point, you’ve moved from discovery into delivery. The learning window has largely closed.

The danger isn’t in building - it’s in confusing two very different phases by using the same name.

That blurs priorities. And that’s where risk creeps in.

MVP in Enterprise: Often Misunderstood

In enterprise environments, “MVP” is often used to describe the first working version - something users can interact with, something that delivers visible progress.

And that version might be:

• Well-scoped
• Aligned with goals
• Technically solid

But let’s be honest: in many orgs, “MVP” just means V1 with a limited feature set.

That’s not inherently wrong - it’s just mislabeled.

By the time you’re building that version, your key assumptions are already locked in. You're in delivery mode, not discovery.

This is why clarity matters.

In complex organizations, we should distinguish between:

• MVP → A test to validate assumptions
• POC (Proof of Concept) → A test to assess feasibility
• V1 → The first real product shipped to market

When these terms blur, so does strategy. We stop testing. We start assuming. And we expose ourselves to unnecessary risk.

Breaking Down the Metaphor

Let’s analyze what the image actually shows:

• Users get something usable early (a skateboard)
• The product improves over time (scooter → bike → motorcycle → car)
• The full vision is shipped in stages

That’s a great delivery roadmap. It assumes the user needs a car and shows how you might get there incrementally.

But real product discovery is when you ask:

“Do they even need a vehicle in the first place?”

That’s the difference. Discovery vs. Delivery.

The metaphor works well when the solution is already assumed. But real discovery means questioning whether that solution is right at all.

The image assumes the final goal - a car - is fixed. That’s a delivery mindset. MVP thinking starts earlier: questioning if the car is even needed.

Could a bike or a scooter be a better fit than a car? Does the user even want transportation, or something entirely different?

Can the Metaphor Still Work?

Yes - if each step is an experiment.

If the skateboard tests the need for mobility, and the bike tests distance or comfort, then the metaphor can support a lean, hypothesis-driven discovery process.

But let’s be honest.

Most teams use the metaphor to show staged delivery of a pre-decided solution. That’s fine - just don’t mistake it for an MVP.

In startups, the metaphor can help plan phased delivery. But each step still needs to be a test, not just a feature drop.

Are you testing a hypothesis, or just building a roadmap?

When Building Is the Experiment

In startups - or fast-moving product orgs - sometimes building and shipping is the fastest way to learn.

That makes sense when:

• Development is cheap and reversible
• Mockups or tests won’t get you real data
• Speed to market is part of your feedback loop

But even in those cases, it only works as an MVP if:

• You’re testing a clear assumption
• You’ve defined success/failure
• You’re ready to pivot if it doesn’t work

Without that mindset, it’s not an MVP. It’s just V1 - with extra pressure.

Startups win with speed - but only if the first release is grounded in learning.

If it’s for validation, it’s still an MVP. If it’s just shipping a product without testing assumptions - it’s V1. That opens the door to rework, misalignment, and wasted cycles.

So What Should We Do?

Use both models - but use them deliberately.

• Use MVPs during discovery to test assumptions, validate problems, and de-risk your bets.
• Use iterative delivery in execution to build momentum, improve UX, and align teams.

They’re both critical. But confusing them leads to:

• Misaligned expectations
• Skipped discovery
• Poorly validated roadmaps
• High cost of change later

The solution is clarity: know when you’re in discovery (MVP) and when you’re in delivery (V1).

Final Thought

The skateboard-to-car metaphor isn’t bad. It’s just misused.

For almost a decade, many of us have quietly cringed when the image is presented as the definition of an MVP.

It feels wrong - because it skips the validation step.

Henrik Kniberg, in his 2016 post “Making Sense of MVP,” clarified that the image shows iterative delivery, not discovery. He said explicitly: MVPs mean different things in different contexts.

The irony? The image meant to bring clarity has often fueled confusion.

This isn’t Henrik’s fault. His explanation was solid. The problem is how the image has been widely adopted - and too often mislabeled.

So next time someone shares that image:

• Use it to discuss delivery strategy
• Don’t confuse it with MVPs or discovery
• And always ask: What assumption are we testing at this stage?

Let’s be sharper in how we build and learn. In startups, this clarity helps you stay lean and avoid waste. In enterprises, it can mean the difference between delivering real value - or just shipping features.

How does your team distinguish between MVP and V1?

What’s one assumption you wish you had tested earlier?

Have you ever seen a roadmap built on untested assumptions?