Pre-mortems: How a Stripe Product Manager predicts & prevents problems before launch

source https //coda io/@shreyas/pre mortems how a stripe product manager predicts prevents probl https //coda io/@shreyas/pre mortems how a stripe product manager predicts prevents probl in this doc, we’ll look at the “what” and “how” of pre mortems, along with a novel technique of using tigers, paper tigers, and elephants to run effective pre mortems my aim here is to be as concrete as possible so that you can take the steps described here and run your very first pre mortem this week test https //twitter com/shreyas/status/1221257560033857536 https //twitter com/shreyas/status/1221257560033857536 so, what’s a pre mortem, and what role does it play? post mortems, after action reviews (aars), etc are becoming standard process at many organizations, usually implemented after an outage, a failure, or even a fairly successful execution of a project unlike a post mortem—where you discuss what went wrong (and what you can learn from it)—pre mortems occur earlier in a project’s lifecycle and ask the team to assume that the project has failed and you prompt the team to come up with the reasons for the failure before project execution begins if you do a pre mortem right, you won’t need a tough post mortem the standard pre mortem script in gary klein’s hbr article on pre mortems, standard pre mortems are accomplished in four steps a facilitator informs attendees that the project has failed spectacularly everyone in the room writes down why they thought the project failed, including reasons they wouldn’t normally mention for fear of being impolitic the facilitator asks each team member to read one reason for their list and records the reasons mentioned after the meeting, the facilitator reviews the list and looks for ways to make the plan more robust to failures a modified pre mortem process as background, my teams at stripe have routinely run a modified version of this pre mortem script, particularly for major product launches and while we haven’t been 100% mistake free, pre mortems have enabled “calm product launches” and have enhanced team productivity and morale why modify the standard pre mortem script? in my experience, the standard pre mortem meeting was very engaging while the team was in the room but i frequently saw everyone forget about the progress made in the meeting, quickly reverting back to old patterns as soon as the meeting was finished so, i began looking for ways to change that i wanted the team to actively spot major problems, and surface those problems to other team members throughout the lifecycle of the project, not just at that one pre mortem meeting what was missing, i realized, was an evocative, convenient lexicon that allowed people to talk about these things in a psychologically safe manner enter the metaphors tigers, paper tigers, and elephants tigers, paper tigers, and elephants the way i like to run pre mortems now is to ask the team to list out their concerns about the project in three different categories 🐯 tigers a clear threat that will hurt us if we don’t do something about it 📃 paper tigers an ostensible threat that you are personally not worried about (but others might be) 🐘 elephants the thing that you’re concerned the team is not talking about so after your pre mortem meeting, you’ll start hearing your teammates mention “the tiger bob flagged” or “that elephant mentioned during yesterday’s standup” when communicating over slack, email, meetings, and even 1 on 1s this lexicon for potential threats and problems creates more psychological safety for team members to raise their concerns throughout the project’s execution how to run a pre mortem the right way while you can organize your pre mortem meeting just about any time, a good rule of thumb is to organize it one to three months prior to your launch this timing gives your team sufficient context on possible tigers, paper tigers, and elephants for your project, while building in a window to respond to potential problems that are identified during the pre mortem the meeting itself is a highly structured one hour context and prompt (10 min) think of at least 2 tigers and any paper tigers and elephants quiet time #1 (10 min) list out tigers, paper tigers, and elephants quite time #2 (10 min) review others’ inputs in a shared doc and +1 those you agree with (each team member is allocated five +1s) around the room sharing (20 min) share reflections and what resonated most with the entire group tentative top themes and next steps (10 min) the meeting leader shares emergent top themes and next steps that takes care of the meeting itself the most important part of the pre mortem process comes after the meeting the post pre mortem action plan if you are the meeting leader, you now need to prioritize the top 3 5 tigers and elephants that emerged from the pre mortem meeting this action plan should consist of top themes coming from the pre mortem meeting verbatim tigers and elephants people discussed during the meeting proposed actions for mitigating these tigers and elephants a directly responsible individual (dri) for each theme use this coda doc to run your pre mortem process to run my version of a pre mortem, copy this doc and use the pre mortem meeting page to run the actual meeting after the meeting, you (the meeting leader) can use the action plan page to list themes, share those themes with the team for feedback, and then put it in action to have a much smoother launch watch shreyas walk through this doc https //www youtube com/watch?v=lzzetqynsau https //www youtube com/watch?v=lzzetqynsau source https //coda io/@shreyas/pre mortems how a stripe product manager predicts prevents probl https //coda io/@shreyas/pre mortems how a stripe product manager predicts prevents probl in this doc, we’ll look at the “what” and “how” of pre mortems, along with a novel technique of using tigers, paper tigers, and elephants to run effective pre mortems my aim here is to be as concrete as possible so that you can take the steps described here and run your very first pre mortem this week https //twitter com/shreyas/status/1221257560033857536 https //twitter com/shreyas/status/1221257560033857536 so, what’s a pre mortem, and what role does it play? post mortems, after action reviews (aars), etc are becoming standard process at many organizations, usually implemented after an outage, a failure, or even a fairly successful execution of a project unlike a post mortem—where you discuss what went wrong (and what you can learn from it)—pre mortems occur earlier in a project’s lifecycle and ask the team to assume that the project has failed and you prompt the team to come up with the reasons for the failure before project execution begins if you do a pre mortem right, you won’t need a tough post mortem the standard pre mortem script in gary klein’s hbr article on pre mortems, standard pre mortems are accomplished in four steps a facilitator informs attendees that the project has failed spectacularly everyone in the room writes down why they thought the project failed, including reasons they wouldn’t normally mention for fear of being impolitic the facilitator asks each team member to read one reason for their list and records the reasons mentioned after the meeting, the facilitator reviews the list and looks for ways to make the plan more robust to failures a modified pre mortem process as background, my teams at stripe have routinely run a modified version of this pre mortem script, particularly for major product launches and while we haven’t been 100% mistake free, pre mortems have enabled “calm product launches” and have enhanced team productivity and morale why modify the standard pre mortem script? in my experience, the standard pre mortem meeting was very engaging while the team was in the room but i frequently saw everyone forget about the progress made in the meeting, quickly reverting back to old patterns as soon as the meeting was finished so, i began looking for ways to change that i wanted the team to actively spot major problems, and surface those problems to other team members throughout the lifecycle of the project, not just at that one pre mortem meeting what was missing, i realized, was an evocative, convenient lexicon that allowed people to talk about these things in a psychologically safe manner enter the metaphors tigers, paper tigers, and elephants tigers, paper tigers, and elephants the way i like to run pre mortems now is to ask the team to list out their concerns about the project in three different categories 🐯 tigers a clear threat that will hurt us if we don’t do something about it 📃 paper tigers an ostensible threat that you are personally not worried about (but others might be) 🐘 elephants the thing that you’re concerned the team is not talking about so after your pre mortem meeting, you’ll start hearing your teammates mention “the tiger bob flagged” or “that elephant mentioned during yesterday’s standup” when communicating over slack, email, meetings, and even 1 on 1s this lexicon for potential threats and problems creates more psychological safety for team members to raise their concerns throughout the project’s execution how to run a pre mortem the right way while you can organize your pre mortem meeting just about any time, a good rule of thumb is to organize it one to three months prior to your launch this timing gives your team sufficient context on possible tigers, paper tigers, and elephants for your project, while building in a window to respond to potential problems that are identified during the pre mortem the meeting itself is a highly structured one hour context and prompt (10 min) think of at least 2 tigers and any paper tigers and elephants quiet time #1 (10 min) list out tigers, paper tigers, and elephants quite time #2 (10 min) review others’ inputs in a shared doc and +1 those you agree with (each team member is allocated five +1s) around the room sharing (20 min) share reflections and what resonated most with the entire group tentative top themes and next steps (10 min) the meeting leader shares emergent top themes and next steps that takes care of the meeting itself the most important part of the pre mortem process comes after the meeting the post pre mortem action plan if you are the meeting leader, you now need to prioritize the top 3 5 tigers and elephants that emerged from the pre mortem meeting this action plan should consist of top themes coming from the pre mortem meeting verbatim tigers and elephants people discussed during the meeting proposed actions for mitigating these tigers and elephants a directly responsible individual (dri) for each theme use this coda doc to run your pre mortem process to run my version of a pre mortem, copy this doc and use the pre mortem meeting page to run the actual meeting after the meeting, you (the meeting leader) can use the action plan page to list themes, share those themes with the team for feedback, and then put it in action to have a much smoother launch watch shreyas walk through this doc https //www youtube com/watch?v=lzzetqynsau https //www youtube com/watch?v=lzzetqynsau