Some serious balls to write about a mistake like that. Appreciated.
I am absolutely all for the Skateboard, Bike, Car philosophy. I see a lot of value in it for projects where there’s questions around what you’re building, why you’re building and the jobs to be done.
But, I also feel compelled to mention that it isn’t the right approach for all projects. Sometimes you know you need a car. Sometimes you’ve been using cars so long that building a skateboard or a bike would genuinely be a waste of everyone’s time. There can still be smaller questions, and the need for prototypes, test code and a bit of wiggle room, but sometimes the larger portions of the project can be specced immediately.
Don't get me wrong Andrew, I love the article, but this metaphor has never been really right and it can point beginners in the wrong direction.
You can't really go from San Francisco to LA in a skateboard, so it definitely doesn't fulfill the same role as a car. They might both achieve the same goals at times, but I'd say it's dangerous to assume they always will.
I'm hoping when he talks about this approach its for new products and not existing ones. I'd imagine trying to do this for existing products (cars) would be a tough feat to get right.
Ain't no one-size-fits-all.
(Btw. this metaphor was pioneered by Spotify)
we’ve spent the past few months documenting our process. We call it Skateboard, Bike, Car. Why does it have this dumb name? Because building a product should be tangible, satisfying, and fun the whole way through.
I'm curious why you didn't attribute this concept to the original author, which as far as I can tell is Henrik Kniberg? The language you use makes it sound very much like you came up with the idea when analysing your process.
Otherwise, very interesting article.