Where the Skateboard-to-Car MVP Metaphor Breaks Down

The skateboard-to-car illustration can be useful, but it has limits.

What the illustration shows

Henrik Kniberg's skateboard-to-car illustration explains iterative development through two sequences. The top row shows the "wrong" way: build a wheel, then a chassis, then a body, then a car. Each increment is useless until the last one ships. The bottom row shows the "right" way: ship a skateboard, then a scooter, then a bicycle, then a motorcycle, then a car. Each step delivers value. Each step generates learning.

The image makes an important point about delivering usable value early. It becomes less useful when teams treat each stage as a literal product-development path.

Skateboards, scooters, bicycles, motorcycles, and cars are different businesses with different engineering, supply chains, customers, and economics. That makes the sequence a weak model for product evolution.

What the Illustration Gets Right

Kniberg's core principle is useful: a release should solve a user problem end-to-end, even if crudely. Building a wheel for someone who needs transportation does not solve the broader need.

In engineering teams without strong product leadership, this message is valuable. It reframes the conversation from "build a car" to "solve for transportation."

The illustration is a teaching metaphor, not an operating manual. Its limits become more important in complex products, multi-sided platforms, and new markets.

Where the Metaphor Breaks Down

Category Leaps Are Not Iteration

A skateboard shares almost no components, architecture, or design principles with a car. You can't refactor a skateboard into a bicycle. Read literally, each transition requires substantial rebuilding rather than a small extension of the previous product.

When your "skateboard" CRM is a basic stamp card and your "car" is an integrated merchant marketing platform with consent management, campaign orchestration, and cross-product bundling, the work may involve substantial rebuilding rather than a series of small extensions.

It Conflates Discovery with Delivery

Marty Cagan distinguishes discovery prototypes from production delivery in his discussion of the illustration. Teams should be clear about which kind of work an early version represents.

Discovery uses prototypes, concierge tests, painted-door experiments, and wizard-of-oz simulations. None of those require production code.

Before committing to production code, use the least expensive method that can answer the relevant question. The right pace and number of iterations depend on the uncertainty, user access, and method.

Architecture Does Not Iterate Linearly

Twitter's search team documented a substantial architecture change in 2011. It replaced a MySQL search backend with a real-time Lucene system and its Ruby on Rails search front end with a Java server called Blender. The team reported roughly a 3x reduction in 95th-percentile search latency, from 800ms to 250ms.

This was a rebuild of important parts of an existing service. The product continued to evolve, but its architecture did not simply gain one small capability at each step.

Platforms Break the Model Entirely

The skateboard image assumes a single-user, single-problem product. It has nothing to say about marketplaces where value depends on network effects.

A marketplace with five merchants and ten users may not reveal how one with fifty thousand merchants will work. A basic restaurant booking tool also tests a different proposition from a dining marketplace. Customer alternatives matter when deciding what an early test can establish.

Platform tests need enough relevant supply and demand to answer the question being tested. Teams may need to seed one side or use subsidies, but a small test can still reveal useful information about customer needs.

What to Do Instead

Start with Your Riskiest Assumption

Rik Higham's Riskiest Assumption Test (RAT) framing starts with the uncertainty that matters most. Find the single assumption that kills the initiative if wrong. Design the cheapest experiment to test it: a landing page, a concierge simulation, a fake door test.

Buffer founder Joel Gascoigne describes testing interest with a two-page site before building the working application. He then added a pricing page to learn whether visitors would consider paying. These were signals of interest, not proof of paid demand.

Before you build anything, ask: "What is the single riskiest assumption? What is the cheapest way to test it?"

Think in Concentric Rings, Not Category Hops

Instead of skateboard to bicycle to motorcycle to car, think go-kart to sedan to sports car. Use the rings to ask which capabilities can expand within the same product and which require a different architecture or market proposition. The go-kart analogy also has limits; it does not guarantee that components will carry over.

Use Kniberg's more specific labels

In his 2016 explanation of the same illustration, Kniberg distinguishes Earliest Testable Product (ETP), Earliest Usable Product (EUP), and Earliest Lovable Product (ELP). He continues to use the skateboard metaphor and warns against taking it literally.

These labels help clarify what an early version is meant to establish: whether users can test an idea, use it to meet a need, or prefer it to alternatives. That distinction is more useful for planning than treating every step as a production release.

The Real Job

A product leader's job is to reduce uncertainty about value, usability, feasibility, and viability before committing scarce engineering resources to production code.

When teams use the illustration to justify building before testing key assumptions, learning becomes more expensive than it needs to be.

In a product review, identify what the proposed version will teach you, whether it needs production code, and what would have to be rebuilt in the next version.

Prerequisites