That ‘Skateboard to Car’ image really grinds my gears

Written By Robin-Yann Storm

The famous ‘Skateboard to Car’ image, Originally Created by Henrik Kniberg

The original idea is that if you give a user just a wheel and then ask them what they like or dislike, then there's nothing they can say to you. The users cannot test it, they cannot use it, so it’s useless to just give them a wheel.

The classic image of what not to do, by giving users wheels

If you give them two wheels, and then ask them what they like and dislike, again they can't test it! They can't use it! If you put a body on top of the two wheels again it does not work, as there's no wheel, and there's no engine, so they still can't use it. In the end you give them a car, and you ask them what they like and dislike, they seem okay with it. They can do with it what they need to. Hopefully. This is what happens if you eventually build something that users like, which isn't always the case with waterfall development. It’s a bad way of working.

So instead you give the user a skateboard first and then you ask what they like and dislike. They can't do much but they can do a little bit, so you get feedback. Then you give them a little bit of improvement, by changing it into a scooter, and again you ask them to try it out. Again you do a little bit more improvement and you find out: They they like the wind in their hair when moving! You hear feedback on what they like and dislike! Great! And so you edit a little bit more, and again you edit a little bit more, and you end up at an end solution that the user is really happy with.

Iteration makes us better understand the users’ needs

So because of proper iteration we arrived at a better end solution. The original solution was a car, but the better end solution with iteration was a slightly different car. The end result is different and the user likes it a lot more. That's the idea of this image in a nutshell, created by Hendrik Kniberg. It's a great way of teaching folks how to do iterative development. It makes sense. It is the idea of the minimum viable product, the MVP, where you learn what the product is as you build it.

Basically in a nutshell the ideas are:

  • You learn what the product is, as you build it

  • Your MVP should be small

  • Don’t build the whole product in one go

  • Please iterate

This is all lovely.

But! And this is a really big but!

This process does not work for replacement software.

For example: You have an old tool somewhere internally. It works, but it needs to be replaced. It has that old like 80s UI on it and it's just not that great to use. It does work! Everyone internally uses it. Every day, for critical workflows. It's a little bit like a rusty car:

You can drive this car. It works! But the amount of maintenance it requires is huge, and it constantly keeps breaking down, and it makes a lot of weird noises. It works, but you need to replace it. So, what happens a lot of the time?

A developer says: Here's a scooter!

They give it to the customer:

The customer goes: “Uh no the scooter sucks.”
Then someone in production goes: “No, just give it a shot! We're doing Agile iterative development! Just try this out.”
And the customer says: “I literally can't do my job with this.”

So why does the scooter suck? Well the scooter features are:

    1. Move from A to B

    2. Runs on electricity

    3. No physical effort

    4. Fits a person

And the car features are:

    1. Move from A to B

    2. Runs on gas

    3. No physical effort

    4. Fits multiple people

    5. Much faster

    6. Can carry a load up a hill

And especially that last one might be the base use case that users need on a daily basis. So if you compare them, you see that the scooter features and the car features overlap so little, that the scooter cannot achieve what the car does. What the car was built to do cannot be done with a scooter. And that's the really critical part to understand here:

What the car was built to do cannot be done with a scooter.

Which means that the scooter is not your MVP!

Sometimes a scooter is not your MVP

So don't build a scooter! I see a lot of companies saying things like “Yay we're doing agile production! We're using that skateboard-to-car image! That famous one!” which on a surface level sounds great, and the idea behind it is fantastic, but you cannot follow that image blindly.

Instead, if you already have a car, basically some kind of existing software that users are already using, then you need to iterate on it to build a replacement. That old rusty car might be bad, and we might to replace it, but it does do what users need to do at this moment in time. So the first MVP we have to build is a modern car. A normal regular modern car. Either as a complete replacement, or as an iteration on the rusty car, by slowing replacing the rusty elements with new and modern elements. So we build either from the ground up, or build transitionally. This new car has to do what the old car was able to achieve.

And then from there you can still be agile. We can find out the users want bigger wheels. We can find out they want a big battery to charge their devices while in the car. We can find out they want a tent on top of the car, great! We are still gather feedback at each point. We build, and try things out with users, and only after trying things with users do we build more features:

And so through doing this process we find out the original car wasn’t what users need anymore. What they actually need nowadays is a big SUV with a tent up top:

Great! We still find out what we need to build through an agile process of trying things out and iterating on it. But we have done that by not starting with a scooter.

You don't always start with a scooter. Instead, you look at the base features of the current software you have and then you build an MVP that does the things that already does. Or at least enough of them that the users can do daily workflows. Then you iterate from there.

Please stop blindly building scooters every time. And then blaming either users for being obtuse, or for the agile process to be bad. You’re just using both wrong.

Stop building scooters all the time, please

So when it comes to this image of the ‘Skateboard-to-the-car”, the takeaways are:

    1. MVPs are more complicated when building replacements to existing software

    2. Do not follow the ‘Skateboard to Car’ MVP model blindly

    3. Iterate on the current needs of the user. Don’t just give them the super duper minimal version that doesn’t do what they need it to do.

Thank you for reading! If you enjoyed this post, you can find my talks here, and my other posts here. You can also subscribe below to get updates when a new post is published. There is also a video version of this article that you can find below.

Robin-Yann Storm
Previous

“Why is our new tool not being used?”
Next

Video: "How to think about workflows when designing tools."