It’s been one too many times that I’ve seen the famous skateboard, scooter, bike, motorcycle, and car image by Henrik Kniberg, which he says is about (agile) “product development in general”. I’ve finally figured out what bothers me about it so much. I’ll argue that the underlying mental model is at best not helpful and at worst actively misleading for product development, despite the article making a couple of excellent points and presenting great examples. Hiding in Kniberg’s own text and examples is a better mental model: vertical slices.

Let’s remind ourselves of the (in)famous image quickly before we go further.

This image illustrates the key metaphor presented in the article. Attacking a metaphor always runs the risk of attacking a strawman by taking the metaphor too literally. Still, it is fair to examine the metaphor as such to evaluate whether it’s even a helpful way of illustrating Kniberg’s core thesis. Then, I’ll also critically evaluate the mental model that underlies the metaphor. A mental model guides our thinking and consequently our decision-making. When it is flawed, it can lead us to make bad decisions.

The Good

At its core, the original article argues that rather than building incomplete pieces of a grand vision, start with a simple solution that already delivers real user value. Evolve testable, usable, lovable versions through feedback. This avoids wasted effort and leads to a better product than executing a fixed upfront plan.

Gathering user feedback frequently and using it to iteratively improve your product during development is great advice. Understanding actual user needs is hard enough as it is and almost impossible in isolation. We all know the “If I had asked people what they wanted, they would have said faster horses” quote often attributed to Henry Ford¹ and there’s much wisdom in it. Continuous feedback informing us of how aligned we are with the user needs is indeed invaluable. I think, as a framework for product discovery, this is great. It also shines when used as a mental model for getting us to actually commit to the earliest testable/usable/lovable/… version of a product. This prevents us from optimizing something to death in an ivory tower.

Digging Deeper

And yet, something just feels off to me about this skateboard-to-car metaphor. Of course! No car manufacturer started with a skateboard, right? Sure, but that’s just taking the metaphor uncharitably literally. So does the skateboard just mean simpler car? That also feels wrong. In Kniberg’s article, the skateboard is described to the customer by saying “don’t worry […] We’re still aiming to build a car, but in the meantime please try this and give us feedback”. So the metaphorical skateboard is a stepping stone on the way to a car.

In the article, the first thing that the customer would get delivered in the Not Like This section is a single wheel of a car, which is of no use to them. In the Like This section, a skateboard is shipped to them. They are potentially not happy about it, but it’s definitely something that they can use and provide feedback on. So usable is one important property of a metaphorical skateboard. Obviously, it’s also simpler than a (metaphorical) car. And thirdly, it’s self-contained. It’s not a partial car, in fact: it’s not even part of a car! You could give a partial car to users to test it, and as a matter of fact that’s pretty much what I’ll argue later, but still Kniberg chose to go with a skateboard. Those notions of self-containedness (is that a word?) and independence are where, I believe, things start to unravel.

Let’s dig into the examples in his text and see if we can understand what Kniberg could mean by skateboard…

The Examples

I’ll try to keep this short, because this is shaping up to be a long article, but we do need to talk about the examples in the original article briefly. For the Spotify example, Kniberg writes:

“developers basically sat down and hacked up a technical prototype, put in whatever ripped music they had on their laptops, and started experimenting wildly to find ways to make playback fast and stable”

He goes on to explain that they focused on the singular metric of latency to make the product viable and used friends and family to test it. I can definitely see that this is pretty far from what Spotify is today (or even at the time the article was written), but why not just leave it at prototype? Is a skateboard a prototype for a car? Hardly. I’d argue the same is true for the Minecraft example presented in the article ².

The Big Government example in the original article is a great case study of how they released a very narrowly scoped initial version (with respect to both capabilities and distribution) and built on the gathered feedback. However, I don’t see how that first version is a skateboard except for it being a much simpler, stripped-down version compared to the releases that came after. But again, a skateboard is not a simpler car, it’s not a partial car, it’s not part of a car.

All this is to say that the examples in the text are excellent examples of good development practices that led to great products, but none of this has anything to do with the skateboard-to-car mental model and all to do with vertical integration.

A Skateboard Isn’t a Simpler Car…

it’s a simpler mode of transportation! I hear you shout at your screen, shaking your copy of the Agile Manifesto at it. But let’s think about it. The Spotify “skateboard” was built around specific commitments in the realm of low-latency music streaming. Later increments were built on top of those commitments, not independently from them. The other examples play out much the same way.

One principle that I strongly believe is that successful development needs clear constraints. Just think of practical reasons like hiring decisions, funding rounds, technology choices and the like³. A concrete vision helps by constraining the solution spaces you’ll explore. And exploration doesn’t come for free. And yes, do get user feedback early and often, because it will help you align your vision with user needs.

