TL;DR: Henrik Kniberg's skateboard-to-car illustration teaches a valuable core lesson—ship usable increments, not useless components. But the metaphor breaks at scale: skateboards and cars are different businesses, not iterations of each other. Strong product teams separate discovery from delivery, think in concentric rings instead of category hops, and test their riskiest assumptions before writing production code. The job isn't to ship skateboards. It's to systematically reduce uncertainty before committing engineering resources.
Why product development's most beloved metaphor misleads more than it teaches.
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.
Henrik Kniberg, "Making Sense of MVP" (2016) — blog.crisp.se
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.
I've started asking one question in every product strategy discussion where this image surfaces: 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 blueprint 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 not an iteration—it's 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.
Discovery vs. 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, wizard-of-oz simulations—none of which require production code.
Cagan has observed teams spending four months building an MVP when the same questions could have been answered in a week. Good product teams in discovery mode should be testing 10 to 15 iterations per week. If you're shipping one skateboard per sprint, you're doing expensive, slow discovery and calling it agile.
Architecture doesn't iterate linearly
The tech stack that's right for a team of five serving a thousand users is almost never the stack that works for a team of two hundred serving ten million. At some point, you don't iterate your way out of architectural limits. You rewrite.
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. 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.
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, from transport to payments to 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, then Earliest Usable Product, then Earliest Lovable Product. 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's not lean.
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?"