Learning to fail to deliver digital product success

I've lost count of the number of times organisations have told me they have a "fail fast, fail often" approach to delivering projects. This isn’t a new idea, but in practice, so few companies are open to systematically trying new things, making mistakes and learning from their failures. At best they're just paying lip service to this mantra.

The challenge is that most companies are not structured in a way that makes failure an option.

There’s little appetite to experiment, knowing that many of these experiments will fail and might be called a waste of money.

No one wants to be called a failure, after all. Instead, new projects make it through to delivery on the back of a theoretical business plan written by someone who’s never spoken to a single user.

Some of the most successful businesses in the world continue to innovate, test, and learn, in order to increase their market share or venture into new markets.

So why are so many organisations resistant to working this way? The key to this problem is to change the way they think about failure.

The human condition & blame culture

Failure is the tangible outcome of a mistake or several mistakes. You can always fix a mistake, but a failure you can only learn from.

I can list a number of things I’ve failed at over the years, and most felt awful at the time. However, once you’ve got over it emotionally, quite often you learn something valuable to prevent it from happening again.

The trouble is, we’re taught from a young age that failure is bad, and often results in punishment. This means that failure and punishment, or blame, are so closely tied together that there’s no wonder it’s hard to admit when we’ve done something wrong.

Multiply these feelings by the number of people you have in your organisation, and you can see why blame culture is so prevalent.

We all harbour a (not so secret) desire to avoid making mistakes, and more often than not will find ourselves hoping for the best outcome, despite our better instincts telling us otherwise. Particularly when working on a project or experimenting with something new, addressing these mistakes early might help us save face in the long run in front of our peers and seniors alike.

The only way to solve this is to promote a culture that accepts failure and makes people feel confident when admitting their mistakes.

I’ve seen this done (in the extreme) at a previous company I worked for; the “Church of Fail”. Every Friday at 4.30pm over a beer, any person who had failed at something or made a mistake during that previous week could come forwards and announce to the whole company:

• What happened
• Why they made that mistake
• What they would do differently next time

Raucous applause would ensue. As I say, it might seem extreme but our CEO both introduced and embraced it wholeheartedly.

I learned a lot from other people’s mistakes. Of course, this wouldn’t necessarily work in an engineering or manufacturing environment when the risks of injury or worse are much higher, but my point is, that tolerance to failure must come from the top. 

You might think that there’s a fine balance between allowing employees to get away with almost anything, and holding them to account when something goes wrong, but really this is where we need to get better at identifying the root cause of the failure rather than immediately pointing fingers.

Often, there’s more than one reason the failure happened. In fact, an organisation that fosters a culture to speak up when failures happen is likely to be more productive, achieve better outcomes and save thousands (if not more) of pounds.

Detect, analyse, adapt

Highlighting mistakes early is the only way to minimise the risk of failures happening. However, when people are so reluctant to speak up when they’ve made a mistake, how can you identify these problems early enough to do something about them? 

We need to decouple emotion and opinion from data and facts.

We love Kanban here at Red Badger, as a way to build in quality and reduce waste on any project.

I’m not going to bang the process drum in this post (you can find more about how we deliver projects here), but there’s one part of Kanban that’s extremely relevant to this. Jidoka - developed by Toyota in the late 1800’s - is a way to visualise and deal with problems throughout a process or workflow.This doesn’t just work for production lines. Anything involving a process can take the theory of Jidoka and implement it to highlight problems that require immediate attention. 

Visually highlighting problems, whether that’s as simple as using colour-coding in your stakeholder reports, sticking BLOCKED post-its on your Kanban board, or using monitoring to automate alerts when there’s a problem with your website isn’t a new thing.

I’m sure most of you reading this do these sorts of things without even thinking about it. It’s the next steps that are critical.

Those who work on Agile projects are used the next step, analysis, or in Agile terms a retrospective. Once you’ve detected a problem, it’s important to understand why it happened.

This isn’t about pointing fingers, it’s about using data and facts to understand why the mistake was made in the first place. By removing the human factor and emotion, it allows us to think clearly about the underlying reasons, of which there may be several contributing factors.

The final piece is the adapt part - actions to ensure it doesn’t happen again or implementing improvements to make it better.

You can see how, in this cycle, it makes sense to try and make mistakes as early as possible in the project or process lifecycle, so you’re building in quality and reducing the risk of failure as you go.

The Lean Startup

That’s all well and good when you’re completing a project or a process, but I digress.

Back to the original problem. What happens when you’re trying out new ideas when you don’t know what failure looks like, or even what the right answer is?

The risk is much greater when there’s no “end state”, hence why businesses are adverse to this concept. Pumping money into an as yet unproven idea which may fail isn’t exactly attractive to an organisation with their eyes on the P&L.

At Red Badger, it’s simple; we use one of the basics of the Lean Startup - build, measure, learn. In practice, this means that we test ideas quickly and cheaply, in order to validate whether or not it’s a good idea, reduce uncertainty and risk, and ultimately prevent costly failures. We need to find the perfect harmony of desirability, feasibility & viability. It’s pretty straightforward to do this:

1. Create a list of assumptions and hypotheses to test for each idea.
2. Prioritise these by risk (by testing the largest assumptions and riskiest hypotheses first, we avoid wasting money later down the line).
3. Run experiments to learn what works, and what doesn’t. Discard the ideas that add little or no value to the business or the intended user.
4. Use the data from the experiment to influence what’s tested next.

Start with small, cheap experiments to reduce uncertainty and avoid wasting large sums of money.

Again, we use data and facts to validate or disqualify ideas, so human emotion can’t have an impact, catching potential failures before they’ve even had a chance to manifest themselves in delivery. 

The outputs of this process are validated ideas that are far less likely to result in a negative outcome.

Are you failing to learn, or learning to fail?

Failing should be encouraged, but only if the learnings that are taken out of it allow a better result next time. You can do this by:

1. Embracing failures rather than immediately pointing fingers.
2. Understanding what caused the failure, and taking measures to prevent it from happening again.
3. Using validation and experimentation, to quickly and cheaply decide whether new ideas are good or bad.

Rather than fail fast, and fail often, we need to change the mindset of organisations to learn fast, and learn often. 

To learn more about how we can help your organisation validate ideas and use failure to your advantage, get in touch with us.