Ship the skateboard
The MVP lesson about skateboards to rocket ships survives because it's right and almost nobody follows it.
There’s a model we reference often on product teams. Two rows of drawings. In the first row, a team building a car delivers a wheel, then a chassis, then a body, then finally the car. In the second, the team delivers a skateboard, then a bike, then a motorcycle, a car, and then a rocket ship.
It shows up on enough slides that it’s easy to go numb to it. The point underneath is sharp and almost universally ignored: in the first row, nothing works until everything works. In the second, every single release does something.
Nobody can ride a wheel.
Why teams build wheels anyway
Sequencing by architecture is comfortable. Build the database, then the API, then the admin, then the interface, then launch. It matches how the system is shaped, it lets each specialist work in peace, and it defers the scariest moment (a real person using the thing) to the very end, when it’s too late for their opinion to change much.
Ordering the work by usability is uncomfortable, because you have to hand someone a skateboard and stand there while they tell you it isn’t a car. You knew that already. It stings anyway. The wheel never gets that kind of criticism, and that’s precisely the problem: nobody can disappoint you with feedback about a thing they can’t use.
What a usable release buys you
Three things, and each one beats completeness.
Real feedback, to start. People can only react honestly to something they can actually use. Hand them the skateboard and they’ll teach you about steering, balance, and where they truly wanted to go: lessons that transfer straight into the bike. Give them a chassis and they’ll nod politely and say it’s coming along.
Second, the option to stop. Budgets get cut, priorities shift, companies change their minds. A team that’s been shipping usable releases walks away from a canceled project with something alive in the world. The wheel-first team walks away with parts.
Third, morale, which sounds soft until you’ve lived the other version. Eight months of building with nothing anyone can touch is a long time to sustain belief, and belief is the actual fuel of a project, the thing that gets people to care about the details when nobody is checking. A thing that rolls, however modestly, feeds the team that built it.
Finding your skateboard
The test is blunt: what’s the smallest thing a real person could use, end to end, to get somewhere they couldn’t get before?
Not the smallest component. The smallest journey.
Cut scope by journey, not by layer. One audience instead of four. One workflow that runs all the way through instead of six that each run halfway. A checkout that handles the common case cleanly and hands the edge cases to a human, for now, on purpose. The layers-first instinct will keep whispering that it’s wasteful to build a small complete thing you’ll partly replace, and the whisper is even right about the code. It’s just wrong about everything else: the learning, the momentum, the option to change course while changing course is still cheap.
When we are focusing on MVP, we like to tell our clients: If we are going to build you a skateboard, it will be the best one on the road…
One clarification the sketch deserves, because it gets misread: a skateboard is not a worse car. It’s a complete skateboard. MVP, yes, but finished quality. The trucks are tightened, the wheels spin true, and someone can actually ride it to actual places. Teams sometimes hear “ship early” as permission to ship something broken, and that’s a different mistake wearing the same t-shirt. The move isn’t lowering the bar. It’s shrinking the thing the bar applies to.
And hold the line on the word “usable.” If a release can’t be used, it isn’t a release. It’s inventory with a version number.
The middle is the point
None of this argues against the car. The car is still the destination, and nobody wants to run a company that ships skateboards forever.
The argument is about the long middle, the stretch between the first commit and the finished thing, which is where most projects actually live and where some quietly die. Spend that middle as a team with something rolling, or spend it as a team with a very promising wheel.
Only one of those can steer.
