ne of the mantras of post-modern software development and agile delivery in general is to fail fast, fail early. The thinking behind this approach makes total sense but can seem counter-productive, especially to teams who might be more used to traditional approaches.
“Why would you want to fail? We want our project/product/software to succeed!”
This is a common concern and has a simple, if somewhat abrupt answer. If you think your product/project/software will be a success because your last one created was great, or because you have spent months researching and discussing with clients, then be careful, it may not turn out quite that way! The simple truth is that nobody, not me, not you, not Mark Zuckerberg, not the investment angels, nobody really knows what users will take up and what will be successful.
Granted some designers and product managers have better ideas and seem more successful than others. But I bet you £3 that their success is based on some form of failing early. They might be really good at explaining the concept to potential users, or they create mocked-up visuals, or prototypes or have some way to get early feedback.
“Early and continuous feedback during the product development lifecycle is the point, and is the key to success.”
Only through constant feedback can you really discover if your product is on the right track. If it is, then great, if not the we need to think again or potentially even drop the solution and start from the beginning. This may happen at any point in the cycle, but with an iterative approach and constant feedback it is less likely to happen at the end and this it the point. Early feedback tell can help you understand you need to think again and it makes sense that, if this is going to happen, then doing so at the beginning of he investment rather than at the end makes sense. At least that is what I want to happen with my products, this way I make sure my teams are effective and creating value.
A more traditional approach to product development might still involve speaking to users, creating mock ups etc but then would move into the development stage and the feedback stops because the team is “busy engineering” at least up until QA time. Consider making a car, you might build:
- The chassis
- add wheels
- add a body and paint work
- add the engine
This would certainly deliver a car but the user would not be able to know what ‘what it felt like’ unit step 4. If it is not what they wanted then we have failed and failed late after all our investment and all the time spent building the damn thing!
A different approach might at first feel a little strange at first, instead of building a car bit by bit we are going to iterate a transport device and instead build:
- a skateboard
- a scooter
- a bike
- a motorbike
- a car
The reason this feels odd is that we are building four separate products. In the first example we build on the previous stage but in the second we don’t, well not physically maybe but we do conceptually and this is why it works. With a skateboard I can show it to customers, it is faster than walking but it does not help me get the kids to school and the shopping home. But that is not the question we are trying to answer here, we just want to know if this ‘transportation device’ is going in the right direction (forgive the pun).
If it is, great, what do we need next? How about ‘something to hold on to so we can push a bit harder’ maybe? Great, lets add some handlebars. That works what next? Well how about if we add pedal power? And so on, and so on.
Going back to our car manufacturing analogy for a moment, it is true that if we then want to ramp up production of the final product that we would then need a different approach, creating tens of thousands of vehicles by starting with a skateboard would clearly be madness. But I think it is the manufacturing analogy which has caused the situation in the first place. Most physical engineering has to consider the best way to build and this can get in the way of the product’s evolution. This is not the case in software engineering as there are many different ways to remove the fluffy outer coating from a feline.
A natural approach when considering a new product or service is to conceptualise it in its entirety and then build it block by block. But this approach does not work so well and is not really necessary when building software. If we remove the need to deliver a specific product in a specific way then we create space for inventive thinking from all the team, and this is when the best innovation happens which can lead to better products which our clients will be happier with and then so will we. Another often benefit is that we might decide that we don’t need a car after all a bike will be just fine! Now we have a great product, our client has saved money and everyone is happy!