In 2018, I performed on stage of TEDxGdynia. As you might expect, I talked about how to learn from failure, and presented the first version of the method I will describe below.

At the start of my talk, I asked two questions:

First: Did you know that we should learn from our failures?
Almost every person in the audience raised their hands.

Second: Do you know any effective method of how to learn from failure?
And there were only two hands raised…

As such, I would like to share with you the Failess Model – an effective way to learn from our failures. It is not important whether or not we were the ones at fault. The purpose of this method is to be resilient to future failures by learning from our experiences and preparing ourselves.

But first, let me tell you a short story from my life as an example…

In 1996, I was a co-owner of small software company. We developed and distributed games for Commodore Amiga and PC computers. I created concepts and scenarios for games and other software (such as a karaoke app).

After the huge success of our first adventure game, based on a very popular Polish comic book, I wanted to create our own heroes and start a new game series. The graphic concept and sense of humour of the game was based on Wacky Races, a popular Cartoon Network movie series – all translated to the Polish environment, of course. The heroes, two teenage boys, had many adventures in Poland and later the whole world after meeting an alien in need of help.

I had a very clear idea of what the product should look like, how we would sell it (as a box), the price (not as low as other local Polish games), and what we would title the entire series I had planned.

In my mind, this was a first game of a brand new series we would be producing for years to come. I had the title of the series and a subtitle matching the first game. I spent a lot of time writing scenarios and dialogues, and planned a lot of short animations (some were very… naughty – as seen below) to make the game addictive and funny.

We spent a lot of dime discussing how we would create the game, and inventing some new techniques for efficient and quick game development.

We even found additional money from investors for the first time in our short history.
After a year the game was ready.
After the next year we shut down the company.

What the hell happened?

There were a lot of wrong decisions made.

The price was too high for the Polish market.

The distribution, done by us, wasn’t very effective.

The marketing sucked.

And finally: if we make a game for young teenagers, we should not title it “Wacki” (a Polish slang term for… “dicks”).

You can imagine what happened when parents, grandparents or aunts and uncles would want to buy a “computer game for a 10-year-old kid” and saw this title…

It was a huge fuck-up…

The company went down. I spent years thinking about all that went wrong with whole process and decisions I made during the creation of the game.

What were the mistakes?
How did they happen?
What should I do (or not) next time not to repeat them?

Using this story as a practical example, I would like to describe my method for effective learning from our defeats, which I’ve called…

The Failess Model

The Failess Model consists of five steps: Identify, Understand, Plan, Do It, and Verify & Validate

Step 1: Identify the “root failure”

It is simple, isn’t it? The failure was that we screwed up our company!
If you start from this conclusion and proceed to the next steps, you will… fail!
The closure of the company was the result of mistakes we made earlier.

Let’s try to find the REAL failure – the “root failure” – using the Five-Whys* method.
1. Why did we screw up our company?
Because our price was too high, we sucked at distribution, and the game had a very (very!) stupid name.

2. Why did we have these three silly things?
Because we made stupid decisions?

3. Why we made this kind of decisions?
Because our leader didn’t accept other ideas.

4. Why didn’t he accept other ideas?
Because he thought that his knowledge about game development and marketing was good enough, and he was sure of his opinions. He forced other team members, including his co-founder, to do everything based on his vision.

And there is the root failure: I forced my vision and said “shut-up” to my team, because I was “the smartest guy on board”!

As you know, life verified my self-esteem…

* The “five” in Five-Whys method is only a suggestion. As you can see above, the four “whys” were enough in this case . Sometimes we need to use more “whys”, or less.

Now we identified the root failure: “The leader based his decisions on his own knowledge and opinion, and didn’t accept other views.”

Of course, there may be more than one “root failure” in your case. You should go through this step and the next ones for all of them. Or select the one most important or the most painful failure, if you prefer.

Step 2: Understand the reasons

If we know where the fuck-up happened, we should understand how it happened. We can use tools such as the Ishikawa diagram to find different types of reasons. For example: organisational, financial, resources, external or internal occurrences etc.

In my example, there will be categories such as, let’s say, “stupidity” or “lack of knowledge about real life”. We should find some examples, such as:

I never thought that the name “Wacki” (Polish word similar to “dicks”, as you should know by now…) may cause some concern
I did not want to verify if the price would be accepted by the market (e.g. by talking with our customers and partners), and looked only at projected income in Excel (because I thought that I was the smartest guy on the market)
I did not want to hear about distribution methods other than our own; there were other ideas from my teammates, e.g. distributing in newsstands (very popular channel back then) or finding an external distributor, with good selling channels and better knowledge of how to promote this kind of product (such as CD Project, who had spoken with us about joining their software division; who knows, perhaps we would’ve been the Witcher team?)

And you should see the biggest reason: almost every problem was caused by my inability to share decisions with my co-founder and team…

Step 3: Plan to improve

If we know what sucks and why, we can plan for what we can do next time to avoid this kind of failure, decrease the chance of it showing up again, or at least mitigate the negative results.

You can use some brainstorming techniques to create different methods or tools that could help in a similar situation.

Sometimes, there will be a lot of ideas; some of them impossible to deploy due to lack of resources or excessive complexity.

I suggest using the Eisenhower Method to analyse which solutions are most or least efficient (x-axis) and what the cost of implementation is — low or high (y-axis). If you find very efficient solutions that have low cost (we call that “low-hanging fruits”), there is your first choice. Usually, you should forget about inefficient and costly ideas. Analyse the other ones to decide whether they’re worth implementing and when. Maybe you can implement the high-cost and high-efficiency solution in the near future, when you will have resources which are now unavailable?

