Failing_fast_not_only_for_engineers_David_DeWolf_1200x675

Failing Fast Isn’t Only for Engineers

1024 576 David DeWolf

As a software developer and agile evangelist, I used to preach the concept of “failing fast.”  Failing is expensive and the better you are at doing it, the more you will minimize its impact.

In the ideal world, we would never fail.

Get over it: this is the real world and you’re likely going to fail at least as often as you succeed.

In the engineering world, a fail-fast system immediately terminates and reports a flawed condition as soon as it is discovered. By failing fast, the failure occurs as close to the core issue as possible. This maximizes feedback (it is provided early and often), allows for contextual information to be captured, and ensures that feedback occurs early and often.

As a result, no operations are conducted in a flawed state (waste), and debugging is simplified since it is much easier to pinpoint the failure. Ultimately, failing fast reduces cost, while the alternative, continuing in a flawed state and attempting to perform operations that are likely to result in an erroneous outcome, bloats cost.

In the agile product development world, the concept of a “minimally viable product” likewise reduces waste. The approach doesn’t imply that quality is sacrificed. Rather, a small number of features are released to test assumptions and guide direction.

By releasing quality product to market “early and often,” product managers are able to test assumptions by gathering user feedback, statistics, and usage patterns in order to refine the product roadmap and ensure that what is being built is in alignment with what users will actually use (not with what marketers say they will use).

Products that leverage this approach fail fast and recover quickly. Less time is spent designing and building robust products that fail miserably and more time is spent building features that are guided by real feedback and user requests. Again, failing fast reduces cost. For many product teams, building and refining a minimally viable product is the difference between colossal failure and continued improvement.

No matter what you’re doing, failure is expensive. It puzzles me why we have not applied the concept of failing fast to a wider range of business scenarios. For some reason, we have a tendency to try to avoid failure instead of trying to learn from it. We figure that if we think hard enough, plan long enough, and strategize effectively enough we may make the right decision in the first place. Unfortunately, we are still bound to make the wrong decision every once in a while.

I have learned the hard way that making a well-informed and decisive decision quickly is much more cost-effective than delaying a decision in hopes of more information, a better plan, or a stronger strategy. Failing fast is good. Failing too late is expensive. Failing fast allows you to refine your approach, adjust your idea, and move forward without losing too much time.