Skip Mockups When Building Skateboards

If you need to deliver a usable product version in two weeks, you should stay away from mockups.

To explain more, I need to start with a software development picture from Henrik Kniberg that I keep seeing more and more frequently:

This picture teaches us that iterative product development doesn't mean that we deliver the final product in unusable parts to our clients. Instead, iterative product development should mean that we try our best to deliver usable versions of the product that we are building.

When building a car for the purpose of moving around in the world, our first deliverable isn't a car tire—it's a skateboard. This might feel like a useless or an unproductive development step. But it's actually a step towards true learning and meaningful software.

We can't give our client a car tire and learn about how they use it to transport themselves. A car tire won't enable you to move around. Our clients can't test their product assumptions with a tire.

The skateboard is different. Our clients can use the skateboard. When using the skateboard, our clients will learn more about what are the most important things about transport in general. We the developers will learn how our clients actually interact with a vehicle.

The problem with mockups

When a client comes to you with a goal or a problem they need to solve with software, your first design step should be to figure out what's the smallest useful thing that you can build for that client. When you have that figured out, you can start thinking about the minimum amount of functionalities and requirements needed to deliver something useful.

If your first design step is to open Sketch or Adobe XD on your computer, it's very likely that the north star of your design process won't be the smallest possible usable thing. Instead, you will draft a non-embarrasing version of a product and let that guide your development.

We don't turn mockups into actual software with one iteration. High-definition mockups are never that small in scope. Because of this, we break mockups down into smaller parts; we figure out in which order to build the final product. Our deliverables become car tires and not skateboards.

Additional notes

This post is mainly inspired by a discussion between Ben Orenstein and Adam Wathan on Full Stack Radio.