Canonical page: https://tellenze.com/work-templates/pre-mortem-actions [All templates](https://tellenze.com/work-templates) A free writing template # Pre-mortem actions Imagine a failed outcome, then turn the plausible causes into early checks and actions. Use it when you are preparing a change or launch and want to discuss risks while there is still time to act. [Start with the blank template](#blank-template)[Read the filled example](#filled-example) No account or email needed. Downloads work without JavaScript. Make the structure useful ## Current facts. A clear next step. Replace the prompts with your own context. Keep an unanswered question visible when the facts are missing. Agree the people and decisions rather than copying them from the example. The blank and filled versions are portable Markdown. They do not install native Tellenze templates or create workspace work. [Manage dependencies](https://tellenze.com/guides/manage-dependencies) - 01 State the planned outcome and a specific failure scenario. Use a hypothetical future, not a claim that failure happened. - 02 Let participants suggest causes before comparing them. Separate supported facts from assumptions. - 03 Choose the few risks that deserve action and give each an early signal, response and agreed owner. - 04 Link the actions to actual work. Revisit them when the plan or evidence changes. 01 / Your starting point ## Begin with the real work. Copy or download this version. Replace the placeholders, then review the definition with the people who will use it. Portable Markdown ## Blank template [Download blank template](https://tellenze.com/work-templates/pre-mortem-actions/download?version=blank) Use the preview below, then copy the text or download a .md file. ### Pre-mortem actions #### Planned outcome [What we are trying to achieve] #### Hypothetical failure [Imagine the work has failed. What does that failure look like, and for whom?] #### Context - Participants: [people with relevant perspectives] - Sources and known facts: [current evidence and access-checked links] - Assumptions: [what we have not confirmed] #### Risks worth acting on Repeat for each selected risk: ##### Risk: [a plausible cause of failure] - Why it could happen: [evidence or a clearly marked assumption] - Consequence: [who or what would be affected] - Early signal: [what we can observe before the harm] - Prevention or response: [a concrete action] - Agreed owner: [confirm who will act] - Work link: [where the action will be tracked] - Review point: [a meaningful check or date agreed by the team] - Remaining exposure: [what the action does not cover] #### Decisions and next check - Actions selected: [which risks we will address and why] - Risks accepted or deferred: [reason and who agreed] - Next check: [when we inspect the signals and actions] View blank template Markdown source Markdown source — blank template# Pre-mortem actions ## Planned outcome [What we are trying to achieve] ## Hypothetical failure [Imagine the work has failed. What does that failure look like, and for whom?] ## Context - Participants: [people with relevant perspectives] - Sources and known facts: [current evidence and access-checked links] - Assumptions: [what we have not confirmed] ## Risks worth acting on Repeat for each selected risk: ### Risk: [a plausible cause of failure] - Why it could happen: [evidence or a clearly marked assumption] - Consequence: [who or what would be affected] - Early signal: [what we can observe before the harm] - Prevention or response: [a concrete action] - Agreed owner: [confirm who will act] - Work link: [where the action will be tracked] - Review point: [a meaningful check or date agreed by the team] - Remaining exposure: [what the action does not cover] ## Decisions and next check - Actions selected: [which risks we will address and why] - Risks accepted or deferred: [reason and who agreed] - Next check: [when we inspect the signals and actions] 02 / A fictional example ## See how the sections connect. The Northstar customer portal is fictional. Its receipt-download scenario shows a writing approach, with assumptions, unfinished checks and required decisions kept visible. Use the structure with your own facts. Example text is not evidence of a shipped feature or approval for an action. Portable Markdown ## Filled example [Download filled example](https://tellenze.com/work-templates/pre-mortem-actions/download?version=example) Use the preview below, then copy the text or download a .md file. ### Pre-mortem: receipt download Fictional example: Northstar customer portal. The failure below is hypothetical. #### Planned outcome Customers can download a receipt containing the correct payment information for their own completed order. #### Hypothetical failure The download is released, but some customers receive an incorrect receipt or cannot tell whether a failed download can be retried. #### Context - Participants: a product owner, developer, reviewer and Support representative. - Sources and known facts: the agreed receipt fields, access model and current order page; link the real versions in the actual plan. - Assumptions: the existing PDF generator supports the required fields without a new dependency. #### Risks worth acting on ##### Risk: the payment date means different things to different readers - Why it could happen: the display timezone is not yet agreed. - Consequence: a customer may read a date that differs from the expected payment record. - Early signal: the brief and receipt-format document disagree or omit the timezone. - Prevention or response: agree the timezone before implementation and add a boundary-date check. - Agreed owner: the product owner confirms the decision with the reviewer. - Work link: link the receipt-field decision and implementation item. - Review point: inspect the definition before work starts. - Remaining exposure: this action does not cover refund dates. ##### Risk: a PDF request uses an order without checking its owner - Why it could happen: access checks can be lost when a new download path is introduced; this is a risk to verify, not a known defect. - Consequence: private payment details could be shown to another customer. - Early signal: the proposed implementation or tests do not cover a different customer's order. - Prevention or response: reuse the current ownership check and require a refused cross-customer request test. - Agreed owner: the developer implements the check; the reviewer inspects the evidence. - Work link: link the implementation and access-test results. - Review point: complete this check before deployment review. - Remaining exposure: the team still needs to check its normal operational and access requirements. #### Decisions and next check - Actions selected: resolve date ambiguity and verify order ownership before review. - Risks accepted or deferred: refund behavior is outside this request and needs its own brief. - Next check: inspect the selected actions with the code and receipt example at review. View filled example Markdown source Markdown source — filled example# Pre-mortem: receipt download Fictional example: Northstar customer portal. The failure below is hypothetical. ## Planned outcome Customers can download a receipt containing the correct payment information for their own completed order. ## Hypothetical failure The download is released, but some customers receive an incorrect receipt or cannot tell whether a failed download can be retried. ## Context - Participants: a product owner, developer, reviewer and Support representative. - Sources and known facts: the agreed receipt fields, access model and current order page; link the real versions in the actual plan. - Assumptions: the existing PDF generator supports the required fields without a new dependency. ## Risks worth acting on ### Risk: the payment date means different things to different readers - Why it could happen: the display timezone is not yet agreed. - Consequence: a customer may read a date that differs from the expected payment record. - Early signal: the brief and receipt-format document disagree or omit the timezone. - Prevention or response: agree the timezone before implementation and add a boundary-date check. - Agreed owner: the product owner confirms the decision with the reviewer. - Work link: link the receipt-field decision and implementation item. - Review point: inspect the definition before work starts. - Remaining exposure: this action does not cover refund dates. ### Risk: a PDF request uses an order without checking its owner - Why it could happen: access checks can be lost when a new download path is introduced; this is a risk to verify, not a known defect. - Consequence: private payment details could be shown to another customer. - Early signal: the proposed implementation or tests do not cover a different customer's order. - Prevention or response: reuse the current ownership check and require a refused cross-customer request test. - Agreed owner: the developer implements the check; the reviewer inspects the evidence. - Work link: link the implementation and access-test results. - Review point: complete this check before deployment review. - Remaining exposure: the team still needs to check its normal operational and access requirements. ## Decisions and next check - Actions selected: resolve date ambiguity and verify order ownership before review. - Risks accepted or deferred: refund behavior is outside this request and needs its own brief. - Next check: inspect the selected actions with the code and receipt example at review. Check before you share ## A useful file. A result you can trust. - Replace placeholders and fictional facts. - Check that readers can open every source. - State what is verified and what remains unfinished. - Agree the next action and any required approval. ### Put the template to work. [Manage dependencies](https://tellenze.com/guides/manage-dependencies)[Run a pre-mortem](https://tellenze.com/pre-mortem-workshop)[Follow a complete workflow](https://tellenze.com/examples/release-notes)[Use native work templates](https://tellenze.com/guides/work-templates) Another useful starting point ## Keep the next conversation clear. COME TAKE A LOOK ## A little less busy. A lot more together. Curious? Join the waitlist and see how we welcome your team. Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace. [Join waitlist](https://tellenze.com/waitlist)Start with your email. No payment needed to join.