Failing fast, using feedback loops, and the benefits of iterative design
Some useful principles to help you succeed with any new endeavor.
The concepts covered in this article are ones I’ve learned through my work as a software designer at IBM. You can read plenty of articles about how these ideas apply directly to startups, but I believe they also apply to pretty much any area of life, so I thought I’d explore them here in more general terms.
Fail fast
This term is taken from the lean startup methodology; if you’re not already familiar with it, here’s a quick summary (source here):
Fail fast is a philosophy that values extensive testing and incremental development to determine whether an idea has value. An important goal of the philosophy is to cut losses when testing reveals something isn’t working and quickly try something else, a concept known as pivoting.
Picture the following scene: you set out on a walk in the woods and decide to follow a circular route you’ve not walked before. All is going well until the way ahead of you splits into three paths. You know that one of the paths continues the circular route you’ve been walking, but you don’t know which one (and there are no signs, maps, phones, or other people around to help). You decide you’ll simply have to pick one of the three paths and hope that it’s the correct one. If it turns out not to be, you figure you’ll simply have to walk back to this junction and try one of the other paths instead.
Now, if you think about this scenario, it’s quite likely (a two-in-three chance) that the first path you happen to pick will turn out not to be the one you want. Furthermore, if it is indeed a wrong path, then the sooner you discover this and turn back, the better; for every step taken along a wrong path takes you further from your desired destination.
As with walking, so too in other areas of life. Whenever we try new things, we rarely get them spot on first time round. Now that’s perfectly okay, but once we recognize that some level of failure is pretty much inevitable, it becomes clear that failing (or, more specifically, realizing that we’ve failed) sooner rather than later is hugely to our advantage. For failing fast is really failing cheaply and intelligently.
It’s such a simple concept, yet so often people don’t do this; they fail really slowly and expensively — like when they launch a new business venture that they’ve spent three years working on, only to find there’s no market for what they’re peddling. So, how do we take this theory and actually put it into practice?
Feedback loops
Another tenet of the lean startup methodology that helps us here is the build / measure / learn loop. Basically, if we want our bad ideas to fail quickly, then we’d be wise to intentionally and regularly create quick prototypes that we can test.
Image you’ve come up with a new business idea — say to offer a camera drone service to enable house owners to see the state of their roofs, chimneys, and gutters. One of your key assumptions is that people will be willing to pay for such a service. So, before you buy a camera, apply for a drone flying license, or create a website, a simple test you could carry out would be to approach 100 house owners to gauge interest in the idea.
Another example: One of my hobbies is brewing beer. One of the things I like about brewing is being able to experiment with the huge range of ingredients, variables, and beer styles that are available. However, I also want to produce beer that my friends and I actually enjoy drinking. So I’m careful to record all aspect of the brewing process (the ingredients, quantities, timings, temperatures, etc.), then when the beer is ready to drink, we rate the aroma, clarity, taste, and strength. This simple feedback loop helps me learn what impact different ingredients, timings, and temperatures have on the end result.
So we always aim to fail fast and to continually increase our knowledge by intentionally building in regular feedback loops. What next?
Iterative design
Iterative design is really just a fancy way of saying upfront that we in no way expect our first attempt to nail it. Nor our second, and probably not our third. From the outset, our mentality is that we will quickly come up with several designs or prototypes and test them in order to get rapid feedback, with the understanding that this might well require us to rework some or all of our previous attempts. Basically we set out on a journey of discovery, wanting to learn more at each step along the way — and we are not precious about the prototypes we produce en route.
Note that what I’m calling a prototype here doesn’t need to be a physical asset; depending on the context, your “prototype” could simply be the bright idea you put into words to share with others, or even a set of behaviors you try out, such as intentionally running your work meeting in a different format to see whether it enhances engagement. The point is that it’s something that you do or share with people in order to gain feedback.
In keeping with the fail fast philosophy, iterative design helps us develop our idea / product / behavior / etc. quickly and incrementally.
A simple example to demonstrate these concepts
I wanted to provide a worked example that combined all these ideas, so on Saturday morning I identified some potential research participants (my two daughters) and asked them if they would be happy to help me with a quick piece of research. Before they had a chance to answer, I quickly mentioned that the research essentially involved playing with Lego and that chocolate-based rewards were on offer. I soon had two willing participants.
I told them that their challenge was to build a strong Lego tower, using the Lego boards, blocks, and flags I provided.
I then explained that we’d be defining a tower as strong if it could withstand a steel pétanque ball being rolled into it from across the rug.
What I didn’t then do is let them loose to work away on their projects in isolation for the next two hours, then come and judge the end results. That kind of “waterfall” approach to the project would not have enabled the girls to benefit from failing fast, using feedback loops, nor iterating over their designs. That would in effect have given them just one shot at success.
Instead, what I did was tell them that they had just 5 minutes to work on an initial tower and that I’d then stop them so that we could test their progress.
Prototype 1: When the 5 minutes were up, my youngest daughter, Hattie, had managed to build a tower with a flag on it (even if it did look suspiciously like a staircase). But was it a strong tower?
Test: I gave Hattie the steel ball, and asked her to roll it into her tower to see if it would withstand the impact… Unsurprisingly, it did not.
What we learned: A staircase-style tower is not very strong.
At this point, I offered some feedback. I explained that having all that weight going out from the base of the tower made Hattie’s structure quite unstable and suggested she build blocks more directly on top of each other in the future to make her tower stronger.
I then set the girls off on another 5 minute tower-building sprint.
Prototype 2: Hattie’s next tower was indeed built with blocks placed directly on top of each other, and was arguably stronger than her first. But would it be strong enough?
Test: The tall, thin tower toppled and broke. Fail.
What we learned: A tower with individual blocks stacked directly on top of one other has a better center of gravity and is somewhat stronger than the staircase-style tower, but is still not strong enough to withstand the steel ball.
I then introduced the concept of staggering the joins between bricks from row to row, explaining that this made the structure stronger and is in fact how real brick walls are typically built.
Prototype 3: My older daughter, Thea, built a tower using this newfound knowledge, which certainly seemed stronger than the previous two prototypes.
Test: Sadly, rolling the steel ball into the front of this “wall” style tower still resulted in the tower collapsing.
What we learned: Overlapping bricks into a wall-like structure provides greater strength. However, even a strong wall-like structure is susceptible from an impact to its front or back.
I then explained that a box shaped structure like a house (i.e. one that has height, width, and depth) is even stronger than a straight line wall-like structure.
Prototype 4: The girls then worked on a new prototype together, using all of the principles they had learned so far. At the end of the 5 minutes they had made a pretty robust looking tower.
Test: Hattie took the steel ball and rolled it across the rug into the tower… and the tower stood firm! Success.
What we learned: By combining all of the learning points identified in the feedback loops, the girls now knew how to successfully build a Lego tower that is strong enough to withstand having a steel ball rolled into it.
In this experiment, the girls had a clear goal and immediately had ideas about how to achieve that goal. However, crucially, I set up regular, simple tests to help them see whether their current prototype was really on track to achieve their stated goal. Then, whenever a prototype failed a test, the girls were able to reflect on that and learn quickly from their “failures” (admittedly with a fair bit of guidance from me). This regular prototype-then-test approach encouraged them to move away from ideas that weren’t great and to try out new ideas instead (i.e. to “pivot”).
This structured approach resulted in fast, incremental improvement (each tower they produced was better than the last one) and ultimately led to success. And the key point is that this progression happened as quickly and efficiently as possible. The girls put in just enough time and effort into each prototype to allow them to test it. This meant that they regularly benefitted from real data, which either validated or invalidated their current assumptions and plans.
With thanks to my colleague Eric Morrow who has taught me much about many of these principles. You can read how Eric put this approach into practice in his article: Prototyping IBM Design Thinking Method Cards
Tom Waterton is a Content Designer at IBM based in Hursley, UK. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
