Fast, Good, and Cheap: Choose 2 — What’s your fail strategy
Anyone that has been around software development has likely seen the titular aphorism at some point. The beauty of this statement lies in its elegance, simplicity, and truth. You can never get all three variables, though two can be achieved at the expense of the third. While most often applied to software development, this sentiment has broader application. I feel it applies equally well when it comes to a related aspect of product development — failure. It’s time to think a little more about why we choose to “Fail Fast”.
The intent of fail fast is that when uncertainty exists in the world, rather than spending a lot of time trying to clear up the uncertainty, it is better to release to users quickly and get feedback. This is very logical and adds a lot of value when implemented properly. From what I have seen, though, this phrase is often hijacked and taken to mean something altogether different. People take the fast portion to its extreme and only focus on this variable. What they get is fast and cheap, when the intent is really to fail well.
How it goes bad
Usually, fail fast is misapplied in cases where uncertainty can be resolved through other means, but the product team chooses not to. In the interest of moving fast, the team comes up with a bunch of ideas and seeks user feedback. The common belief is that any user feedback is good input to the design process, but this is misguided. Because when fail fast goes bad, it goes bad spectacularly.
There are two likely, but opposite, outcomes that lead to failed projects. First, a poorly thought out idea is released too soon and disenfranchises the customer or user set. While feedback can be collected, the company has now put a bad product in the world that stains the company/product/brand name. For small companies that can rename and rebrand, it’s possible to get away with this tactic (probably about once or twice, depending on cash reserves), but big companies cannot as they are not able to rebrand and hide as easily. In the consulting world, this can also lead to cancelled projects as the customer quickly loses faith in the ability of the team they hired.
The tech world is littered with companies that had a good idea nugget, which wasn’t realized enough upon initial release. These ideas then go on in future products with other companies, but the initial product team fails to see the benefit. While this is good for the collective society, it is not good for the launching company or their investors.
The other outcome is that one of the initial ideas shows some initial promise. The concept is seen as a step in the right direction and something to iterate on. Unfortunately, humans tend to seek out the positive even when none is there. If you generate a variety of ideas, it is painful if none of them pan out so even the tiniest of glimmers of hope will be seen as a good thing. Complicating things is that test users will provide some positive feedback, since they don’t want to hurt feelings of the people whose product they are testing (and likely getting some compensation from). This makes it likely that you will always have a direction to go in, but it is possible that it can send you on a false path.
This concept seems good but quickly reaches a local maximum. At this point, a lot of money has been thrown at the project with expectations of success. By choosing a promising, but ultimately poor starting point, the project has a limited ceiling that guarantees long-term failure.
An alternate approach
While speed is important, and failure might not be fatal, failure is not the goal. A successful product is the goal. The purpose of showing a product to users is to get feedback and to learn. It is imperative to be clear about what the unknowns are, what you hope to learn, and how you will collect that data. We do not want to go fast just to go fast. In some cases, that means spending a little (or maybe a lot) more time up front, adding forethought to the product concept. This can, in fact, have an amplifying effect on your user feedback and ultimately your product.
This is also where the value of expertise, and UX in particular, comes in to play. An experienced UX professional will be able to think through options and know strengths and weaknesses of these ideas without having to try them or test them. Some will be outright rejected without talking with users; others will be explored in more detail. The professional will be able to quickly identify where there are gaps in the knowledge and what needs to be explored more when testing does occur.
Without this expertise, the design process turns into a brute force method. Brute force will get to the desired result eventually, but at virtually no concern to the final cost. All options are exhausted. It guarantees success eventually (if you have unlimited resources to pay for all this, of course), but also guarantees a lot of (fast) failure before arriving. Fail fast, fail often means that failure is not cheap.
With expertise, you can take a targeted approach — smartly moving through options and testing with users as necessary. The expert doesn’t fear failure, but doesn’t seek it out either. The expert doesn’t want to fail as fast as possible, but as fast as necessary. When experts fail, they want to fail good and fail cheap, and are not as concerned with how fast this comes.