It is all your decision, but I suggest implementing at least one of them, even a “low-hanging fruit”. Even small improvements make your work or your organisation more effective, and ensure less failures.

And here are some possible solutions based on my story:

change our decision process to increase the participation of our employees
decide about important things by voting rather that giving the owner the final say
discuss our pricing, distribution and marketing (including product name 😁 ) with our partners and customer representatives
discuss potential distribution outside of our company and focus only on games development
create simpler or cheaper games and distribute them via newsstands (the Internet was still in its infancy)

Step 4: Implement

Just do it! Implement the initiatives you’ve selected. This step is as simple as the sentence above, but it is the most crucial one for the Failess Model to be effective.

If you have the most beautiful plans but you never make even a bit of them reality, all the work you did before is for naught. All the knowledge you acquire during the failure (sometimes very expensive in money or emotions), you’ve lost.

It is painful to hear “there were some lessons learned after the project, but we did not utilize any ideas we created to avoid failures in the future”. This is wrong on many different levels, but one is very important: if you don’t engage your team in learning from failures, either through the Failess Model or a different one (even uglier than what I’m proposing), it makes your team frustrated and unwilling to support learning from failures the next time something goes wrong.

There is a lot of methods for how to efficiently improve some changes or deliver solutions, including project management techniques or agile methods. You probably know them better than me — so use your knowledge and experience to deliver your chosen solutions.

For the record, the most important things to making this step efficient are:

describe the solutions you’ve decided to implement using SMART method
designate a person responsible for the solution and give them the resources they need
agree on the date of implementation and monitor the work
make this task a part of their job, which will be evaluated as a KPI or yearly evaluation

And reward them when the job is done!

Let’s look at my example again, and see possible implementations:
Idea: discuss our pricing, distribution and marketing with our partners and customer representatives
Implementation: set up the Product Owner role, responsible for adjusting our product to the market. Their responsibility will be, for example, to meet with three of our biggest partners and make ten calls to our customers (chosen at random) to verify the idea of our product when we have prepared first version of the concept. Responsible: Mister X.

Idea: discuss potential distribution outside of our company and focus only on games development
Implementation: during the next month, call up to four biggest game distributors in Poland and discuss a possible business deal, and set up the framework for cooperation. The decision of whether we want to do this will happen within a month after the calls. Additionally, discuss the options with whole team. Responsible: Miss Y.

Step 5: Verify & validate

People usually don’t like change.

It is common knowledge that we have to make sure the changes we planned are really implemented, whether people are using new procedures, processes, tools, and whether they are working in the way we agreed on.

To motivate our employees, it is important to make the new rules part of their job evaluation. Of course, we first need to explain to them what the purpose of the changes is, and teach them how to work in the new way. We have to clear up their doubts. It all serves to make the change more acceptable, even it means a bit more work for them – and us.

But we must verify if they really use the new rules, change processes, and so on. This is why I wrote about using KPI or other methods of controlling if our employees have switched to the new method. For example, if we change something in the project delivery process, PMO should verify if the new or changed steps are realized in the proper way.

On the other hand, we should also validate if the changes work. Do the new solutions give us the results we expected? Do the results they give make their cost acceptable? Is the risk of failure in the areas we’ve discussed really lower? Maybe we eliminated all risk? Or, unfortunately, we invested the resources, and yet nothing has improved?

At some point after we implemented and observed the changes, we should decide whether we will keep them, change them or trash them.

Coming back to my example:

Implementing Product Owner role:
Verify: mister X reports the calls to Management Board every month, as described in his KPI.
Validate: after delivering the new product to the market, collect the feedback from customers and partners and look at the income from the product. Based on this information: give the bonus to mister X (or not) and improve the consultation process

Deciding to use external distribution opportunity:
Verify: check if our products are promoted, distributed and sold in the way we agreed on.
Validate: look at the income. If you are satisfied, it is ok. If not, renegotiate the deal, change the partner or build your own sales team.
(In this case it is important to plan for those options before we make the deal, and make sure that the contract contains appropriate agreements)

Is this method effective?

I created the Failess Model based on my experience, as well as by analyzing other tools, such as PDAC, DMAIC, Lean Six Sigma, and coaching solutions and practices in both big corporations and small start-ups.

Yes, it is effective!

I tested it in formal and informal ways.

Informal tests occurred when I didn’t use flipcharts, post-it’s and so on; I simply used the five steps of the Failess Model during various discussions or short reviews, such as Scrum retrospective.

More formally, I used this method for improving some regular product delivery processes. An example I love: during an hour-long session, using Failureless, we identified some “low-hanging fruits” and selected one of them. We implemented a really small change very quickly, and we managed to save $20 000 per year through a very small reorganisation of the testing process.

I don’t have faith in the Failess Model. I have proof it works!

If this method seems very complicated or usable only for huge failures, that is far from being the case. You can use this way of thinking for minor things as well, even as small as my (previously-regular) issue of being late far too often. (let me know in the comments if you’re interested in reading me describe this example)

I’m waiting for your opinions about the Failess Model. Critical ones, too. As I learned from my mistakes with “Wacki”, there is no better to improve such tools than by listening to what others have to say about them!

The Failess Model is licensed under a Creative Commons Attribution 4.0 International license

^{reklama własna}

ZAMÓW KARTY FAILOWSHIP