🪦 Pre-mortem in Product Design

🪦 Pre-mortem in Product Design

There is probably no need to explain what the postmortem ceremony is (but here’s a Wikipedia link just in case). And as much as it is important to get those lessons-learned and future prevention strategy for what happened already, it's just as important to do similar exercise before the project/feature launch to figure out what can potentially go (very) wrong, and to set a high level strategy of how to deal with that (Wikipedia yet again).

And if you're wondering why some product design person touches this topic — that's because I believe that pre-mortem (as well as postmortem) can and should be used in all teams and departments, and can be applied to projects of all scales and meanings.

And on the product design side it can start with questioning the main hypothesis (what if we misunderstood the whole thing in general?) and can go as granular as you would like it to (what if users misunderstand the name of this button?).

So why is pre-mortem helpful?

Let's take a closer look into the hypothesis example and imagine that based on some data and insights (hopefully not only a gut feeling or design trends) you came up with the hypothesis on where or how something can be improved or solved. And so you started digging deeper and after few rounds of discussions, wireframes, design concepts, and so on, you got to building and releasing the feature.

But what if the initial hypothesis wasn't correct? For example, because all of the research participants were biased or they just happened to be the only ones among all of your users who had that specific feedback. I know, the chances are close to zero, but still...

  • First of all, you need to know how to measure the overall success and define what failure means.

    • Does it affect revenue? (positively or negatively)

    • Does it affect conversions or retention rate?

    • What are the side effects? (for example, people tend to forget about increased customer support load, but it's also money)

    • etc.

  • This should make it clear if in case of failure you have to roll back to the previous version or continue with what you have and try to improve.

  • And you should also keep in mind potential next projects that are designed considering success of this one.

    • How exactly they will be affected?

    • Are adjustments insignificant or maybe critical?

How to structure such an exercise?

  • Whom to involve?
    Of course you can do it all on your own, but it’s good to team up with you design peers, or a stakeholder, or other project team members. No one says you don’t know the subject good enough — it’s only about getting a different perspective.

  • Brainstorm project weaknesses and unknows
    Just list down any part of the feature design that is new, meaning being introduced to the product with this feature (new hypothesis, new flow, new component, new copy, etc.).

  • For each of the items from the previous step, list down:

    • How do we know it works?

    • How do we know it doesn’t work?

    • Is failure of this element critical for the feature?

    • Does any other project depend on this element?

    • Who needs to be informed/involved in case of failure?

    • Anything else that is relevant for your specific case

This may sound complex, but in reality it's just 1-2 hours exercise that (if documented) can save time and nerves if something goes wrong, as instead of running around in panic you will have a plan in place, ideally with names of whom to ask/inform/involve.

Do your lessons learned before they actually learned.

I know it sounds confusing but you can do it :allthethings: (iykyk 😉)