In this business, we must FAIL FAST! This means taking massive and continuous action using the principle of fast iteration.
- Fail Fast
A major benefit of fast iteration is you also fail fast. Failing fast means you invest less time in the things that don’t work. If you quickly find out what works and what doesn’t work, then you take action to turn it into something that does work.
Ironically, teams that fail fast improve as fast, if not faster, than those who try to get it right the first time. The reason is simple: Teams trying to get it right the first time fail as often as everyone else does. However, when they fail, they fail really slowly and struggle to pinpoint problems because they’ve changed so much at once, making it harder to identify solutions
- More Experimentation
The faster you fail, the more experimentation you can do. You can try out ideas that might not have a lot of support, but could be potential winners. This allows for an innovative environment.
Perhaps you’ve heard of Google’s 20% time? They expect their engineers to work 20% of their time on a personal project — an experiment they find personally interesting. This program has the effect of bootstrapping experimentation, so it will happen more often.
- Learn Quickly
We’ve all had the experience of sitting in meetings arguing whether something will work or not. Usually, both sides just don’t have enough data to go on, and they end up going with their gut or with the loudest arguer (for better or worse). Fast iteration helps solve this problem by giving developers a platform on which they can test quickly, helping to collect data about any outstanding questions instead of resorting to opinionated arguments.
- Provide Continuing Interest
In addition to improving your design, fast iterations may have a psychological effect on users. Those users who use your app with any frequency will notice the changes, and if the good ones stick, they’ll appreciate your ongoing efforts to improve.
The best teams not only design the changes, but design the process for introducing the change. They experiment with methods to overcome the users’ natural resistance to change, providing migration paths and clear benefits for each improvement.
- Reduced Risk
Quickly iterating helps reduce risk during design. If teams can make many small changes instead of a few larger ones, they mitigate risk because they know which changes have what effect. If a design team makes many changes at once, they have a harder time knowing which parts work and which parts don’t. When you make only one or two changes at a time, you know immediately what effect it has. Reducing risk is a valuable outcome of moving to fast iteration.