Skip to main content

Be a specialist in failure

Why your organisation's culture might need to change and some steps to help you along your way.

Finally an excuse

Last week, at a UX talk the best question of the night came during the panel Q&A regarding how to deal with 'failure' when testing designs. My personal journey in the organisations I have worked in have, perhaps, witnessed more progress in this regard. So I thought I would share my thoughts and my colours

It has always been a stretch to talk about Arsenal and UX in the same breath, until now.

This story goes back to early 2014 when Arsene Wenger was the manager at Arsenal and Jose Mourinho was back at Chelsea for a second time. As the title race was warming up the mind games begun. Wenger shot first in a comment regarding team's declaring themselves out of the  title race:

"it's fear to fail - if you not in a race you can not lose it"
Arsene Wenger

Mourhinio was asked what he thought of the comments to which he snapped back saying:

"You know he's a specialist in faliure, I'm not."
Jose Mourinho

Hindsight delivered a sweet irony as Jose's career eventually free-falled. However, it must be said, neither really was a specialist in failure to their detriment. Here's why.

Why you should be a specialist in failure

Those who cannot learn from history are doomed to repeat it.
George Santayana

It's an age-old quote, it probably meant history like the stuff in books but for me, it counts for everything I've done.

What I am trying to advocate for is maximise what you learn from your failures in order to not repeat the mistake and to build new assumptions and hypothesis off the back of it. This applies to both you and, importantly, your organisation.

90% of start-ups fail in the first year.

Guess what else fails 90% of the time, your bad ideas. It's true most of your ideas suck, don't feel bad we're not idea machines. But ask yourself, honestly how many features that you designed shipped on the first or second time of trying? I bet pretty much all of them, me too. There's a problem in tech where we so often ignore the evidence in front of us and ship the product hoping it's going to somehow be alright.

I once worked on a team that cost £1.2 million to run doing just that. After 6 different design iterations, all failing (in a big way) a 7th design was created by the BAs and POs which went live. In the first half, they had 2 customers with a business value of a few thousand.

If wasting £1.2 million isn't reason enough to accept failure and become better at learning from it then I don't know what is. But how do you go from refusing to fail to learning from failure?

Learning > Delivery

I believe it was in Eric Reis book Lean Startup he talks about how organisations have to develop a learning culture.

In Lean, like TPS lean, they talk about Kaizen ("Improvement") as a fundamental principle.

By continually learning you are continually improving and continuous improvement leads to good things. Any organisation large or small can apply Lean principles to their organisation, it is not just for start-ups.

Keep the faith and Lean will reward you in delivery.

Continuous improvement

Continuous improvement can be split into 2 part:

Continuous Delivery

It's the one most of us have heard of. Engineering teams releasing code at will into the wild. Beautifully crafted pipelines let devs write, test and deploy code in a utopia of cloud stack bliss. That is to say, it is: scalable, reliable, fast and maintainable.

Most of us will be familiar with Henrik Kinberg's article about how to build an MVP. I won't go as far to say it's wrong but Marty Cagan's article reflected the way we worked at CareerBuilder. It wasn't by chance either, Marty came to CareerBuilder and flipped our ways of working to better empower the discovery work in the organisation.

Continuous Discovery

So we move onto Continous Discovery, it's a place where the chaos of discovery can live without impacting the execution of delivery but most importantly it never stops. It continues to impact the shape of delivery throughout the product's lifecycle.

The discovery track ensures everything in the product (that is everything that gets delivered) is: valuable, usable, feasible and viable.

Dual track Agile

The easiest way to manage this is through a dual-track Agile process. Honestly, don't try and stick discovery work into a delivery board. You can't put the discovery in a box, it wants to be free, it's a wild child, a stallion yet to be tamed. If you put it in the delivery board your velocity and burn down charts will just implode.

Stories that get validated then pass onto the delivery board by which time they should meet your team's definition of ready, almost by magic :-D

In a dual-track Agile board, you can burn through 9 stories to get to your 1 working one no worries. Put your technical spikes into the discovery board too, they are a form of discovery.

Just like a spike you should time box your discovery stories. Time box them based on how risky they are, more risk needs more time to de-risk and importatnly it helps you get better at failing when combined with the pivot.

The pivot

Every story in discovery should have a falsifiable hypothesis, a pivot and by the end of the time-boxed period, it should have been tested.

The pivot is a decision you make before you run the tests about what to do depending on the results.

By making the decision beforehand you are making a commitment to honour the outcome. Let me tell you, your estimations change when you do this.

Typically you'll have a go no go decision to make, but sometimes it can be more nuanced than that. Your pivot will be some empirical score against the test or KPI you are trying to reach. For example, you might say we expected our feature to improve conversion by 7%, anything less and we go back to the drawing board.

When all else fails

Sometimes you fail a lot, you fail so much you have nothing to pass to the delivery team. Your cadence is shot and there's no value to deliver.

This can happen, especially if you're running scrum instead of Kanban and you are truly behaving like a learning organisation.

I once found myself in this situation, it was difficult I reported to my product owner, not a lot is going to come out of this sprint, all our designs are flops. It wasn't a good week for me. So when I got to meet Jeff Patton and Jeff Gothelf I posed this situation and told them what I did, got the engineers doing discovery. They agreed, if that's where you are, get the engineers doing discovery so you can find that value sooner and resume business as usual.

TLDR;

In summary, you can try these things in your organisation to start becoming a specialist in failure:

  • Accept you have a problem (you are not constantly winning)
  • Learn to learn from your mistakes
  • Advocate for a learning culture over a delivery culture
  • Start doing Continous Delivery and Discovery
  • Manage discovery/delivery in a dual track Agile system
  • Set a pivot point
  • Get developers doing discovery

Random Quote

Begin with the end in mind

Stephen Covey

Photos by JOSHJDSS and Aleksandr Osipov from Flickr