Drew Barontini

Product Builder

Technical Pre-Mortem

When you shape work for a given feature or project, you’re doing it from the perspective of the user—that is, a design perspective. So if you were to hand this work off to a developer, you’re crossing your fingers and hoping you didn’t miss any big technical issues. It’s plausible you have enough technical understanding and you side-stepped any land mines. Ultimately, though, you won’t know because it’s all guesswork until you do the work.

So try a Technical Pre-Mortem. You’ve probably heard of a “post-mortem”, which is in reference to the idea of performing autopsies to determine cause of death. This is commonly used as a way to review what went wrong with a project (morbid origin, I know) in an effort to prevent it from happening the next time. The inverse of this, “pre-mortem”, is the idea of thinking through what could have killed the project if something went sideways enough to derail it. Let’s not leave it to chance, and do our best clairvoyant impression while we peer into an imagined future.

Identify the root causes

Let’s assume the work didn’t ship on time. We’re going to apply this thought exercise by asking the question “What went wrong?” and taking it to its logical end (to the best of our abilities). This is a good place to ask “why” and dig deep to find the underlying first principles. If the project failed miserably, what caused that to happen?

Work backwards to mitigate

If we identify the root cause, we can then work backwards until we have guarded against that possibility. This sometimes means we just need to call it out in the pitch and make the team aware of it. Awareness is the precursor of preparation, and it’s often the best we can do in the face of unknowns. But sometimes there is enough clarity uncovered in the root cause. In that case, we can adjust the solution in the pitch to protect (prepare) the team.

Be consistent in action and flexible in approach

Development work is riddled with unknowns. There will be unknown unknowns you don’t even know about and can’t foresee, no matter how much you look for them. The only way to learn is by doing, and the only way you get there is through diligent action. The team will be prepared, but they won’t be caught in the trap of thinking there will be no problems. That’s never the case.

Don’t be fooled by the plan

No matter how much planning you do, it won’t change the uncertainty in the process. Sometimes we’re right and sometimes we’re wrong—very wrong. As Dwight D. Eisenhower famously said, “Plans are worthless, but planning is everything.” That’s the key here. We’re not fooled into thinking we’re safe by adjusting the plan proactively. We’re exercising our minds through preparation and planning, critical skills in effectively delivering work on time.

Enjoying this post? Sign up to get weekly insights in your inbox.