No Skateboard Company Has Ever Become a Car Company | PM Toolkit

Why product development's most beloved metaphor misleads more than it teaches.

The Most Shared Image in Product Management

Ask anyone in product to explain iterative development and they'll pull up Henrik Kniberg's skateboard-to-car illustration within minutes. 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.

It's one of the most shared images in the history of product management. It is also, at any meaningful level of product complexity, wrong.

Try this in your next product strategy discussion where the skateboard image surfaces: ask the room to name one skateboard company that became a car company. The room always goes quiet. Because the answer is zero.

Tony Hawk did not pivot into motorcycles. Razor scooters did not evolve into Ducati. Trek bicycles did not become BMW. These are different businesses with different engineering, supply chains, customers, and economics. The metaphor collapses under its own logic.

What the Illustration Gets Right

Credit where due. Kniberg's core principle is correct: every release should solve the user's actual problem end-to-end, even if crudely. Building a wheel and handing it to someone who needs transportation is waste. That insight has saved countless teams from componentized delivery where nothing works until everything works.

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

But a teaching metaphor from a conference talk has been mistaken for an operating manual by thousands of product teams. When you run product at scale, across multiple markets, on multi-sided platforms, the gaps become serious.

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. Each transition in the bottom row is a complete rebuild wearing the costume of incremental progress.

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, you're not iterating. You're rebuilding from scratch, possibly multiple times.

It Conflates Discovery with Delivery

This is Marty Cagan's most pointed critique. The skateboard model encourages teams to use engineers writing production code as their primary tool for learning. Strong product teams separate discovery from delivery.

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

Cagan has observed teams spending four months building an MVP when the same questions could have been answered in a week. Competent product teams in discovery mode should be testing 15 to 30 iterations per week. If you're shipping one skateboard per sprint, you're doing expensive, slow discovery and calling it agile.

Architecture Does Not Iterate Linearly

Twitter launched on Ruby on Rails. Right choice for a small team in 2006. But as it scaled, Rails couldn't keep up. The "Fail Whale" became a symbol of architectural limits.

Twitter didn't iterate Rails into a scalable system. They rewrote their backend in Scala, rebuilt their message queue, and replaced their search engine. The result was a 3x drop in search latency and the ability to handle over 300,000 tweets per minute.

The skateboard didn't become the car; Twitter threw it out and built something else. That is the norm.

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 isn't a "skateboard version" of one with fifty thousand merchants. It's a ghost town. You can't test whether a dining marketplace works by giving restaurants a skateboard booking tool when they already have Chope or SevenRooms.

The bar for viability is set by the competitive market, not by your iteration count. Platforms need to seed supply, solve for liquidity, and often subsidize one side before any real learning happens.

What to Do Instead

Start with Your Riskiest Assumption

The Riskiest Assumption Test (RAT) framework, proposed by Rik Ingram, flips the MVP sequence. Instead of build-measure-learn, you learn-measure-build. 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 tested demand with a landing page before building anything. Airbnb tested willingness to stay in strangers' homes with air mattresses before building a platform.

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. Each ring adds capability, but the core architecture, user mental model, and market category stay the same. You're not changing the vehicle class with each iteration. You're expanding within the same product.

Ride-hailing platforms didn't start as skateboards and become cars. They went from one vehicle type to many. Transport, then payments, then delivery, all on the same core platform.

Adopt Kniberg's Own Evolution

Even Kniberg has moved past the skateboard. He now talks about Earliest Testable Product (ETP), then Earliest Usable Product (EUP), then Earliest Lovable Product (ELP).

This framing is more honest because it admits the first release isn't a product at all. It's a test. Calling it a "skateboard" gives it too much dignity and sets the wrong expectations with stakeholders.

The Real Job

The job of a product leader is not to ship skateboards. It's to systematically reduce uncertainty about value, usability, feasibility, and viability before committing scarce engineering resources to production code.

The skateboard metaphor encourages teams to skip this work and jump straight to building. That isn't lean discovery. It's expensive discovery dressed up as agile.

Next time someone pulls up the image in a product review, ask them: which skateboard company became a car company?

Sources

Henrik Kniberg, "Making Sense of MVP" (blog.crisp.se, 2016)
Marty Cagan, "Skateboards vs. Cars Revisited" (svpg.com)
Rik Ingram, "The MVP is Dead. Long Live the RAT." (HackerNoon, 2016)
Kit Friend, "You Can't Make a Skateboard into a Car" (Medium)
Delivery Hero Engineering, "Minimum Viable Product: Why Do You Really Start with the Mythical Skateboard?"

Prerequisites