Challenge your assumptions before you build anything, otherwise you’ll burn money fast.
Everproof’s technique for running a premortem
Include everyone you think will add value. We invite product, engineering and commercial thinkers to our sessions. You’ll need around 120 minutes of their time.
1. Introduction (10 minutes) — Your team must understand they need to dedicate two hours to this session, no phones and no laptops allowed. Ensure they’re present by starting the session with an icebreaker. I’ve found that the funnier you make the game, the better the session will be. This is my favorite icebreaker, but the rest of my team would beg to differ:
2. I Assume That (30 minutes) — Ask everyone to write down all the things they assume to be true about the problem you’re trying to solve, and the world around you. There’s no such thing as silly assumptions! Write out assumption like this:
3. This Failed Because (30 minutes) — Ask everyone to write down all the reasons they think the project could fail, even ones that may seem improbable. As with assumptions, there’s no such thing as silly reasons for failure! Write out reasons like this:
A quick note — some people on our team like to spend the entire 60 minutes writing a mixture of assumptions and reasons for failure, there’s no rules here! This is what the output for two people in a 30 minute IAT and 30 minute TFB session can look like:
4. Cluster post-its (30 mins) — One person chooses a note from their pile of notes, read it to the room and stick it on the whiteboard. If anyone in the team has a similar note, they stick it clustered next to that one. You’ll know what I mean by “similar” when you start doing the exercise.
5. Review notes and groupings (30 mins) — Review each card, making sure it makes sense and is grouped appropriately. You should be able to summarize each group in a simple sentence. If some of your groups don’t have assumptions, fix that and think of what assumption is underlying that reason for failure. Do the same for groups that don’t have reasons for failure… if that assumption was to be invalidated, would that cause a failure? Make sure all your groups have at least one assumption and one reason for failure… if they don’t then retrospectively add them.
We’ll run research sprints to validate or invalidate our assumptions. We’ll also create a failure prevention plan for each of the reasons for failure.
Before that though, we need to document our assumptions and reasons for failure in a spreadsheet. I’ve written another article explaining how we do that, click below to view that article: