The anatomy of a future failure

When we mess up or something goes wrong, one of the most important things we can do is understand and analyse what happened to avoid it happening again.

At The User Story, we’re always finding ways to get to learnings faster - rapid prototyping, testing and iterating - so that we can fail fast and make shit things slightly less shit, as quickly as we can. But some mistakes can be costly and take a long time to reveal themselves. Is there a way we can shorten that timescale, where we can’t speed up development or learn from mistakes before a project even begins?

Yes, and it’s called ✨time travel✨ a pre-mortem.

Killing your project before it starts

We’ve all heard of post-mortems: the dissection of a corpse after they have died in mysterious circumstances, giving us clues as to what happened. In some cases, so we can take steps to prevent failures in the future, too.

But a pre-mortem is exactly the opposite. Instead of waiting for the corpse to come in, we imagine a world in which the poor, hapless individual has already met their grisly end, and we surmise all the possible ways that could have happened, the reasons it could have gone wrong, and crucially, what we could do to prevent it.

It helps us to get into a better mindset. Not just to think about reasons that something might go wrong but to help facilitate a scenario where it has already gone wrong, and we are air-crash-investigating our way through the wreckage.

As you can imagine, this technique can be quite depressing. When projects start, they’re usually full of promise and lofty expectations, and much like usability research, we’re looking to prove that we can make it work rather than thinking of ways it won’t. It’s often a difficult frame of mind to expose ourselves to, especially for those of an optimistic disposition.

Thankfully, I’m generally a pessimist when it comes to products and projects, so this comes naturally.

The anatomy of a pre-mortem

No matter whether this prospect is exciting or terrifying to you, it’s easy to get started with a pre-mortem but difficult to do it really well. So here are a couple of tips to get you started.

1. Kill your project

Decide what you want to pre-mortem. Is it a product, feature, or project?

Write the words “[X Project] is dead. How did it happen?” on your board.

Get a whiteboard (or a digital board like Miro) and write up a couple of headers to prompt people’s thoughts:

• Why did the project deadline get missed?

• What materials were missing?

• What did we not accomplish?

• Who wasn’t available?

• What did we not understand?

• What assumptions did we make?

2. Invite your investigators

You should invite stakeholders, designers, researchers, developers, project managers, basically anyone who is working on the project together. You’ll want to hear from people of all perspectives and experience who are fully invested in and excited about what you’re working on together.

So you can dash their hopes and bring them crashing down to reality.

3. Set the scene

Introduce what you’re doing, and paint everyone a picture.

You have travelled to the future. The project has failed, a new feature you developed has not worked, or the company has collapsed, and you’re all out of a job.

Now, my chrono-investigative team, it’s time to get stuck in and find out why.

4. Don your detective hat

Give everyone a stack of sticky notes and have them write up every reason they can think of that your beloved project is dead. Give them plenty of time to do this. I like to set a long timer, something like 15 minutes, and let people silently write-and-stick.

Once you’re done, have people go through each of their stickies and explain what happened. Make sure everyone understands them.

Then, get curious. Take those stickies and ask questions. Why did it happen? Add more stickies as you dig deeper.

5. But how likely is it?

You’ll have added a bunch of stickies now, some of which seem pretty far-fetched and others a bit more likely. You should decide as a group which things are the most likely to kill your project that you want to focus on.

You can do this with whichever method you use for deciding on things as a group. I like to use dot-voting, but you could also use a $100 Method, a forced ranking, or whatever you like. Just ensure it’s done equitably rather than in the highest-paid person's opinion.

6. Now go back in time

Once you’ve done enough digging, you can decide how to mitigate those high-priority things. What would have helped, if you had enough time, to stop that thing from happening in the first place? Add those items after them in a sticky with a different colour.

You might have more than one mitigation, too. Just add as many ideas as you need.

You’re almost done, but also just starting!

Your present-future selves have just seen a vision of the future and now have the superpower to prevent a disaster. Use that knowledge wisely, prioritise your fixes based on the likelihood of happening versus how long it’ll take you to fix, and add them to your project.

Plus, use this chance to decide, based on what you’ve explored, to remove things from your project that might lead to its downfall, too - it’s not all about adding after all, but what you can take away, too.

You have a great power and must now wield this great responsibility to do a great job. Use it well. And if you happen to find the Gray’s Sports Almanac for 2025 on your travels, I’d like a copy, please.