You know that graphic about building a car that goes through steps from skateboard to car as the Right Way to Do It? I’ve always been bugged by something in that. To wit: each of the five steps is its own fully realized engineering project. They’re arguably smaller than the build a whole car project, but they also don’t meaningfully build towards it. So if you know you need a car, you’re wasting effort to offer a really good skateboard or an okay bicycle. By the time you delivered a car, your customer’s living space is filled with other transportation options. Maybe they didn’t want any of this optionality at all!
In other words, it’s a crappy metaphor, because if product managers or consumers actually used this process for transit-to-the-stores, both sides would end up very unhappy. Wasted effort, wasted production, new problems of storage or disposal, and the customer spends untold time trying out poor solutions instead of jumping straight to a good one. In the physical world, products you don’t use are a problem after you buy them. They end up dragging on your space, budget, and psyche.
There are three keys to using this graphic correctly: the vendor doesn’t know the customer needs a car, the customer doesn’t know that the vendor could make a car, and software projects that fail to meet the customer’s need can be deleted.
Asymmetry of knowledge from vendor to customer
It’s not that the vendor doesn’t hear the customer saying “I want to go to the shops three miles down the hill from here and buy several days worth of groceries and some books.” A given customer’s ask is clear, and could be solved without building anything: that’s called professional services, or in this metaphor ordering a Lyft. Rather, the asymmetry is produced by vendor characters, probably executives or product managers to be frank, who are trying to reshape the customer’s ask into something they can repeatedly sell. Services are linear, products are exponential, capitalized companies greatly prefer products. Can we build a bus or tram service and partially meet the needs of many similar customers by forcing pickup/dropoff locations and a timetable on them? How do we optimize for the fact that engineering has made a bunch of small, extremely low-friction wheels? What if the customer would like to have the optionality of going lots of places whenever they want? Oh, many people don’t have a private garage, noted… What if we have an interview note that mentions the joy of bombing down a hill at speed, can we tell ourselves that is more important than easily carrying several heavy bags back up the hill? Here’s your skateboard, I’m pretty sure it’s what you need, let me know if that doesn’t work and we’ll try again in the next development cycle. With this first attempt the vendor has failed. Might be a good skateboard, but they haven’t found a way to make a profitable, repeatable product that adequately serves the needs of enough shopping-bound customers to define a market.
Asymmetry of knowledge from customer to vendor
It’s entirely possible to produce the same situation in the other direction, though in my opinion this is also usually a vendor flaw. The vendor uses structured feedback systems and surveys that normalize feedback and hide important details. However, it is theoretically possible for a customer to not realize that the vendor they’re working with has the ability to provide exactly what they really wanted. In this model, the customer proposes solutions within an envelope of what they think the vendor is able to do. “Really great skateboard, I appreciate how long it is because I can bungee cord all my shopping into a huge wad and balance it on top of the board while I push that up the hill to my house… do you think you could add a small motor to the board so it’s easier to push? Maybe some bungee cord attachment points too? Because sometimes my groceries fall off.” Instead of asking for a cargo e-bike or a small car, the customer in this case asks for weird modifications to the existing product because they’re trying to work within what they think the vendor can do. This is what people mean when they say to ignore customer solutions in feedback, “faster horse” and all. Unfortunately, all too often that idea is used as an excuse to ignore real needs.
Software ages like milk and most of it should be deleted
This is an uncomfortable statement for those of us who make our living in the very expensive space of creating enterprise software, but that doesn’t make it less true. Markets and design requirements have cycles, solutions that are largely the same keep getting rebuilt from scratch in slightly different ways, architecural patterns shift around while the problems remain largely the same (hint: reduce cost, reduce risk, expand capability, in that order). Code is easier to write than read, and sometimes the correct answer is to toss it out and just start over. When you’ve delivered a skateboard to solve “I want to go to the shops three miles down the hill from here and buy several days worth of groceries and some books”, the correct answer is rm -rf skateboard.
Reading Henrik Kniberg’s post again, it’s not wrong when considered as a path to building an enterprise software tool. Being able to do a typical enterprise task, such as “safely move several terabytes from here to there” can start off slow and difficult to use, then incrementally improve. Delivering a single-threaded script now is often better than delivering a microservices castle in nine months. That said, this post is just one in a long series complaining that the skateboard to car metaphor is bad. One of the things you learn in humanities is that metaphors really do matter, they shape the way that people think. This metaphor is not doing a good job of explaining agile principles and it needs to go away.
More reading:
Monkeynoodle.Org 