We as humans are inherently prone to making mistakes. And as Design Thinking becomes more deeply embedded in the process of product development, we are conditioned to use “mistakes” as support for “experimenting freely, and abandoning quickly.” In other words, mistakes enable us to fail, thus we should do so as quickly, and as often as we can to maximize learning. But in order to fail, something must first be built, so a more accurate description for this kind of approach would be build fast, fail fast. The underlying questions that by character emerge from that notion are: does “build” then become another word for “iterate,” and what exactly is the difference between the two? Let’s try to unpack that.
Build to Fail? What the…
Iteration is driven by creative and critical thinking, not by minimizing the amount of time it takes to fail just for the sake of learning. A build is what should materialize only after investing an ample amount of time — I’ll say it again — creatively and critically analyzing a problem, and at the same time, iterating through the varying paths that lead to a solution. The solution, or what is built, is the manifestation of the discoveries made in however many iterations it took in response to arrive there. The learnings from evaluating the build may introduce a need for another cycle of iterations which could in turn result in a subsequent build. But no failings should be ignored due to an irrational race to get to market first, especially if a market need has not been adequately determined, defined, and verified.
And what about Design Debt? (Audrey Crane, Nov 2018). How many failed “iterations” does it take to kill a product before it’s had the chance to become a viable market option? The cost of operating and dedicating a design/development infrastructure in the name of experimentation is indisputably prohibitive when the goal is to generate a substantive ROI; after all, business is business. Not to mention the drain on teams being pushed to release under-developed products at the expense of discovery, research, and proper testing. Can any resulting product be considered an MVP? A market solution? Or was this so-called product simply dumped off to remain nothing more than a relic that might be (but usually is not) revisited at some indeterminate time in the future and made right? Is taking such risk worth incurring the attributable technical and design debt? I’m not sure there are definitive answers to any of these questions. We might be better served asking ourselves whether or not the build fast, fail fast philosophy is inherently flawed at its core.
Think Responsibly, Build Accordingly
The article Product Fail (Marty Cagan, June 2015) starts to lay bare some of the root causes that perpetuate the cycle of product failure, for example, how prioritizing ideas and establishing a roadmap will somehow enable product teams to predict how much time and at what cost a product will be market-ready. What’s problematic here is that those measurements can be only be quantified in hindsight because there is no way to accurately forecast the amount of investigation, discovery, research, testing, and iteration it will take to deliver the “necessary business value,” a.k.a. the “time to money.”
Failing fast by replacing proper testing with a customer-facing MVP, that, in many instances, is nothing more than a high-fidelity prototype lessens the value of both the product and the consumer’s needs. Is it the customer’s responsibility to validate early experimentation, or is it the product development team’s responsibility to provide something of genuine value that is worthy of trust and loyalty? This too begs the question of whether or not it's worth taking such risk in the name of timeliness. It also brings into question the value of any learnings gathered from that kind of failure.
There is no denying, and I agree with my colleague when he wrote in Good Product Design is Good Business (Doug Rangi, Feb 2019), “As product teams adopted aggressive development processes to beat out competitors (read as “agile”, “lean”, “scrum” etc.), it forced UX design teams into a reactionary role of patching interfaces under even more aggressive deadlines.” Clearly, that is not a viable path to success. After all, the goal is not to contribute to design debt in any product cycle, nor would it be effective to force product teams to comply with a system that results in seemingly limitless failure. The suggestion here is not to then build slow, fail slower. There is great benefit to streamlining processes and workflows, but it should not be at the expense of abandoning things that add the most value to a product that actually meets a market need. Who was it that said “Design Fast, Test Fast & Launch better.” Well put, Doug.