When things go wrong, we spend so much time trying to figure out what happened and how our project launch got off track. But what if we did that first, in what research psychologist Gary Klein calls a project premortem before we have any actual fires to put out? We often don’t and instead are left with postmortems that look something like this:
Two weeks after you launched a project that your team dedicated months to, that feeling of accomplishment has quickly faded and things have gone very wrong. The team has worked tirelessly to patch issues and now they’re left feeling angry and dejected. Tensions are high but the project team has assembled for a postmortem to report back to stakeholders how this happened and what, if anything, could’ve been avoided.
The discussion uncovers several avoidable issues. The sales team shares that the new product took considerable effort and handholding to close even a fraction of the expected sales. “We thought sign-ups would happen self-serve since we’re not selling to small businesses. But instead, prospects wanted to be walked through the solution. Many were confused as to whether we’d solve their problem or not and wanted a demo.”
Marketing piles on, adding that creating a new category may not have been the right product positioning. The customer problems we were solving weren’t clear. They do note that the handful of customers who successfully onboarded are getting real value.
Customer Success sighs, “yes, onboarding has been a real challenge. Many customers just give up midway through. We’ve been reaching out to accounts as fast as we can, but we just weren’t expecting so much heavy lifting, and it’s not sustainable.”
Finance jumps in, “well, it’s not financially sustainable. This was pitched as a high volume, lower margin product but what I’m hearing is that it’s neither.” They leave the meeting early with an ominous statement, “Obviously, this can’t continue.”
An engineer quietly mentions, “I’m relieved it hasn’t taken off.” Everyone turns to them as they continue, “The machine learning model I built was just a proof of concept. I don’t think it’s going to hold up with tens of thousands of users let alone our goal of a hundred thousand daily active users.” The engineer then sinks into their chair as they realize this is the first time many of their colleagues are learning this.
The project team then begins brainstorming ways they could’ve improved project success and reduced these risks. The product manager admits that they knew they needed to do more customer discovery and interviews to really understand the problem and the target market, but felt pressured to make the launch date. The team finishes the postmortem, lays out a list of ways to reduce risk next time that includes using a prototype to validate the product idea early on, shortens the onboarding to get users to the ‘aha’ moment more quickly, and demonstrates the value of the product. Sales and marketing agree a clearer positioning statement and better definition of the target market would have avoided brand damage and customer confusion.
In his Harvard Business Review article, Klein notes that the problem with a postmortem is that it benefits everyone except the patient. Hindsight is great, but what if the project team had stopped and done this same risk assessment at the beginning of a project? Klein suggests performing a project premortem early in a project’s planning phase. Instead of a typical critiquing session where the team predicts what might go wrong, the premortem analysis assumes the project’s failure. The team’s job is to brainstorm potential problems that caused the project’s failure. The premortem exercise taps into a concept called “prospective hindsight”. Researchers from Wharton and the University of Colorado discovered that the process of imagining an event has occurred increases the ability to predict future outcomes by 30 per cent. And perhaps some of the pay off is that once the team thinks about avoidable risk from the start, they're primed to do that throughout the project.
People are sometimes hesitant to speak up in the planning phase of a project because of politics, or a fear of being seen as negative. The hypothetical nature of the premortem reduces that fear while making it safe for everyone to participate and even rewarding for those who identify potential weaknesses others on the project team didn’t foresee.
Ideally, the premortem analysis begins right after the kickoff meeting, once everyone knows the context and goals of the project. The team takes a few minutes to quietly brainstorm reasons the project has failed, placing one reason on a sticky note (real or virtual).
After the team has finished brainstorming, it’s time to analyze. One-by-one each team member introduces their reason and places it on a whiteboard. The team discusses potential ways they can guard against the risk. We recommend categorizing each risk against four categories:
- Desirability (value proposition, customer segments, channels, and relationships)
- Feasibility (technical, regulatory, skill sets, and patents)
- Viability (revenue and cost structures)
- Ethics (should we build this?)
The team should also do more risk analysis to determine what quick experiments they might conduct to reduce that risk. For example, they might identify value proposition concerns and decide to test an experience prototype to determine the target market’s willingness to pay for the proposed product. Or a technical spike may be appropriate to rule-out feasibility risk. The team should choose the right experiments to run — those which are crucial for success. Some risks aren’t worth tackling because they’re either known or are unimportant. Using something like this matrix will help the team prioritize:
By tapping into the power of intuition, the premortem technique helps project teams with better decision making and most importantly, avoiding the dreaded postmortem.
