Skateboards vs. Cars – How to Get the Product Right

Real cross-functional product teams are lacking in many organizations. All that exists are engineering teams to see to product development, with just about anyone playing the role of a product owner. Henrik Kniberg’s article on product development, using skateboards and cars as metaphors, makes a useful guide for such organizations that rely only on engineering teams.

The said article does apply to real cross-functional teams as well, but with some slight modifications. The underlying idea of taking advantage of minimal versions to build the right product remains relevant. So what is a better way to approach development when we have a true cross-functional product team?

Skateboards and Cars

In his popular skateboard-to-car article, Kniberg includes an image that seems to show the right and the wrong way to develop a car. The Agile coach, however, indicates that the picture didn’t just relate to car development but product development in general, with a car merely serving as a metaphor. Agile product development offers an alternative to the Waterfall approach that involves taking time to build the “right” product and only shipping when that is done. It instead takes an incremental tactic to build the correct product, using the learning that is made along the way to do better. It entails shipping in small increments.

However, Agile implementation in development can be flawed sometimes. This can happen if all we do is deliver increments that are useless to the user. It’s like shipping a tire or a partial (non-functional) car to a customer that wants a car. Kniberg recommends first trying to understand the underlying need of the customer that wants a car instead. This could be to just have something to move from point A to point B. A car isn’t the only option in such a case.

We could build a skateboard (the minimum viable product) and get feedback from users to know what we can do better. We use customer feedback to guide development until we finally arrive at a car, or the right product.

Product Discovery is Critical

As good as Kniberg’s analogy was, skateboards don’t always end up becoming cars – even though they’re only metaphors. Teams behind many successful products first had a clear idea of the kind of product they’re looking to create before building anything. They only improve on earlier releases in subsequent ones when using the Agile methodology.

The skateboard-car analogy suggests working in iteration, which is a common practice. But a problem with the approach suggested is that engineers’ time is used to work on each iteration to test on users to get a better idea of what would work for them. Several iterations (plus a lot of time) may be needed before we get something that works as intended. Essentially, we will be putting too many resources on the line for these learning iterations. There’s a better approach that we could have taken instead, especially when we have a cross-functional team.

We can cut down on a lot of waste by first doing product discovery before building the first version. As Marty Cagan advises, we should take our time to identify inherent risks so that we’re in good stead to tackle them appropriately. It is critical to give due attention to the value, feasibility, usability, and business viability of the product.

The discovery process helps us to make good use of our engineers’ time and creativity. It offers a means of honing ideas by grasping more clearly the problems that customers have. Why does the customer want a car and should we build one? The process aids in zeroing in on the underlying need. During product discovery, we use developers more for their opinions rather than coding. They come in to help determine the feasibility of what we’re contemplating and how we can improve it. We don’t even need to build anything to test our ideas. Prototypes suffice. These come in different forms, including interactive wireframes or even simple sketches.

Prototypes add some form to theories and give a hint of how well we understand customers’ problems and needs. They help us to figure out the best approach to adopt in light of the identified risks. The cross-functional team can learn a lot faster while putting far fewer resources at stake with product discovery, compared to how engineering-centered teams work.

Ensuring More Seamless Delivery

When we take the time to do proper product discovery, we make it a lot easier for ourselves to build the right product. Engineers no longer need to work with as much uncertainty as would exist if we had ignored the process. They are already clear on what they would be building – the ideal product. If it’s going to be a car, what’s the point in building a skateboard first?

Clarity on what to build helps our engineers to adopt the right method. It enables them to choose what they consider the best implementation or architecture with more conviction. Prototyping done during discovery would have helped to make clear aspects that would ordinarily not be to the engineering team. Potential risks have been identified and some key questions would have already been asked. This allows us to move faster when we get to the delivery phase instead of trying o deal with these matters then.

Another benefit to identifying risks and deciding how to deal with them in advance is that it makes it easier for engineers to build in a “scalable, performant, reliable, and maintainable” way, as Cagan puts it. This will make a whole lot of difference down the line, and we don’t want to miss out on it.