So sure, in the most charitable interpretation, the skateboard just means to start simple and get early user feedback. None of this is objectionable, but I’d argue it’s also not very helpful for planning actual development⁴. Kniberg writes “Think big, but deliver in small functionally viable increments”. I agree wholeheartedly, but the skateboard metaphor is a very bad way of illustrating how to do that. One big problem with that article is that it tells us to deliver functionally viable increments, without explaining how to go from one step to the next systematically, other than getting user feedback. As a pure product discovery framework, this might seem useful, but there is no discovery without development.

Say you’ve identified your (metaphorical) skateboard, which, although less complex than a (metaphorical) car, will likely be a product of decent complexity. It’ll take requirements analysis, architecture decisions, actual engineering work, and much more. This is where a lot of the complexity lies. More than that, the skateboard-to-car metaphor can imply a harmful level of independence of earlier and later versions. In reality, architectural decisions will compound and components will be shared across iterations. In that sense, the metaphor doesn’t just fail as a guide for development: at worst, it actually points in the wrong direction.

Kniberg does acknowledge a continuity of vision, since even at the skateboard state we’re “still aiming to build a car”, but he doesn’t explicitly acknowledge the continuity of engineering in his prose⁵. That’s how the skateboard-to-car metaphor obscures crucial aspects of the development process necessary to even get from one stage to the next.

A Better Development Model: Vertical Slices

One last time, let’s revisit Kniberg’s examples. What do they actually represent? They are thin vertical slices, which are a “narrow but complete sliver of the final product vision”⁶. They are all highly incomplete and/or narrowly scoped when compared against their later versions, but all examples show a high level of vertical integration, meaning a lot of system components from top to bottom have to work together. Let’s check how a vertical slice compares to the key properties of the (metaphorical) skateboard we identified above.

Are vertical slices usable? Yes, they are, though I much prefer testable, as Kniberg does, too. That’s actually one of their major benefits. A vertical slice through a complex system means that many modules will have to work together successfully. Thus, you really get to pressure test those interfaces, which is where a lot of the breaking points of a system are. Sure, it’s easy for a team to deliver a brilliantly polished module, but that’s worthless without seeing if their assumptions and the formal interface specifications (you do have those, right?) hold up in reality. Fail early here and iterate, to save yourself a lot of costly rework later.

Are vertical slices simpler than what comes after? Of course! Are they self-contained? Yes, that’s a byproduct of pursuing vertical integration, but they aren’t independent from later versions, nor should they be. They enable us to get early feedback, but they definitely aren’t what a skateboard is to a car, and we should all free ourselves from the idea that incremental versions have a high degree of independence. Your versions, of course, won’t be independent from each other, that’s the whole point! You’re building something incrementally. Thinking of vertical slices helps us remember that we are iterating towards a (possibly evolving) vision incrementally rather than building solutions of increasing complexity independently from each other. Vertical slices make it clear that the decisions you make in the early stages will have an impact on the later stages. Vertical slices aren’t a new idea, and spelled out like this, all of this may sound banal, and yet the skateboard-to-car metaphor exists. This article isn’t about inventing a new development practice. I’m pointing out what Kniberg’s examples already show, and arguing that the popular skateboard-to-car metaphor obscures a better mental model.

And now for the final question: does this mental model help us plan development? Absolutely. If we prioritize verticals, then this helps us slice our work into manageable chunks. Prioritize narrow goals which require high vertical integration and work towards them. Remember Kniberg telling us to “Think big, but deliver in small functionally viable increments”. Vertical slices help you achieve exactly that. They force end-to-end integration and thus requirements have to be concrete enough to implement, interfaces have to be specified and actually used. Foundational architectural decisions can’t be deferred, but they also don’t have to be made all at once. This allows you to test internally, both manually and automatically, ideally through all levels of integration. You’ll catch wrong assumptions while it’s still cheap to correct them, and can ultimately deliver a product early.

Conclusion

The examples in Kniberg’s original article are all excellent illustrations of good development practices. What made them work wasn’t the skateboard, it was the fact that the early releases were all thin, integrated vertical slices. Gathering early user feedback was used to inform future iterations. Those were incrementally built on the engineering decisions in their predecessors. The skateboard metaphor obscures that part. If you think “skateboard”, it’s easy to forget that earlier versions lay the groundwork for their successive increments.

Think “vertical slices” instead. They are simpler, testable, and most importantly: you’ll be forced to make decisions that lay the groundwork for subsequent increments. To my mind, that’s a better mental model of a good incremental development process, and one that’s both well-known and worth repeating.

Endnotes