Create a postmortem research plan for [EVENT OR OUTCOME]. The event occurred during [TIME PERIOD] and affected [AFFECTED PEOPLE OR SYSTEMS]. The known facts so far are [KNOWN FACTS]. The purpose of the research is to determine [RESEARCH DECISIONS]. Available evidence sources are [AVAILABLE SOURCES]. Stakeholders who may hold relevant information are [STAKEHOLDERS]. Legal, privacy, safety, or operational constraints are [RESEARCH CONSTRAINTS]. The final postmortem is due [DEADLINE], and the available research capacity is [TEAM AND CAPACITY]. Produce a research plan that begins with a neutral problem statement and a timeline of facts, assumptions, and unknowns. Then create a research-question matrix with columns for question, why it matters, evidence needed, best source, collection method, owner role, and target date. Cover detection, timeline, scope and impact, decision points, process controls, dependencies, contributing conditions, and recovery. Separate factual questions from causal hypotheses; do not treat correlation, a single interview, or a missing log entry as proof of cause.
Next, propose an evidence-collection sequence that preserves volatile records first and minimizes burden on affected people. Include interview guides tailored to operators, decision makers, and affected users, with non-leading questions. Provide a simple method for testing candidate causes against disconfirming evidence and for ranking corrective actions by risk reduction, feasibility, and ownership.
Finish with a workback schedule to [DEADLINE], naming deliverables, owner roles, review points, and escalation triggers. Include the final report outline: executive summary, impact, factual timeline, contributing factors, evidence limits, corrective actions, and follow-up checks. Keep the answer under 1,200 words.
Before answering, check that every research question has a source and an owner role. Also flag evidence gaps that could make a causal claim unreliable. Ask up to three clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [EVENT OR OUTCOME] | The incident, failed project, missed target, or unexpected result being studied. | Incorrect renewal invoices sent to enterprise customers |
| [TIME PERIOD] | When the event occurred and the period that should be reviewed. | September 2 through September 5 |
| [AFFECTED PEOPLE OR SYSTEMS] | The customers, teams, systems, services, or operations affected. | Forty-three enterprise customers, billing operations, account managers, and the invoicing service |
| [KNOWN FACTS] | Verified details, observed impact, and an initial timeline. | A pricing-table import ran on September 2; 43 invoices used old discount terms; 11 customers contacted support; no payments were processed on the incorrect invoices |
| [RESEARCH DECISIONS] | The decisions the research must inform, such as corrective actions or process changes. | Determine corrective controls, customer remediation steps, and whether the pricing import process can resume |
| [AVAILABLE SOURCES] | Logs, records, documents, metrics, tickets, or other evidence that exists. | Import logs, pricing-table versions, invoice records, deployment log, support tickets, CRM notes, and approval emails |
| [STAKEHOLDERS] | People or groups with direct knowledge, responsibility, or impact. | Billing operations lead, finance systems engineer, account-management director, support manager, and two affected customers willing to speak |
| [RESEARCH CONSTRAINTS] | Privacy, legal, safety, access, retention, or operational limits on the research. | Customer billing data is restricted; preserve records for audit; do not interrupt month-end close |
| [DEADLINE] | When the research plan or final postmortem must be complete. | Research findings due September 12; corrective-action review September 15 |
| [TEAM AND CAPACITY] | Who can conduct the research and how much time they have. | Operations analyst at half time, finance systems engineer for four hours, and billing lead for two interviews |
How to use
- Paste only verified facts first and label any interpretation as an assumption.
- Check that the plan preserves logs, versions, and records with retention risk before scheduling interviews.
- Assign people to collect evidence, not to prove a preferred explanation, and document where access limits prevent certainty.
- Follow up with: “Using the collected evidence below, draft only the factual timeline and evidence-gap section; do not state root causes.”
Variations
Incident investigation
Use this when a service or operational incident needs rapid evidence collection.
Create a 48-hour investigation plan for [INCIDENT]. Known impact: [IMPACT]. Earliest known time: [TIMELINE]. Evidence available: [SOURCES]. Investigators and availability: [TEAM]. Produce an ordered checklist that preserves logs, snapshots, configuration versions, and communications before they expire; then assigns analysis, interviews, and a factual update cadence. Include a hypothesis register with supporting and disconfirming evidence. State escalation conditions for [SAFETY, LEGAL, OR CUSTOMER RISK]. Do not identify an individual as a cause or make unsupported claims.
Project failure research
Use this when a project missed its scope, date, budget, or intended outcome.
Plan research for a postmortem on [PROJECT] that missed [TARGET]. Original plan and assumptions: [ORIGINAL PLAN]. Actual result: [ACTUAL RESULT]. Available artifacts: [ARTIFACTS]. People involved: [STAKEHOLDERS]. Deadline: [DEADLINE]. Build research questions around estimation, scope changes, decision timing, dependencies, staffing, risk management, and stakeholder communication. Assign an evidence source and owner role to each question. Provide a workback schedule and a report outline that distinguishes facts, contributing factors, and recommendations.
Customer-impact study
Use this when an unexpected outcome affected users and their experience must shape corrective work.
Design postmortem research into a customer-impact event: [EVENT]. Affected customer segments: [SEGMENTS]. Known customer impact: [IMPACT]. Existing customer evidence: [EVIDENCE]. Privacy and contact constraints: [CONSTRAINTS]. Create a plan that combines product or service records with ethical, non-leading customer interviews. Specify sampling criteria, interview questions, evidence limits, and how to avoid treating a few conversations as representative. End with an action-prioritization method that weighs customer harm, recurrence risk, and implementation effort. Do not invent customer quotes or sentiment.
Tips
- Preserve mutable evidence, including logs, configuration versions, and message timestamps, before interviews reshape people’s recollections.
- Write a factual timeline before debating causes; it makes gaps and conflicting accounts visible without treating either as a conclusion.
- Test a suspected cause by asking what evidence would disprove it, not just what evidence supports it.
- Corrective actions should change a control, decision rule, or operating condition, not merely instruct people to be more careful.
FAQ
Who should own postmortem research?
Use a facilitator or analyst who can coordinate evidence, while subject-matter owners supply records and context. The person closest to an event should not be the sole judge of its cause.
How much evidence is enough to name a root cause?
Enough to support a defensible causal chain and rule out material alternatives. If the evidence is incomplete, report contributing factors and uncertainty instead.
When should legal or safety experts be involved?
Involve the appropriate professional early when the event may trigger reporting, privilege, privacy, regulatory, safety, or employment obligations. A research prompt cannot replace that advice.