.png)
Project overview
Include details of the project here with a link to any additional specification documents. Make sure you note who owns each part of the workload if relevant. This should be filled out in advance, as it sets the context for the rest of the meeting that follows.
Potential outcomes
Start off by thinking critically about the feature or product, laying out possible outcomes for how people might engage with whatever you’re working on. For example, let’s say you are adding a checklist to your product to increase activation. One possible outcome is that users don’t engage with the checklist at all!
-
Reasons for outcome
Next up it's time to brainstorm the reasons that the previous outcome might occur. Maybe the checklist blends in with the other UI elements? Maybe people see it, but just don't want any guidance. It's important to go broad and generate lots of ideas, especially the negative ones.
-
Scenario responses
Last but not least, ponder how you would respond to that outcome. If the checklist doesn't stand out among the other elements, would you add more color or make it bigger? Will you cut your losses and try another approach?
-
Before Jonathan began his tenure at Squarespace, he worked in private equity for a bit. “Pre-mortem actually came from my first job in private equity where we would go through scenarios of how a deal would play out. It didn’t look like a decision tree, usually it was more like a spreadsheet, but I found that it’s actually really useful for product management,” says Hastings. Today, this means that each of Jonathan’s teams go through a pre-mortem meeting at the beginning of major product development efforts. The meeting forces everyone to dig into different hypotheses and question assumptions being made. It doesn't matter if you're a designer, developer, or product manager. Premortems are a team-wide exercise.
Hastings centers the meeting around a template that breaks down into three categories:
- Things that we think might happen
- Potential reasons for that outcome
- How we would respond to that outcome
This might seem fairly straightforward, but each one exists for a specific purpose. Start off by thinking critically about the feature or product, laying out possible outcomes for how people might engage with whatever you’re working on. For example, let’s say you are adding a checklist to your product to increase activation. One possible outcome is that users don’t engage with the checklist at all!
Next up it's time to brainstorm the reasons that the previous outcome might occur. Maybe the checklist blends in with the other UI elements? Maybe people see it, but just don't want any guidance. It's important to go broad and generate lots of ideas, especially the negative ones.
Last but not least, ponder how you would respond to that outcome. If the checklist doesn't stand out among the other elements, would you add more color or make it bigger? Will you cut your losses and try another approach? Statements like “We understand that this might happen, but we’re going to ignore it for now” are hallmarks of this approach done right. These are difficult decisions, but they become a lot easier when you prepare in advance.
.png)
.png)
.webp){kind=small}