We’ve all been through starting a new project. In the CI/CD world we live in, new projects that we start are not a matter of if, but how many. Being a product manager, it is widely known that problem determination lays at our feet. Another thing, that is less publicized, is risk mitigation.
You’ll know this intuitively because of the questions we tend to get and ask ourselves. These questions are themed often around the idea of “how do we know this will work?” We get so many variations of this question that it finds itself in all of our tools. Retrospectives are designed to help answer that question in the past, but what helps us understand this in the future?
As a product person and founder for over ten years, this is one of the questions that keep people like us up at night – partially because there is no solve. If you knew the future, you wouldn’t need to be a product manager, you ought to just play roulette all day. The best thing we can do is minimize our risks and surface potential problems as soon as possible.
How do you do that?
Let me introduce the concept of “Premortem,” tell you the first time I found about it, and how I’ve taught any PM on my team to leverage its power to mitigate the risks associated with launching something new.
What is a pre mortem?
A pre mortem is simple. It’s setting some dedicated time before the project begins, a set of questions. Those questions have a theme – let’s assume the worst has happened, first – what happened, then what got us there, and then a way to mitigate that risk. It’s super useful when there is a diverse range of folks in the room because each perspective more than likely has a critical failure that can ruin a project.
The benefit of doing this is two-fold. First – as a product manager, you’ll get far more visibility into what other teams go through. Second – the other perspectives will understand what other teams go through, and once put together, it’s easy to speak to everyone involved in common terminology. Pre mortems can create a map for teams to follow and stay aligned by presenting constraints.
The first time I saw it used
I worked for a company called Philosophie Group, an innovation consulting firm as a product strategist and while there, due to the wide range of companies the firm worked with, I got a chance to learn and apply all types of tools to help teams get the outcomes they desired. This was the first time I got a chance to see the magic of a premortem.
We had a client and they were really concerned. The work they did was in the non-profit sector, and going to an innovation shop was a big deal for them. Not only did they have a problem to solve, but they also needed to get institutional support – they were a rogue team.
Only we didn’t know that. If we had gone through this engagement as “normal” there was a high probability that the work we did would just be thrown away. Now, sure, as a firm, we would get paid, but who wants to work on stuff that won’t be used?
My manager, Chris Butler, had a feeling that something wasn’t right, and walked me through the concept of a premortem during one of our one on ones before our kickoff meeting. And with that, I walked in and executed, finding the “rogue team” problem extremely early.
It changed how the engagement worked, as we focused a lot more on helping the team working with us to build trust in their internal organization – and as a result, we got the follow-on engagement and the team got a little more ingratiated into their organization.
Why I teach this
One of the things that younger PM’s have to get a handle on is ambiguity. Product requires a different mindset than most disciplines because you are constantly living in a world of non-determined answers and there is no way to “right” no matter how much prep you do. It’s all ambiguous.
Teaching this to PM’s early gives them insights on how many potential problems. I then make them choose the top three or four to focus on per project, reminding them that it’s about choices, and nothing they can do get the “right” answer.
Pre-mortems not only lower the risk by surfacing problems, but it also helps PM’s (especially less experienced PMs) build trust by showing they care about the issues other teams face. Showing people you care is important and a trust builder.
Pre mortems are important
There is no way to know the “right” answer, but there are ways to make sure you get closer and surface critical errors early. Premortems are a tool to keep in your toolbox to surface your risk and make sure the team is aware.
Disclaimer: This content was originally posted at Product School. You can find all my writing from this website here. Want to see all my writing on Product Strategy? here.
