Article3 Dec 20256 min read
Skateboard, bicycle, car: ship something that moves
Nobody wants a quarter of a car. The most useful thing about incremental delivery is that every increment has to actually take someone somewhere - which is why we start with the skateboard, and why the chassis-first plan quietly fails.

Gareth turns tangled business problems into clear delivery plans, keeping strategy, engineering and clients pulling in the same direction.
There is a drawing that has done more for software delivery than most methodologies. Henrik Kniberg sketched it around 2014 and it has been quoted, adapted and mangled ever since. In the top row, a team builds a car in four steps: a wheel, then a chassis, then a body, then the finished vehicle. In the bottom row, the same team builds a skateboard, then a scooter, then a bicycle, then a motorbike, and finally the car. Both rows arrive at the same place. Only one of them is useful on the way.
The difference isn't speed and it isn't scope. It's that every single step in the bottom row is rideable. Somebody can stand on the skateboard and go to the shop. That means somebody can also tell you that the shop is in the wrong direction, that they'd rather carry things than push them, that the hill on the way is the real problem. The top row can't hear any of that, because a chassis doesn't go anywhere and nobody can use one badly enough to teach you something.
The chassis plan is seductive for a reason
Nobody chooses the top row because they want to fail. They choose it because it is the most efficient-looking way to build a car, and on a whiteboard it genuinely is. You build each component once, properly, in a sensible order, with no rework. The plan has clean edges and the estimate looks defensible, which is exactly what makes it so easy to approve.
What the plan quietly assumes is that you already know you're building a car. If that assumption holds - if the requirements are settled, the users are known and the destination isn't going to move - then building it in component order is fine, and often correct. The trouble is that this assumption almost never holds in the work we're actually asked to do, and the chassis plan gives you no way to find out that it has broken.
A chassis can't be ridden badly, so it can't teach you anything.
What the bottom row costs
Five vehicles cost more in total than one car, and some of what you build gets thrown away. The premium is not waste, it is the price of an option - you are paying to find out whether the car was the right vehicle while it is still cheap to change your mind. Where uncertainty is high that premium is the cheapest insurance available. Where the destination genuinely is settled, it is just cost, and the chassis plan wins.
A handful of decisions cannot be retrofitted at skateboard prices: the data model, the tenancy model, identity and permissions, the compliance boundary. Those get designed once, up front, for the car. Everything above them - features, workflows, screens, integrations - is where the bottom row earns its keep. Incremental delivery is not an excuse to leave load-bearing decisions until the motorbike.
What the skateboard is really buying you
It's tempting to read the bottom row as "start small", but that undersells it. A skateboard isn't a small car; it's a different vehicle that happens to solve a sliver of the same problem. Choosing it means deciding what the journey is actually for before committing to how it will be made - which is a product decision dressed as a delivery one.
- Something real in the hands of real users, early enough that their reaction can still change the plan.
- Evidence about the destination, not just progress towards an assumed one.
- A working system end to end, which means the integration risk surfaces first rather than last.
- The option to stop. If the bicycle turns out to be enough, you have already shipped it.
That last one is the most valuable and the least discussed. In the chassis plan, stopping early leaves you with nothing at all. In the skateboard plan, stopping early leaves you with a bicycle, and there are plenty of problems a bicycle solves completely. Being able to stop is what turns a budget into a series of decisions rather than a single bet.
Options only have value if somebody actually exercises them, and in practice teams almost never do - the car is on the plan, so the car gets built. So we make the stop explicit: at the end of each increment, continuing is a decision that has to be re-argued, not a default that has to be interrupted. The question is never "is the next phase approved", it is "given what the bicycle just taught us, is the motorbike still the best thing we could spend the next six weeks on".
Where the metaphor is usually misused
The drawing gets quoted to justify shipping something shoddy, and that's not what it says. A skateboard is not a broken car - it is a complete, well-made skateboard. The wheels turn, the deck holds weight, and nobody falls off it because it was rushed. Scope came down; quality didn't. If your first increment is a car with three wheels, you haven't followed the bottom row, you've just shipped the top row early.
The other misuse is treating the sequence as fixed. Skateboard, scooter, bicycle, motorbike, car is a nice cadence for a drawing, but the real sequence comes out of what each step teaches you. Sometimes the skateboard tells you the destination is close enough to walk and the whole vehicle programme was the wrong idea. That is not a failed project; that is the cheapest possible version of finding out.
How we hold it in practice
In delivery terms this means we shape each increment around a journey somebody can complete, rather than a layer of the system. We would rather have one narrow path working through the whole stack than every component half-built across the whole surface, because the narrow path can be used, demonstrated and argued with, and the half-built surface can only be reported on.
It also changes what a status update says. Instead of a percentage against a plan, an increment either carries someone somewhere or it doesn't, and everyone in the room can tell which. That is a harder standard to meet and a much easier one to trust, and it tends to end the long silent stretch in the middle of a build where progress is real but invisible and confidence quietly drains away.
None of which makes the car unnecessary. The point was never to stop at the skateboard - it was to make sure that by the time you build the car, you are building it for a journey you have watched somebody take.