Be a specialist in failure

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.

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?

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.

Continuous improvement can be split into 2 part:

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.

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.

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.

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.

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.

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