You don’t have to be a designer to understand the principles of good product development. And if you’re interested in applying for a Tech for Good grant it’s going to pay to.
Product development is risky and complex. There’s so much we don’t know at the beginning. Even after days of user research you can’t predict how your users will respond or if your product will actually meet their needs.
That’s why building iteratively is important.
“Iterative development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles.”
So what have skateboards and bicycles got to teach us about it?
This metaphorical image from Spotify’s Henrik Kniberg (whose original article inspired this post) is quite self-explanatory. But there’s more to it than at first appears.
How we used to do it
We used to do it like this.
This is also known as Waterfall or Big Bang development. Specify all features up front then build it. But notice there’s no user in this picture, because their not involved until the end.
Why not do it this way?
- It takes a long time
- The user gets nothing they can use until the end
- No user testing is possible. You can’t test a set of wheels that size.
- The end product will have design flaws because of earlier assumptions that could never be tested. The user is unlikely to be as smiley as in the picture.
So what should we do instead?
Focus on the underlying need first
When you do this, more options become available. What’s the underlying problem and what’s the smallest, testable thing we could do to solve it (that’s better than doing nothing)?
In this case the problem is that the user wants to get from A to B. But we’re not trying to make them happy yet (that’s why in the image they aren’t). We’re only interested in learning. A skateboard is pretty simple to make and we can can ask for feedback on it. It represents the minimum testable product.
We could also give them a bus ticket then ask them about their experience.
Shorter journeys become longer journeys
The skateboard works, a bit. But for most people it isn’t going to be very usable. It’s tricky to learn and not very fast.
In the next iteration adding handlebars makes it easier to use. You can balance better and travel further. Its a scooter and its more usable. Some people call this the minimum usable product.
But it’s still tiring on the legs. And sometimes users want to travel further.
Usable turns to lovable
So you iterate again and build a bike. Its more complex design makes it better for longer journeys. OK, so you can’t use it to whizz around the office anymore, but you can get to work and across the park pretty quickly and efficiently.
And it’s fun to cycle along and feel the breeze. It’s probably the minimum lovable product.
But unless you’re a cycling enthusiast it’s still tiring to use on that weekend trip from London to Cornwall. And who wants to arrive at their Monday morning job interview sweaty?
The motorbike is enough
The motorbike solves the problem. It takes the user from A to B quickly without effort, even 200 miles away. They’re happy because they still get to feel the wind in their face.
You could stop there. You’ve actually solved the problem.
But maybe you find that some users want to travel together, or carry their kids. So you build a car without a roof, so they can still feel the wind in their face while travelling with others.
And what if it rains? Then you build a roof.
Couldn’t you work all this out in advance?
It’s easy to look at the car metaphor and think that we could have worked out what to build in advance. It’s particularly easy to think this because the car is such a familiar product.
With good upfront analysis you can work some of it out. For example maybe the original problem was about taking kids to school in the rain. You could still have started with a skateboard (or two) and raincoats, or prototyped a bike plus trailer.
But real life isn’t like that. No amount of research or analysis will tell you what’s going to happen when someone uses your product. There will always be assumptions. Our experience is that assumptions and lack of testing leads to flops and failures.
Some famous flops
- Lego universe online game - tried to build it to perfection before releasing
- Radar app - Samaritans’ app wasn’t very well tested
- Israel’s electric cars - they refused to launch until they had a full network of charging stations
Some famous successes
- Zappos - tested online shoe sales using pictures of shoes from a shop down the road
- Lego now - Lego designers have cool jobs where they get to test new characters and kits with real children first
- Spotify - tested whether they could make online streaming work consistently enough before they went anywhere near building an interface
