Agile Insider
Published in

Agile Insider

Leveraging Pre-mortems to understand why projects might fail

Photo by Jo Szczepanska on Unsplash

As a leader, often your biggest worry is to build features or launch initiatives that fall flat. Failure is inevitable and probably necessary for innovation. Yet, certain practices can help you reduce chances of failure by helping identify blind spots.

One practice to identify potential causes of failure in advance is the practice of using “Pre-mortems”.

In this article, I will take you through what are pre-mortems and share my approach towards conducting pre-mortems.

What is a Pre-mortem?

Pre-mortem is a technique to try looking into the future and try to understand reasons why the project might fail.

While launching an initiative, we usually focus on the positive outcome. But with any initiative, chances of failure are always there.

Given that so much time, money & energy is spent on finishing any project and success is not guaranteed, it is advisable to do a pre-mortem for most projects.

Importance of Pre-mortem

  • The biggest benefit of a pre-mortem is to make every stakeholder aware of the potential reasons why the project might fail. Each of us has our blind spots and Pre-mortems can help overcome those.
  • It gives a chance to people to call out the “Elephant in the room.” Often, out of “fear” of being considered a ‘cynic’/‘naysayer’ we may not voice our concerns.
  • It can help give the team a reality check and have a sobering effect on expectations.

Pre-mortem thus provide a safe and structured way for everyone to share what they think. This eventually helps us build better products.

A number of product leaders have highlighted the importance of pre-mortems:

  • Shreyas Doshi explains how pre-mortems at Stripe have enabled “calm product launches” and have enhanced team productivity and morale.
  • Deb Liu explains how pre-mortems can be leveraged to unlock better product and career outcomes.

Conducting Pre-Mortems

There are multiple ways to approach a pre-mortem. I will share the approach which I follow.

  • In the PRD (Product Requirements Document) for the feature, I add a section titled “Risk” — In this section, I add the potential reasons why the project might fail.
  • To make it easier to structure your thoughts, I recommend grouping the “Risk” section into specific themes. Personally, I prefer to focus on three themes while highlighting risks:
  1. Technical risks — Limitations/challenges on the technical front which might cause the project of fail. For eg. poor internet connectivity for target segment, high latency in fetching the content.
  2. Usability Risks: Difficulties which the user may face in understanding/learning about the feature or product. This could reduce the likelihood of user using the project.
  3. Business Risks: Risks related to feature adoption because the user might not have a real need for it, pricing issues etc.

Depending on your product, you might want to create additional themes to cover different types of risks.

  • Once the risks have been added by you, its time to loop in other stakeholders. In your PRD document, tag the other stakeholders (engineering, design, marketing) to add what they perceive as risks.
  • Before starting development work on the feature, a “risk analysis” meeting is done with the relevant stakeholders to discuss the risks which have been highlighted.

Running the “risk analysis” meeting

A typical “risk analysis” meeting is structured in the following way:

  • 1st 5 minutes — Set context on the purpose of the pre-mortem and explain about the feature we are building.
  • Next 1o minutes — Everybody works in silence as they write about the risks they foresee in the project.
  • Next 35–40 minutes — One by one team members talk about what they perceive as the biggest risks. The team then debates on each of them and identifies mitigation strategies.

Post the meeting, it is useful to share the meeting minutes on a wider forum. In order to implement the mitigation strategies, it would be helpful to identify a point of contact for each of the strategies. Otherwise, there is a chance of some items slipping through the cracks.

Its important to understand that you won’t have a solution for every risk during the meeting. Some of the risks might well be hypothesis and you will have to wait for customer feedback. However, clearly calling out the risks will help everyone in the team acknowledge the potential reasons we might fail.

Conclusion

Pre-mortems work on the adage that “Prevention is better than cure”. If used well, they can be a critical lever in a product leader’s toolkit for identifying the inherent risks associated with any project.

--

--

--

Exclusive and practical insights that enable the agile community to succeed.

Recommended from Medium

50 shades of “done”

Product optimization of the marketplace on the example of BUKI: how to increase the company’s…

What product managers need to understand about Conway's Law.

Bringing Users In: How Voice of the Customer Can Change Your Product’s Development

Our guide to partnerships | Product at Purpose

Recruiting participants faster with a product usage tool

Why do product managers need customer empathy? And how to build it..

Do organizations really need a Product Owner ?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vikram Goyal

Vikram Goyal

Currently PM@Airmeet — building a kick-ass product for conducting remote events and conferences.

More from Medium

Jim Farrell — Product Advice For My Younger Self

Empower your team and product through detailed PRD (Product Requirement Document)

Photo by <a href=”https://unsplash.com/@dtravisphd?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">David Travis</a> on <a href=”https://unsplash.com/s/photos/ux-design-product?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

Run your meeting, lest it will run away

Meeting preparation framework: Why (purpose), What (desired outcomes and agenda), Who (the participants), How (the meeting technique such as interview, workshop and so on plus questions to ask), When (the schedule, and logistics)