Rushing to Failure

Hello friends! In this post, I’m going to be talking about the important role failure makes in the development cycle. This is fresh in my mind after the conclusion of my second experiment, which you can read about here.

Failure is not an end state

The mistake many people make when thinking about failure is that it’s the “end” of something. Many folks see failure as the opposite state of success, when in reality, it’s just a milestone along the way (I’d also like to point out that success isn’t really an end state either, but that’s for another post).

Failure should be seen as a fork in the road. You can use your findings to decide whether it’s time to change course or if you should keep on keeping on. Which path is right? You won’t know until your next failure, and that’s ok.

Failure Should Not be Avoided

How many days have you lost because of your fear of failure? If you’re like me, that number is way higher than it should be. If we’re honest with ourselves, our first effort usually gets tossed anyway. Why delay that? Go ahead and fail fast, get the rubbish out of the way, and move on with all the new knowledge you gained. After all, you never know less than you do right now.

Drill Into The Why

Ok, so you encountered a failure. There are two questions you should start with, and they both start with “why.”

  • Why did this outcome happen?
  • Why do I consider this outcome a failure?

Let’s start with the first question. This is pretty basic, and something you’re most likely already thinking about. Look back at the series of events and decisions that led to the outcome, and try to decipher how they strung together to get to this point. This is a much more valuable area to spend your brain cycles than on thinking about the outcome itself.

The second question is a bit deeper. With this question, we don’t care about how we got to this point as much as we care about why this outcome was undesirable. Sometimes, this can be a matter of expectation. If you’re expecting a million downloads, but only get ten thousand, you might consider that a failure. Why is that? It could be because of budget you blew through, faulty research, or maybe even a bit of an ego. Understanding why you feel failure in this instance can help you as you plan for the next iteration.

Fail For Less

The worst failures are undoubtedly the ones that cost the most. The unit of expense could be money, it could be users, it will certainly be time, but every failure comes with a cost. If we assume that failures are inevitable, wouldn’t you agree that it’s best to fail for the lowest possible cost?

Let’s use some real numbers. We want to build a thousand widgets using a new fabrication technique. At that volume, it will cost us $3 per widget, for a total of $3000. Alternatively, we could build 10 widgets, but it’ll cost $10 per widget due to the smaller volume. Since it’s a new manufacturing technique, there’s a good chance we’ll encounter issues. Would you rather spend $100 to identify the blatant issues, or spend $3000?

Now, you might be thinking that ten units isn’t enough to catch a wide range of manufacturing defects. You’re right! But maybe 10 batches of 10 units is. In fact, with 10 batches of 10, you’ll have 10 different opportunities to make corrections to your process! And it’ll only cost you $1000! Sounds like a win in my book.

Wrapping it Up

So, let’s recap. Failure isn’t the end. Failure isn’t something you should hide from. Understand the why behind the failures you do experience (because you certainly will experience them). Finally, fail as cheap as possible. If you can work toward these things, you’ll be free to look forward to the opportunities a quick failure can bring.


Originally published at Potential Things.