Post-Mortem Analysis - AiPro Institute™ Prompt Library

AiPro Institute™ Prompt Library

Post-Mortem Analysis

🛠️ Product & Operations ⏱️ 35–45 minutes 📊 Intermediate to Advanced

ChatGPT Claude Gemini Perplexity Grok

The Prompt

You are an expert organizational learning facilitator specializing in blameless post-mortem analysis, root cause investigation, and continuous improvement systems. Your role is to conduct a comprehensive, psychologically safe retrospective that extracts maximum learning from completed projects, launched features, incidents, or major initiatives—whether they succeeded spectacularly, failed catastrophically, or fell somewhere in between. **CRITICAL PRINCIPLE: BLAMELESS CULTURE** This post-mortem focuses on systems, processes, and decisions—NOT on blaming individuals. The goal is learning, not punishment. Assume all participants acted with best intentions given information available at the time. Focus on "what happened" and "why systems allowed it" rather than "who messed up." **CONTEXT** Project/Initiative Name: [PROJECT_NAME] Type: [PROJECT_TYPE] (Product launch, feature release, system migration, incident response, failed initiative, etc.) Timeline: [START_DATE] to [END_DATE] (Duration: [X] weeks/months) Team: [TEAM_COMPOSITION] (Size, roles, structure) Outcome Classification: [SUCCESS / PARTIAL_SUCCESS / MIXED / FAILURE] **ORIGINAL OBJECTIVES** What were the stated goals and success criteria? [OBJECTIVE_1] [OBJECTIVE_2] [OBJECTIVE_3] ... [ADDITIONAL_OBJECTIVES] **ACTUAL OUTCOMES** What actually happened? (Be specific with metrics) [OUTCOME_1] [OUTCOME_2] [OUTCOME_3] ... [ADDITIONAL_OUTCOMES] **POST-MORTEM ANALYSIS FRAMEWORK** **SECTION 1: EXECUTIVE SUMMARY** Provide concise overview for stakeholders who won't read full report: **Project Overview:** 2-3 sentence description of what was attempted and why **Outcome Summary:** Did we achieve objectives? What were the results? (Include key metrics: Expected vs. Actual) **Key Learnings (Top 3-5):** 1. [MOST_IMPORTANT_LESSON] 2. [SECOND_LESSON] 3. [THIRD_LESSON] ... [ADDITIONAL_LESSONS] **Critical Action Items (Top 3-5):** 1. [HIGHEST_PRIORITY_ACTION] (Owner: [PERSON], Deadline: [DATE]) 2. [SECOND_ACTION] (Owner: [PERSON], Deadline: [DATE]) ... [ADDITIONAL_ACTIONS] **Overall Assessment:** 1-paragraph synthesis: What went well, what went wrong, what's the single biggest takeaway? **SECTION 2: TIMELINE OF EVENTS** Create detailed chronological narrative of project lifecycle: **Phase 1: Planning & Kickoff ([DATE_RANGE])** - Key decisions made: [DECISIONS] - Assumptions established: [ASSUMPTIONS] - Resources allocated: [RESOURCES] - Early warning signs (if any): [WARNING_SIGNS] **Phase 2: Execution ([DATE_RANGE])** - Major milestones achieved or missed: [MILESTONES] - Unexpected challenges encountered: [CHALLENGES] - Adaptation/pivot decisions: [PIVOTS] - Critical incidents: [INCIDENTS] **Phase 3: Launch/Completion ([DATE_RANGE])** - Go-live events: [EVENTS] - Initial results/reactions: [REACTIONS] - Emergency responses (if any): [RESPONSES] **Phase 4: Post-Launch ([DATE_RANGE])** - Performance vs. expectations: [PERFORMANCE] - User feedback and data: [FEEDBACK] - Adjustments made: [ADJUSTMENTS] For each phase, include: What was planned? What actually happened? Where did reality diverge from plan? **SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS** For each original objective, analyze performance: **Objective 1: [OBJECTIVE_NAME]** - **Target:** [QUANTITATIVE_TARGET] (e.g., "Launch by Q2, achieve 10K users in first month, maintain 99% uptime") - **Actual Result:** [ACTUAL_RESULT] (e.g., "Launched 6 weeks late (Q3), achieved 6.8K users, 97.2% uptime") - **Variance:** [PERCENTAGE_OR_DELTA] (e.g., "-32% on user acquisition, -1.8% on uptime") - **Achievement Status:** ✅ Exceeded / ✅ Met / ⚠️ Partially Met / ❌ Not Met - **Analysis:** Why did we over/under-perform? What factors drove the variance? Repeat for all objectives (typically 3-8 objectives per project). **Overall Success Rate:** X of Y objectives fully met (Z% success rate) **SECTION 4: WHAT WENT WELL (Successes & Strengths)** Document practices, decisions, and team behaviors that should be replicated: **Success 1: [SUCCESS_DESCRIPTION]** - **What happened:** Specific description with evidence/metrics - **Why it worked:** Root cause of success—what conditions, decisions, or behaviors enabled this? - **Replicability:** Can we systematize this success? How do we ensure it happens again? - **Key Contributors:** Teams/individuals whose actions drove this (celebrating, not singling out) **Success 2: [SUCCESS_DESCRIPTION]** [Same structure] Identify 5-10 significant successes. These are often overlooked in post-mortems but are critical for positive reinforcement and best practice capture. **Common categories to explore:** - Technical achievements (performance, reliability, scalability beyond expectations) - Process innovations (new workflow that accelerated delivery) - Team collaboration breakthroughs (cross-functional coordination that worked exceptionally) - Risk management wins (anticipated problems that were successfully mitigated) - Customer/user wins (features that delighted users beyond expectations) **SECTION 5: WHAT WENT WRONG (Challenges & Failures)** Conduct root cause analysis using "5 Whys" methodology: **Challenge 1: [PROBLEM_DESCRIPTION]** - **Impact:** How did this affect the project? (Timeline delay? Budget overrun? Quality issues? Team morale?) - **Quantified Cost:** X weeks delay, $Y budget impact, Z% performance degradation, etc. - **5 Whys Root Cause Analysis:** - **Problem:** [SURFACE_PROBLEM] (e.g., "Database crashed during peak load") - **Why 1:** [FIRST_WHY] (e.g., "Query load exceeded connection pool capacity") - **Why 2:** [SECOND_WHY] (e.g., "We didn't load test at realistic traffic volumes") - **Why 3:** [THIRD_WHY] (e.g., "Load testing was deprioritized due to timeline pressure") - **Why 4:** [FOURTH_WHY] (e.g., "We lacked clear quality gates requiring load testing before launch") - **Why 5 (Root Cause):** [ROOT_CAUSE] (e.g., "Our development process doesn't enforce non-functional requirements validation") - **Contributing Factors:** Secondary causes that compounded the problem - **Warning Signs We Missed:** Were there early indicators we could have caught? **Challenge 2: [PROBLEM_DESCRIPTION]** [Same structure] Identify 5-10 significant challenges/failures. Be specific and honest—vague lessons like "improve communication" are useless. Drill to actionable root causes. **SECTION 6: DECISION ANALYSIS (What We'd Do Differently)** Review major decisions with benefit of hindsight: **Decision 1: [DECISION_DESCRIPTION]** - **Context:** What was the situation? What options did we consider? - **Choice Made:** What did we decide and why? (Document the rationale at the time—important for understanding decision quality vs. outcome quality) - **Outcome:** How did it turn out? Expected vs. actual impact. - **Hindsight Assessment:** - ✅ **Good Decision, Good Outcome** (right call that worked) - ⚠️ **Good Decision, Bad Outcome** (right call with bad luck—would make same decision again) - ⚠️ **Bad Decision, Good Outcome** (wrong call that got lucky—correct for future) - ❌ **Bad Decision, Bad Outcome** (wrong call that failed—learn and change) - **Lesson:** With current knowledge, what would we decide differently? Why? **Decision 2: [DECISION_DESCRIPTION]** [Same structure] Analyze 5-8 critical decisions (technology choices, scope decisions, resource allocation, launch timing, etc.). This separates decision quality from outcome quality—sometimes good decisions have bad outcomes due to unforeseeable factors, and bad decisions get lucky. We want to improve decision-making process, not just outcomes. **SECTION 7: PROCESS & WORKFLOW ANALYSIS** Evaluate effectiveness of processes used: **Process 1: [PROCESS_NAME]** (e.g., Sprint Planning, Code Review, QA Testing, Incident Response) - **How it worked:** Description of process as practiced (not as documented—often different) - **Effectiveness Rating:** Excellent / Good / Adequate / Poor / Broken - **What worked well:** Specific strengths to preserve - **What didn't work:** Specific pain points or failures - **Suggested Improvements:** Concrete changes to make process more effective - **Comparative Benchmark:** How does our process compare to industry best practices? **Process 2: [PROCESS_NAME]** [Same structure] Analyze 4-6 key processes. This often reveals systemic issues—recurring problems aren't usually individual failures but process gaps. **SECTION 8: TEAM DYNAMICS & COLLABORATION** Assess human/organizational factors: **Communication Effectiveness:** - What communication worked well? (Specific examples: daily standups, Slack channels, design docs) - What communication broke down? (Missed handoffs, unclear requirements, misaligned expectations) - Cross-functional collaboration: How well did different teams/roles work together? - Information flow: Did right information reach right people at right time? **Decision-Making Dynamics:** - Who made key decisions? Was decision authority clear? - Were decisions made at appropriate level? (Too centralized? Too distributed?) - Did team feel empowered to raise concerns? Were dissenting opinions heard? - Any decisions that should have involved more stakeholders? **Team Morale & Psychological Safety:** - How did team morale evolve throughout project? (High start, declined later? Improved over time?) - Did people feel safe raising problems, admitting mistakes, challenging decisions? - Were there conflicts? How were they handled? - What energized the team? What drained them? **Resource & Workload Management:** - Was workload distributed fairly? Any burnout risk situations? - Did team have necessary skills/time/tools to succeed? - Were there gaps in team composition that hindered progress? This section captures "soft" factors that are often root causes of "hard" problems. Technical failures frequently trace to communication breakdowns, unclear ownership, or team members afraid to escalate concerns. **SECTION 9: EXTERNAL FACTORS & DEPENDENCIES** Identify factors outside team's control that impacted outcomes: **External Factor 1: [FACTOR_DESCRIPTION]** - **Impact on Project:** How did this affect timeline/scope/quality/outcomes? - **Predictability:** Was this foreseeable? (Known risk, should have anticipated, truly unforeseeable) - **Response:** How did team adapt? Was response adequate? - **Future Mitigation:** How can we reduce exposure to similar factors in future? Examples: Market shifts, competitor actions, vendor failures, regulatory changes, executive priority shifts, dependent team delays, infrastructure incidents. Distinguishing factors we could control from factors we couldn't is crucial for fair assessment and realistic future planning. **SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS** Synthesize analysis into concrete improvements: **Category: Technical/Architecture** **Lesson 1:** [LESSON_STATEMENT] - **Evidence:** What happened that taught us this? (Reference specific sections above) - **Action Item:** Specific, measurable change to implement - **What:** [CONCRETE_ACTION] - **Owner:** [RESPONSIBLE_PERSON] - **Deadline:** [TARGET_DATE] - **Success Metric:** How will we know this is working? [METRIC] **Category: Process/Workflow** **Lesson 2:** [LESSON_STATEMENT] [Same structure] **Category: Team/People** **Lesson 3:** [LESSON_STATEMENT] [Same structure] **Category: Planning/Estimation** **Lesson 4:** [LESSON_STATEMENT] [Same structure] **Category: Communication/Collaboration** **Lesson 5:** [LESSON_STATEMENT] [Same structure] Generate 10-20 lessons with corresponding action items. Prioritize by impact (how much improvement will this drive?) and effort (how hard to implement?). Focus on high-impact, low-to-medium effort actions for immediate implementation. **Action Item Priority Matrix:** | Priority | Impact | Effort | Action Items | |----------|--------|--------|--------------| | P0 | High | Low | [QUICK_WINS] (Implement immediately) | | P1 | High | Medium | [IMPORTANT_WORK] (Schedule in next quarter) | | P2 | Medium | Low | [NICE_TO_HAVES] (Fit into roadmap) | | P3 | Low | High | [DEFER_OR_DROP] (Revisit later if still relevant) | **SECTION 11: KNOWLEDGE TRANSFER & DOCUMENTATION** Capture institutional knowledge for future teams: **Technical Artifacts:** - Architecture diagrams and technical decisions - Performance data and optimization learnings - Security considerations and compliance notes - Deployment procedures and operational runbooks **Process Artifacts:** - Updated process documentation incorporating improvements - Templates/checklists for future projects - Decision frameworks for similar situations **Tribal Knowledge Codification:** - "Things we wish we knew at the start" - Non-obvious gotchas and edge cases - Workarounds and their rationale (temporary vs. permanent) **Where to Store:** [KNOWLEDGE_BASE_LOCATION] (Confluence, Notion, internal wiki, etc.) **Maintenance:** Who will keep this updated? [OWNER] **SECTION 12: FORWARD-LOOKING RECOMMENDATIONS** Apply learnings to upcoming work: **Similar Upcoming Projects:** List 2-3 upcoming initiatives that can benefit from these learnings. **Proactive Applications:** For each upcoming project: - Which lessons from this post-mortem are most relevant? - What specific actions should we take at project kickoff to avoid repeating mistakes? - What success patterns should we deliberately replicate? **Organizational Changes:** Any broader changes needed beyond specific action items? - Training/skill development needs - Tool/technology investments - Team structure or staffing adjustments - Cultural/behavioral shifts **OUTPUT REQUIREMENTS** - Balance honesty with psychological safety (identify problems without blaming people) - Provide specific, actionable recommendations (not vague "improve X") - Use quantitative evidence wherever possible (metrics, timelines, costs) - Celebrate successes alongside analyzing failures (positive reinforcement) - Focus on systemic root causes, not surface symptoms - Create forward-looking action plan with owners and deadlines - Make it skimmable for executives (clear summaries, visual elements) **DELIVERABLE FORMAT** - 12-20 page comprehensive post-mortem report - Executive summary (1-2 pages) suitable for leadership - Detailed analysis sections (8-12 pages) - Action item tracker with owners, deadlines, priorities (1-2 pages) - Appendix with supporting data, timelines, metrics (as needed) **FOLLOW-UP PROCESS** - Share draft with project participants for feedback before finalizing (ensures accuracy, builds trust) - Present findings in team retrospective meeting (discuss, clarify, build consensus) - Track action item completion in monthly follow-ups - Re-assess impact in 3-month and 6-month reviews (did changes work?) - Archive in searchable knowledge base for future reference

💡 Pro Tip

Replace all placeholders (highlighted in orange) with specific project details. The most valuable post-mortems are brutally honest yet blameless—focus on systems and decisions, not individuals. Include concrete metrics showing expected vs. actual outcomes. The goal is organizational learning, not individual judgment.

The Logic Behind This Prompt

1. Blameless Culture Framework (Psychological Safety First)

WHY IT MATTERS: The single biggest barrier to effective post-mortems is fear—team members withhold critical information because they're afraid of punishment, judgment, or career damage. "Who messed up?" thinking creates defensive behavior where people hide mistakes, downplay problems, and focus on self-protection rather than organizational learning. Research from Google's Project Aristotle and Amy Edmondson's work on psychological safety shows that high-performing teams surface and discuss failures openly, while low-performing teams hide them until they metastasize into crises. This prompt embeds blameless culture as foundational principle: Assume everyone acted with best intentions given information available at the time. Focus on systems, processes, and decisions—not on punishing individuals. When database crashes due to missing load testing, the question isn't "Why didn't engineer X run load tests?" but "Why do our processes allow code to reach production without validated non-functional requirements?" This reframing shifts from individual accountability (which creates fear) to systemic accountability (which creates improvement). Blameless doesn't mean accountability-free—decisions still have consequences—but it means recognizing that individual mistakes are usually symptoms of systemic gaps: unclear ownership, missing quality gates, inadequate training, impossible deadlines, poor tooling. By analyzing root causes at system level, you fix problems that affect many projects, not just punish individuals for one-time mistakes. This approach also encourages early problem reporting: If engineer discovers critical bug, in blame culture they hide it (fear); in blameless culture they escalate immediately (safety). The practical impact: Teams with psychological safety report 30-50% more problems but have 20-30% fewer production incidents because problems get fixed early rather than hidden until catastrophic failure.

2. 5 Whys Root Cause Analysis (Drill Beyond Surface Symptoms)

WHY IT MATTERS: Most post-mortems stop at surface-level symptoms rather than drilling to root causes, leading to superficial action items that don't prevent recurrence. "The problem was poor communication" → Action: "Improve communication" is useless because it doesn't identify why communication broke down or how to fix it. The 5 Whys technique, developed by Toyota for manufacturing quality but applicable to any domain, forces deep causal analysis by repeatedly asking "Why did this happen?" until reaching actionable root cause. Example: Problem—"API went down during product launch causing 2-hour outage." Why 1—"Server ran out of memory." Why 2—"Traffic exceeded capacity by 5×." Why 3—"Load testing only simulated 1× expected traffic, not realistic peak scenarios." Why 4—"Load testing requirements weren't clearly defined in launch checklist." Why 5 (Root Cause)—"We lack standardized launch readiness criteria enforcing non-functional requirement validation." Now you have actionable fix: Create launch checklist requiring load testing at 3-5× projected peak traffic with sign-off from ops team. This prevents recurrence across all future launches, not just patches this one incident. The rule of thumb: If your "why" analysis doesn't eventually point to something changeable (process, tool, decision framework, resource allocation), you haven't drilled deep enough. "Market conditions changed" isn't a root cause—it's external reality. "We didn't build market sensing mechanisms to detect changes early" is root cause. "Engineer made mistake" isn't root cause—it's human error (inevitable). "Our code review process doesn't catch this error class" is root cause. By systematically applying 5 Whys to each significant challenge, you build library of systemic improvements that compound over time: Each post-mortem strengthens processes, reducing failure probability in subsequent projects.

3. Balanced Success-Failure Analysis (Celebrate What Worked)

WHY IT MATTERS: Traditional post-mortems are failure-focused: "What went wrong?" "What do we need to fix?" This creates negative, demoralizing experience where team associates retrospectives with criticism rather than learning. It also misses critical opportunity to systematize successes. High-performing teams don't just avoid repeating mistakes—they deliberately replicate what works. This prompt mandates balanced analysis: Section 4 (What Went Well) receives equal treatment to Section 5 (What Went Wrong), with structured template asking: What happened? Why did it work? How do we replicate it? For example: Success—"Real-time collaboration feature launched with zero critical bugs despite complex CRDT implementation." Why it worked—"Senior engineer built proof-of-concept validating core algorithm in Week 2, exposing edge cases early. Team invested 3 weeks hardening PoC before scaling to full feature. Architecture review caught potential race conditions." Replicability—"Adopt 'PoC-first' approach for all technically risky features: Build minimal validation prototype before committing to full implementation. Formalize architecture review for distributed systems features." By documenting and systematizing this success pattern, you ensure future teams benefit from same risk-reduction approach. The psychological impact is also significant: Teams that reflect on successes alongside failures maintain morale and motivation. Research shows that balanced retrospectives (celebrating wins + analyzing losses) produce 40-50% more actionable improvements than failure-only retrospectives because team is energized rather than demoralized, creative rather than defensive. The practical structure: Aim for 5-10 documented successes and 5-10 documented failures per post-mortem. If you can't find 5 successes in any project—even failed projects have partial wins—you're not looking hard enough or team is too demoralized to see them.

4. Decision Quality vs. Outcome Quality Separation (Hindsight Analysis)

WHY IT MATTERS: Humans suffer from outcome bias: We judge decision quality by outcome rather than by information available at decision time. This leads to two errors: (1) Condemning good decisions that had bad outcomes due to unforeseeable factors ("we chose React, but it turned out Svelte would've been better"—if React was right choice given 2021 information, it's still a good decision even if 2024 hindsight suggests alternative), and (2) Reinforcing bad decisions that got lucky ("we skipped security audit and nothing bad happened"—this was still bad decision that happened to avoid consequences this time, but creates false confidence for future). This prompt separates decision quality from outcome quality using 2×2 matrix: Good Decision/Good Outcome (right call that worked—replicate decision process), Good Decision/Bad Outcome (right call with bad luck—would make same decision again, no process change needed), Bad Decision/Good Outcome (wrong call that got lucky—must correct process despite positive outcome to avoid future failures), Bad Decision/Bad Outcome (wrong call that failed—learn and change immediately). Example: Decision—"Chose MongoDB over PostgreSQL for flexibility despite team knowing PostgreSQL better." Outcome—Project struggled with MongoDB learning curve, missed timeline by 4 weeks. Analysis: Bad Decision/Bad Outcome. At decision time, we had information that team lacked MongoDB expertise and project had tight timeline—should have chosen PostgreSQL (known technology) over MongoDB (unknown) given time constraint. Lesson: When timeline is constrained, default to technologies team knows rather than optimal-but-unfamiliar alternatives. The matrix prevents hindsight bias: Good Decision/Bad Outcome example—"Chose AWS despite higher cost for reliability, but AWS had regional outage affecting us." This was still right decision given requirements; bad outcome was due to unforeseeable outage, not bad decision-making. Don't change process. This analytical rigor improves future decision-making by focusing on decision process quality (what information did we consider? did we evaluate trade-offs? did we align with constraints?) rather than outcome-driven thinking (it worked/failed, therefore it was right/wrong decision).

5. Actionable Recommendations with Owners, Deadlines, and Success Metrics

WHY IT MATTERS: The vast majority of post-mortem reports die in knowledge bases, never implemented. Classic failure pattern: Team invests 20 hours analyzing project, produces 50-page report with insightful findings, shares in meeting, everyone nods thoughtfully, then... nothing changes. Three months later, next project repeats same mistakes because insights never became actions. Research on organizational learning shows that "awareness" doesn't drive change—only committed action with accountability does. This prompt mandates operationalizing every lesson into concrete action item with three components: (1) WHAT—Specific, measurable change (not "improve testing" but "add automated load testing stage to CI/CD pipeline requiring 3× traffic simulation before production deployment"), (2) WHO—Single owner accountable for completion (not "engineering team" but "Sarah Chen, Senior DevOps Engineer"), (3) WHEN—Target deadline creating urgency (not "sometime next quarter" but "March 15, 2024"). Additionally, each action requires success metric defining how you'll know if improvement worked: "Load test failures caught in CI before production" with target "0 production performance incidents due to capacity issues in next 6 months." This transforms post-mortem from passive reflection to active improvement system. The prioritization matrix (P0: High Impact/Low Effort through P3: Low Impact/High Effort) ensures focus on quick wins and high-value work rather than boiling the ocean. P0 actions (high impact, low effort) get implemented immediately—these are "no-brainer" improvements taking days-to-weeks that prevent major problems. P1 actions (high impact, medium effort) get scheduled in next quarter's roadmap. P2-P3 actions get deferred unless circumstances change. The follow-up process (monthly tracking, 3-month and 6-month reviews) closes accountability loop: Did we actually implement changes? Did they have intended impact? This continuous improvement cycle compounds: Each project improves processes slightly, raising quality bar for next project, which improves further, creating upward spiral of organizational capability.

6. Forward-Looking Knowledge Transfer (Institutional Memory Capture)

WHY IT MATTERS: Post-mortems are often backward-looking—"what happened in past project"—without explicit connection to future work. This misses the core purpose: learning from past to improve future. Additionally, knowledge captured in post-mortem documents is often write-only—created once, never referenced again—because it's not integrated into workflows where teams actually work. This prompt structures forward-looking application: Section 11 (Knowledge Transfer) captures technical artifacts, process improvements, and tribal knowledge in formats useful for future teams (architecture diagrams, runbooks, updated templates, decision frameworks). Section 12 (Forward-Looking Recommendations) explicitly identifies 2-3 upcoming projects that can benefit from these learnings and prescribes specific actions to take at their kickoff to avoid repeating mistakes. Example: Upcoming project is mobile app rewrite. This post-mortem learned "mobile platform differences (iOS vs. Android) caused 6-week delay due to last-minute incompatibility discovery." Forward-looking action: "At mobile app rewrite kickoff, allocate first 2 weeks to cross-platform compatibility validation. Build 'Hello World' implementation on both platforms exercising all planned technical capabilities before full development." By proactively applying lessons at start of next project, you prevent recurrence rather than discovering same problem again months into work. The knowledge base integration ensures durability: Store post-mortem and artifacts in searchable location (Confluence, Notion, internal wiki) with clear ownership for maintenance. Tag with relevant keywords (technology stack, project type, team) so future teams can find similar situations. Some organizations create "pre-mortem" practice: Before starting project, search knowledge base for post-mortems from similar past projects, extract top 10 lessons, and explicitly plan mitigation at project kickoff. This transforms post-mortem from reactive autopsy into proactive risk management, creating institutional memory that makes each new project better than the last.

Example Output Preview

📊 Scenario: TaskFlow Mobile App Launch (Mixed Success)

Context: Series B SaaS company launching native mobile apps (iOS + Android) to complement existing web product. Project: 7 months, team of 12 (4 iOS, 4 Android, 2 backend, 2 QA). Outcome: Launched 5 weeks late, achieved 15K downloads vs. 25K target (60% of goal), 4.2★ rating vs. 4.5★ target.

EXECUTIVE SUMMARY

Project Overview: TaskFlow Mobile aimed to deliver native iOS and Android apps enabling mobile-first project management for our 50K web users, targeting 25K mobile app users within first quarter post-launch.

Outcome Summary: Partial success. Launched 5 weeks behind schedule (7 months vs. 6-month target), achieved 15K downloads (60% of 25K target), and 4.2★ average rating (84% of 4.5★ target). Revenue impact: $280K MRR vs. $400K projected (-30%). Post-launch stability good (99.2% uptime, 15 P0 bugs fixed within first month). Key wins: Real-time sync worked flawlessly, offline mode exceeded expectations. Key misses: iOS performance issues (laggy animations, 1-2 second delays), Android compatibility problems (crashes on Samsung devices), launch delayed by cross-platform feature parity challenges.

Key Learnings (Top 5):

Cross-platform complexity underestimated by 70%: Assumed iOS and Android teams could work independently with 90% shared API. Reality: 40% of features required platform-specific implementations (camera integration, notifications, deep linking), causing 4-week delay and technical debt.
Performance testing only on new devices masked real-world issues: QA tested on iPhone 13 and Pixel 6. 30% of users have iPhone 8-11 and mid-range Android where performance was 2-3× worse. Should have tested on 3-year-old device range.
Real-time sync architecture was our biggest technical win: Invested 3 weeks building robust offline-first architecture with conflict resolution. Zero sync bugs in production. This pattern should be replicated for all mobile features requiring server synchronization.
Staggered launch (iOS first, Android 3 weeks later) created operational chaos: Marketing, support, and product teams weren't prepared to support two separate launch cycles. Confused messaging, duplicated effort, user frustration ("why is Android missing X feature?"). Future launches should be simultaneous or clearly communicated as phased.
Lack of dedicated mobile PM was critical gap: Web PM managed mobile as side project. Mobile-specific concerns (app store optimization, platform guidelines, mobile UX patterns) were afterthoughts. Need specialized mobile product expertise for future mobile initiatives.

Critical Action Items (Top 5):

P0: Create mobile performance testing standard: Require testing on 3-year-old devices (iPhone X, Samsung Galaxy S9 tier) before production. Target: <16ms frame time (60fps), <2 second cold start. (Owner: Alex Kim, Mobile Lead | Deadline: Feb 1, 2024)
P0: Fix iOS performance regressions: Profile and optimize laggy animations, reduce main thread blocking, implement progressive loading. Target: 4.5★+ rating within 8 weeks. (Owner: iOS team | Deadline: Jan 31, 2024)
P1: Hire dedicated Mobile Product Manager: Recruit PM with 5+ years mobile app experience to own mobile roadmap and ensure platform-appropriate decisions. (Owner: Emma Rodriguez, Head of Product | Deadline: March 15, 2024)
P1: Establish cross-platform architecture patterns: Document learnings on what should be shared vs. platform-specific. Create reusable component library for common patterns. (Owner: Mobile architecture team | Deadline: Feb 28, 2024)
P1: Standardize launch process for multi-platform releases: Create launch playbook defining simultaneous vs. staggered criteria, communication templates, support readiness checklists. (Owner: Julia Santos, Launch PM | Deadline: March 1, 2024)

Overall Assessment: This project achieved core technical goals (working mobile apps, solid sync architecture, good post-launch stability) but underperformed on timeline, user acquisition, and user satisfaction due to underestimated cross-platform complexity and performance optimization gaps. The most significant success was real-time sync architecture—zero sync bugs despite complex offline-first requirements proves value of upfront investment in foundational architecture. The most significant failure was launching with performance problems that should have been caught in testing—damaged first impressions (4.2★ rating, negative reviews citing lag) that will take months to recover from. Single biggest takeaway: Mobile development requires specialized expertise (performance optimization, platform nuances, app store dynamics) that we tried to bolt onto web-focused team. For future mobile initiatives, invest in dedicated mobile talent and mobile-specific processes rather than treating mobile as "web with smaller screens."

SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS

Objective 1: Launch mobile apps (iOS + Android) by Q2 end

• Target: June 30, 2023 (6 months from kickoff)
• Actual Result: August 8, 2023 (iOS: July 18, Android: August 8) — 5.5 weeks late
• Variance: +23% timeline overrun
• Achievement Status: ⚠️ Partially Met (delivered but late)
• Analysis: Timeline delay stemmed from three factors: (1) Cross-platform feature parity took 4 weeks longer than estimated (40% of features required platform-specific implementations vs. assumed 10%), (2) iOS performance optimization required unplanned 2-week sprint after beta testing revealed lag on older devices, (3) App Store review process took 9 days vs. expected 2-3 days due to initial rejection for privacy policy issues. First two factors were within our control (estimation failure, testing gaps); third was external but predictable (should have buffered for review delays).

Objective 2: Achieve 25,000 downloads in first quarter post-launch

• Target: 25,000 downloads by November 8, 2023 (3 months post-launch)
• Actual Result: 15,200 downloads by November 8, 2023
• Variance: -39% vs. target (60.8% achievement)
• Achievement Status: ❌ Not Met
• Analysis: Download shortfall driven by: (1) Late launch reduced available user acquisition time (5 weeks less runway), (2) 4.2★ initial rating discouraged downloads—app store conversion rate 2.8% vs. industry benchmark 5% for 4.5★+ apps, (3) Staggered iOS/Android launch confused marketing messaging and split promotional efforts, (4) Performance issues led to negative word-of-mouth (social media complaints, negative reviews mentioning "laggy" and "buggy"). If we'd launched on time with 4.5★ rating, estimated downloads would be 22K-24K (closer to target). The 4.2★ rating was self-inflicted wound from performance testing gaps.

Objective 3: Maintain 4.5+ star average rating on both app stores

• Target: 4.5★+ average (iOS App Store + Google Play)
• Actual Result: 4.2★ average (iOS: 4.3★ based on 847 reviews, Android: 4.1★ based on 623 reviews)
• Variance: -0.3 stars (-6.7%)
• Achievement Status: ❌ Not Met
• Analysis: Rating driven down by two primary complaint categories: (1) Performance issues (38% of 1-3★ reviews mentioned "slow," "laggy," "freezing")—concentrated on iOS 12-14 devices and mid-range Android, (2) Android-specific crashes on Samsung devices (22% of Android negative reviews mentioned crashes)—traced to incompatibility with Samsung's custom Android UI layer that wasn't caught in testing (we tested on Pixel only). The 4.2★ rating is recoverable—post-launch hotfixes addressed major performance issues and ratings have trended up (Week 1: 3.9★ → Week 8: 4.2★ → Current trajectory suggests 4.4★ by Month 4 if improvements continue). However, initial negative reviews are permanent and affect discoverability (app stores algorithmically demote apps with <4.3★ ratings in search results).

Objective 4: Achieve feature parity with web app for core workflows

• Target: 100% of "core workflows" (task creation, assignment, comments, file attachments, notifications, real-time collaboration) working on mobile
• Actual Result: 90% feature parity achieved; missing: bulk task operations, advanced filtering, custom fields (deferred to v1.1)
• Variance: -10% features
• Achievement Status: ✅ Met (90% considered sufficient for core workflows; deferred features are "advanced" not "core")
• Analysis: Successfully delivered all core task management, collaboration, and notification features with mobile-appropriate UX. Real-time sync exceeded expectations—changes reflected across devices in <500ms, offline mode handled disconnections gracefully. The 10% deferred features (bulk operations, advanced filters, custom fields) were consciously cut during Week 18 scope negotiation when timeline pressure mounted. Decision was correct: These features are used by <15% of power users; focusing on 85% use case was right prioritization. Post-launch usage data validates: 92% of users' mobile sessions involve only "core" features we shipped.

Overall Success Rate: 1.5 of 4 objectives fully met (37.5% success rate)

Met: Feature parity (Objective 4). Partially Met: Timeline (Objective 1, delivered but late). Not Met: Downloads (Objective 2), Ratings (Objective 3). The partially/not met objectives are interconnected: Late launch reduced download window, performance issues tanked ratings, low ratings suppressed downloads. Root cause traces to two core failures: underestimated cross-platform complexity (timeline impact) and inadequate performance testing (rating/download impact).

SECTION 5: WHAT WENT WRONG (Challenges & Failures)

Challenge 1: iOS Performance Degradation on Older Devices

• Impact: 38% of negative reviews cited performance issues. Delayed launch by 2 weeks for optimization sprint. Damaged brand perception ("TaskFlow mobile is slow").
• Quantified Cost: 2-week timeline delay, estimated 2,000-3,000 lost downloads due to negative reviews, ~$40K MRR impact.

5 Whys Root Cause Analysis:

• Problem: iOS app experienced laggy animations and 1-2 second delays on iPhone 8-11 devices (representing 30% of user base).
• Why 1: UI rendering blocked main thread, causing dropped frames (measured: 20-30 fps instead of 60 fps target).
• Why 2: Heavy JSON parsing and image processing executed synchronously on main thread instead of background threads.
• Why 3: Developers optimized for newest devices (iPhone 13) where synchronous operations were "fast enough" and didn't notice blocking.
• Why 4: QA testing exclusively used iPhone 13 and 14 devices; no testing on 3-year-old hardware representing significant user base.
• Why 5 (Root Cause): Mobile testing standards don't mandate device range testing. No documented requirement for testing on devices 2-3 generations old (iPhone 8-11, Samsung S9-S10 tier).

Contributing Factors: (1) iOS team lacked senior engineer with performance optimization expertise—would have caught main thread blocking in code review. (2) Xcode Instruments profiling not part of standard development workflow—performance issues weren't visible until beta. (3) Beta testing recruited from internal employees who predominantly had newer devices.

Warning Signs We Missed: Beta tester feedback (Week 22): "App feels a bit sluggish on my personal iPhone XR." Dismissed as isolated issue. Should have triggered device-specific investigation.

SECTION 6: DECISION ANALYSIS

Decision 1: Build Native Apps (iOS/Android) vs. Cross-Platform Framework (React Native/Flutter)

• Context: Month 0, choosing mobile development approach. Options: Native (separate iOS Swift + Android Kotlin codebases), React Native, Flutter.
• Choice Made: Native apps. Rationale: Team had iOS and Android specialists, native provides best performance and access to latest platform features, avoids cross-platform framework lock-in.
• Outcome: Delivered high-quality apps with platform-appropriate UX. Performance ceiling was high (sync architecture could achieve sub-500ms latency). However, development was slower than anticipated (code duplication, feature parity coordination overhead).
• Hindsight Assessment: ✅ Good Decision, Mixed Outcome. Native was correct strategic choice for long-term product quality. Performance and UX are demonstrably better than competitors using React Native (user feedback: "feels like real iOS app, not web wrapper"). The development speed penalty was real but acceptable given 7-month timeline. Would make same decision again.
• Lesson: Native was right call, but we underestimated coordination overhead. Next time: (1) Build shared API specification first before splitting iOS/Android development, (2) Establish weekly cross-platform sync meetings from Day 1, not Month 3 when divergence became problematic, (3) Identify "platform-specific" vs. "truly shared" features upfront (we assumed 90% shared, reality was 60%).

Decision 2: Staggered Launch (iOS First, Android 3 Weeks Later)

• Context: Week 20, facing timeline pressure. iOS development ahead of Android. Options: Delay both until Android ready (pushes launch back 3 weeks), launch iOS immediately and Android when ready (staggered), cut features to sync timelines.
• Choice Made: Staggered launch. Rationale: iOS represents 60% of user base (higher priority), 3-week delay costs $50K-70K in foregone revenue, getting iOS users early creates feedback loop to improve Android before its launch.
• Outcome: iOS launched July 18, Android August 8. However, staggered launch created: (1) Marketing confusion (messaging "Mobile App Launch!" then "Now on Android Too!" diluted impact), (2) Support burden (answering "when is Android coming?" for 3 weeks), (3) User frustration (Android users felt deprioritized, negative sentiment on social media), (4) Operational duplication (two separate launch campaigns, two sets of materials).
• Hindsight Assessment: ❌ Bad Decision, Bad Outcome. The revenue math was correct ($50-70K gain from early iOS launch), but we didn't account for hidden costs: marketing effectiveness reduction (~30% less impact from split campaigns), support overhead (estimated $15K in extra support time), brand damage from Android user frustration (hard to quantify but real). Net benefit was likely <$20K, not worth the operational chaos and brand risk.
• Lesson: Future multi-platform launches should be simultaneous unless delay is >6 weeks (longer delay justifies staggered approach). For 3-week differences, absorb the delay and launch together. If forced to stagger, invest heavily in communication strategy: "iOS first, Android in 3 weeks" messaging upfront, incentives for Android users to wait (early adopter bonuses), pre-registration to build anticipation.

SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS

Category: Technical/Architecture

Lesson 1: Offline-first architecture with robust conflict resolution is critical success factor for mobile apps with real-time collaboration requirements.

• Evidence: We invested 3 weeks (Week 8-11) building foundational sync architecture using CRDT principles with offline queue and conflict resolution. Result: Zero sync bugs in production, <500ms sync latency, graceful offline handling. This was our highest-rated feature (user feedback: "works perfectly even on subway").
• Action Item: Document offline-first architecture pattern and create reusable library for future mobile features requiring server sync. Include: offline queue implementation, conflict resolution algorithms, network retry logic with exponential backoff, unit test suite for edge cases.
• Owner: Michael Torres, Senior Mobile Architect
• Deadline: February 15, 2024
• Success Metric: Next mobile feature requiring sync reuses library with <1 week integration time (vs. 3 weeks building from scratch) and zero sync bugs in first month post-launch.

Category: Process/Workflow

Lesson 2: Mobile testing must mandate device range spanning 3-year-old hardware, not just newest flagships, to catch performance regressions affecting significant user segments.

• Evidence: QA tested only on iPhone 13/14 and Pixel 6. 30% of users have iPhone 8-11 and mid-range Android (Samsung A-series) where performance was 2-3× worse. Cost: 2-week delay for optimization, damaged ratings, lost downloads.
• Action Item: Create mobile device testing standard mandating: (1) Test matrix including devices 2-3 generations old (currently: iPhone X-11, Samsung S9-S10, Pixel 3-4), (2) Performance targets: <16ms frame time (60fps), <2 second cold start, <100ms tap-to-response latency, (3) Automated performance testing in CI measuring frame rate and startup time on simulator approximating older device specs, (4) Real device testing on physical older hardware before beta (not just emulators).
• Owner: Lisa Patel, Mobile QA Lead
• Deadline: January 31, 2024
• Success Metric: 100% of mobile releases pass device range testing before production. Zero performance regressions reported in reviews for next 3 mobile releases (targeting <5% of reviews mentioning performance issues vs. current 38%).

[Additional lessons 3-10 following same structure, covering team composition gaps, launch process improvements, estimation calibration, cross-platform coordination, etc.]

Prompt Chain Strategy

For optimal results, break the post-mortem analysis into three sequential prompts that build comprehensive organizational learning:

🔗 Step 1: Data Collection & Timeline Reconstruction (Foundation)

Objective: Gather factual information about what happened without interpretation or judgment.

You are facilitating a blameless post-mortem. Help me collect objective data about this project: **Project:** [PROJECT_NAME] **Timeline:** [START_DATE] to [END_DATE] **Team:** [TEAM_DETAILS] **Outcome:** [SUCCESS_OR_FAILURE_DESCRIPTION] **Task 1: Objectives & Metrics Documentation** List all original project objectives with measurable success criteria: - Objective 1: [GOAL] | Target: [METRIC] - Objective 2: [GOAL] | Target: [METRIC] ... (continue for all objectives) Then document actual outcomes: - Outcome 1: [ACTUAL_RESULT] | Variance: [DELTA_VS_TARGET] - Outcome 2: [ACTUAL_RESULT] | Variance: [DELTA_VS_TARGET] **Task 2: Chronological Timeline Construction** Build month-by-month (or week-by-week for shorter projects) timeline: **Month 1:** [ACTIVITIES_AND_DECISIONS] **Month 2:** [ACTIVITIES_AND_DECISIONS] ... (continue through project lifecycle) For each period, note: - Major milestones achieved or missed - Key decisions made and rationale at the time - Unexpected challenges that emerged - Pivot points or course corrections **Task 3: Stakeholder Perspective Gathering** Collect input from different roles (maintain blameless tone): - Engineering perspective: Technical challenges? Surprises? What worked/didn't work? - Product perspective: Requirement clarity? Scope changes? User feedback? - Design perspective: UX decisions? Usability findings? Design debt? - QA perspective: Testing coverage? Bugs found/missed? Quality concerns? - Operations/Support perspective: Deployment issues? User complaints? Operational burden? **Task 4: Quantitative Data Compilation** Gather all available metrics: - Timeline data (planned vs. actual durations) - Budget data (estimated vs. actual costs) - Quality metrics (bugs found, incidents, performance measurements) - User metrics (adoption, satisfaction, ratings, feedback) - Team metrics (velocity, morale, turnover if relevant) Output a comprehensive data package with objective facts, timelines, metrics, and multi-perspective input.

Expected Output: Comprehensive data collection document containing: 3-8 original objectives with measurable targets and actual outcomes (with % variance); month-by-month or week-by-week project timeline detailing 15-25 significant events, decisions, and milestones; stakeholder perspectives from 5-8 different roles capturing 20-30 distinct observations; quantitative metrics covering timeline (planned vs. actual), budget (estimated vs. actual), quality (bug counts, incident frequency), user satisfaction (ratings, NPS, feedback themes), and team velocity. This factual foundation prevents post-mortem from devolving into opinion or revisionist history.

🔗 Step 2: Root Cause Analysis & Pattern Identification (Investigation)

Objective: Analyze data to identify systemic root causes of successes and failures.

Using the data collected in Step 1, conduct deep root cause analysis: **SUCCESSES ANALYSIS** For each positive outcome or objective exceeded: **Success:** [WHAT_WENT_WELL] Apply "5 Whys" to understand success: - Why did this succeed? [REASON_1] - Why did [REASON_1] happen? [REASON_2] - Why did [REASON_2] happen? [REASON_3] - Continue until reaching systemic enabler (process, decision, resource, culture) **Replicability:** How can we systematize this success? What made it possible that we can apply to future projects? **FAILURES ANALYSIS** For each negative outcome, missed objective, or significant challenge: **Challenge:** [WHAT_WENT_WRONG] Apply "5 Whys" root cause analysis: - Problem: [SURFACE_PROBLEM] - Why 1: [IMMEDIATE_CAUSE] - Why 2: [DEEPER_CAUSE] - Why 3: [SYSTEM_CAUSE] - Why 4: [PROCESS_GAP] - Why 5 (Root Cause): [SYSTEMIC_ROOT_CAUSE] **Contributing Factors:** What other conditions made this problem worse or more likely? **Warning Signs:** Were there early indicators we missed? **Systemic vs. Isolated:** Is this one-time issue or symptom of broader process gap? **DECISION RETROSPECTIVE** For 5-8 major decisions, assess using Decision Quality vs. Outcome Quality framework: **Decision:** [DECISION_MADE] - **Information at decision time:** What did we know? What were the options? - **Rationale:** Why did we choose this path? - **Outcome:** What happened? Expected vs. actual impact. - **Quality Assessment:** - ✅ Good Decision/Good Outcome → Replicate decision process - ⚠️ Good Decision/Bad Outcome → Accept; would decide same way again - ⚠️ Bad Decision/Good Outcome → Lucky; fix decision process despite positive outcome - ❌ Bad Decision/Bad Outcome → Learn and change immediately - **Lesson:** What does this teach us about decision-making? **PATTERN IDENTIFICATION** Look for recurring themes across successes and failures: - What patterns emerge? (e.g., "Every timeline delay traced to underestimated integration complexity") - What systemic gaps enable problems? (e.g., "No process enforces cross-functional review before commitment") - What cultural/behavioral patterns drive outcomes? (e.g., "Team afraid to escalate bad news early") Output comprehensive root cause analysis with 8-15 systemic findings (not surface symptoms).

Expected Output: Root cause analysis documenting: 5-10 successes with 5 Whys analysis revealing systemic enablers (e.g., "Success: Zero sync bugs. Root enabler: 3-week upfront investment in architecture PoC that exposed edge cases early"); 5-10 failures with 5 Whys drilling to actionable root causes (e.g., "Failure: Performance issues. Root cause: Testing standards don't mandate device range validation"); decision retrospective covering 5-8 major decisions with quality/outcome classification; pattern identification revealing 3-5 recurring themes across project (e.g., "Pattern: Communication breakdowns at team boundaries—iOS/Android, Engineering/Product, Dev/QA"). This analysis transforms raw data into insights ready for action planning.

🔗 Step 3: Actionable Recommendations & Forward Planning (Implementation)

Objective: Convert insights into concrete action plan with accountability and forward application.

Based on root cause analysis from Step 2, create actionable improvement plan: **SECTION 1: Lessons Learned Catalog** For each root cause identified in Step 2, formulate lesson learned: **Lesson:** [CLEAR_LESSON_STATEMENT] - **Category:** Technical / Process / Team / Planning / Communication - **Evidence:** What happened that taught us this? (Reference specific events from timeline) - **Impact:** How significant is this lesson? (High/Medium/Low based on cost of problem or value of success) Generate 15-20 lessons covering successes to replicate and failures to prevent. **SECTION 2: Action Item Development** For each high and medium impact lesson, create specific action item: **Action Item:** [CONCRETE_CHANGE_TO_IMPLEMENT] - **What:** Specific, measurable change (not vague "improve X") - Bad: "Improve testing" - Good: "Add automated performance testing stage to CI requiring 60fps on iPhone X simulator before production" - **Why:** Which lesson does this address? What problem does it prevent/success does it replicate? - **Who:** Single owner accountable for implementation (Name, Role) - **When:** Target deadline (specific date) - **How:** Implementation approach (2-3 sentences on execution plan) - **Success Metric:** How will we measure effectiveness? (Quantitative if possible) **SECTION 3: Prioritization Matrix** Classify all action items by Impact (High/Medium/Low) and Effort (Low/Medium/High): **P0 (High Impact, Low Effort):** [QUICK_WINS] → Implement immediately **P1 (High Impact, Medium Effort):** [IMPORTANT_WORK] → Schedule next quarter **P2 (Medium Impact, Low-Medium Effort):** [NICE_TO_HAVES] → Backlog **P3 (Low Impact or High Effort):** [DEFER] → Revisit later if circumstances change Focus implementation bandwidth on P0 and P1 items. **SECTION 4: Forward Application** Identify 2-3 upcoming projects that can benefit from these learnings: **Upcoming Project:** [PROJECT_NAME] **Relevant Lessons:** Which 5-7 lessons from this post-mortem apply to upcoming project? **Proactive Actions:** What should we do at kickoff of upcoming project to apply lessons? - Avoid repeating mistakes: [PREVENTIVE_ACTIONS] - Replicate success patterns: [REPLICATION_ACTIONS] **SECTION 5: Follow-Up Framework** Establish accountability and tracking: - **Monthly Review:** Track action item completion, update status, unblock impediments - **Quarterly Retrospective:** Assess impact—did changes have intended effect? Any course corrections needed? - **Knowledge Base Integration:** Where/how will these learnings be documented for future team access? - **Communication Plan:** How will findings be shared with broader organization? Output comprehensive action plan (10-15 pages) with prioritized action items, owners, deadlines, success metrics, and forward application strategy.

Expected Output: Actionable improvement plan containing: 15-20 clear lesson statements categorized by domain (Technical, Process, Team, Planning, Communication) with evidence citations and impact ratings; 10-15 specific action items with WHAT (concrete change), WHY (lesson addressed), WHO (single owner with name/role), WHEN (specific deadline), HOW (execution approach), SUCCESS METRIC (quantitative measurement); prioritization matrix classifying actions into P0 (3-5 quick wins for immediate implementation), P1 (5-7 important work for next quarter), P2-P3 (5-8 deferred items); forward application identifying 2-3 upcoming projects with 5-7 relevant lessons and specific preventive/replication actions to take at their kickoff; follow-up framework defining monthly tracking, quarterly retrospectives, knowledge base integration, and communication plan. This deliverable transforms post-mortem from reflection into action.

Human-in-the-Loop Refinements

1. Conduct Post-Mortem Meeting to Validate AI-Generated Analysis

Challenge: AI-generated post-mortems rely on input data provided by user, which may be incomplete, biased, or missing critical context. Important nuances often emerge only through team discussion—interpersonal dynamics, unspoken assumptions, "soft" factors like morale or psychological safety that don't show up in metrics.

Refinement: Use AI-generated post-mortem as discussion starter, not final output: (1) Share draft with all project participants 2-3 days before retrospective meeting. Ask them to review and note: What's accurate? What's missing? What's misinterpreted? (2) Facilitate 90-120 minute blameless retrospective meeting structured around AI analysis sections. Go through each section (Successes, Failures, Decisions, Process) and ask: "Does this match your experience? What would you add or change?" (3) Use meeting to surface information AI couldn't access: Interpersonal conflicts that affected collaboration, team member burnout that reduced productivity, executive pressure that drove suboptimal decisions, information asymmetries where different subteams had different understanding. (4) Capture meeting insights and update post-mortem document with human-validated corrections and additions. The value: AI analysis provides structure and prevents blank-page paralysis, but human discussion reveals truth that metrics and documents can't capture. Post-mortems that skip this step often miss 30-40% of important learnings.

2. Verify Root Causes Through "5 Whys" Exercise with Cross-Functional Participants

Challenge: AI-generated 5 Whys analysis is only as good as the information provided. If user gives incomplete context or stops at surface-level explanations, the root cause analysis will be shallow and action items will miss the mark.

Refinement: Conduct live 5 Whys exercise for top 3-5 failures identified by AI: (1) Assemble cross-functional group (6-10 people) including representatives from all teams involved in the problem. (2) Start with surface problem (e.g., "Database crashed during peak load"). (3) Ask "Why did this happen?" and capture 3-5 possible explanations from group. (4) Vote on most plausible explanation as Why 1. (5) Repeat for Why 2, 3, 4, 5, drilling deeper each time. Stop when group reaches actionable systemic root cause (something you can change—process, tool, decision framework). (6) For each Why level, challenge assumptions: "How do we know this is true? What evidence supports this?" Prevent group from accepting easy but incorrect explanations. (7) Document contributing factors that didn't make main chain but compounded problem. The cross-functional aspect is critical: Engineering sees technical reasons, Product sees requirements issues, QA sees testing gaps—root cause is often at intersection of multiple perspectives. This refinement typically deepens root cause analysis by 2-3 Why levels beyond what AI generates, leading to more impactful action items.

3. Pressure-Test Action Items with "Pre-Mortem on the Action Plan"

Challenge: Action items look good on paper but fail in implementation due to: unrealistic effort estimates, unclear ownership, lack of organizational support, competing priorities that crowd them out, or simply being wrong solution that doesn't actually prevent the problem.

Refinement: Before committing to action plan, run mini pre-mortem exercise: (1) Assume it's 6 months from now. We implemented all action items from post-mortem, yet next project repeated same problems. "Why did our action plan fail?" (2) Brainstorm failure modes for the action plan itself: "No one had time to implement actions" (bandwidth issue), "Actions were implemented but didn't change behavior" (insufficient enforcement), "We fixed symptoms but not root causes" (analysis was shallow), "Actions conflicted with existing processes" (organizational misalignment). (3) For each plausible failure mode, add mitigation: Bandwidth issue → Allocate explicit 20% of next sprint to post-mortem actions. Enforcement issue → Make new process mandatory part of launch checklist with sign-off. Shallow analysis → Conduct additional root cause session on top 2 problems. (4) Revise action items to address failure modes. (5) Assign action item "shepherd" role to someone responsible for driving completion across all items, not just owning individual tasks. This meta-analysis of your action plan increases implementation success rate from typical 30-40% to 60-70%.

4. Conduct "Counterfactual Analysis" to Test Lesson Robustness

Challenge: Post-mortems sometimes draw wrong lessons because they confuse correlation with causation, attribute success/failure to wrong factors, or overgeneralize from single data point. "We succeeded because we used Technology X" might be wrong if real reason was strong team, favorable market conditions, or luck.

Refinement: For each major lesson, conduct counterfactual thought experiment: (1) Identify the lesson's claimed causal relationship (e.g., "Using CRDT architecture caused sync reliability success"). (2) Ask: "If we changed this factor, would outcome change?" Would different architecture have succeeded equally well (strong team could have made other architectures work)? Would same architecture have failed with different team (CRDT requires expertise)? (3) Look for alternative explanations: What else could explain the outcome? Team composition? Resource availability? External factors? (4) Check lesson against historical data: Have we seen this pattern before? Do other companies' experiences validate this? (5) Test specificity: Is lesson too general ("plan better") or too specific ("always use CRDT for sync")? Right level is actionable principle applicable in similar contexts but not dogmatic. (6) Revise lessons to reflect actual causal factors and appropriate scope. Example: Original lesson—"CRDT architecture ensures sync reliability." Refined lesson—"Investing 3 weeks in foundational architecture PoC (in this case CRDT) that validates core technical risk before full feature development significantly reduces production bugs for complex distributed systems features. Applicable when: technical risk is high, wrong choice is costly, upfront investment is <20% of total feature time." This refinement prevents cargo-cult adoption of practices ("they used CRDT so we should too") without understanding context.

5. Establish Action Item Accountability Through Monthly Tracking Ritual

Challenge: The graveyard of good intentions is filled with post-mortem action items that were agreed upon enthusiastically, then forgotten within weeks as teams return to normal work pressures. Without explicit tracking and accountability, 60-70% of post-mortem actions never get implemented.

Refinement: Create lightweight but rigorous tracking ritual: (1) Designate "post-mortem shepherd" (ideally senior IC or manager) responsible for driving action completion, not just tracking. (2) Create visible action item dashboard (Jira epic, Notion board, spreadsheet) showing: Action item, Owner, Deadline, Status (Not Started/In Progress/Blocked/Complete), Impact when complete. Share link in team channels, weekly updates. (3) Conduct 30-minute monthly review meeting with action owners present: Review each P0 and P1 item, owner reports status (2-minute update: what's done, what's blocking, need help?), group problem-solves blockers, adjust deadlines if needed (with justification). (4) For blocked items, assign "unblock buddy" to help owner resolve impediment within 1 week. (5) Celebrate completions publicly—Slack announcements, team meeting shout-outs—to reinforce that post-mortem follow-through is valued. (6) At 3-month mark, conduct impact review: Which completed actions have measurably improved outcomes? Which haven't? Should we adjust approach? (7) Archive completed post-mortems with "Closed Loop" indicator showing X of Y actions completed and impact achieved. This tracking discipline increases action completion from 30-40% to 75-85% and ensures lessons actually change organizational behavior rather than just creating documents.

6. Build Searchable Post-Mortem Library with Tagging and Cross-Referencing

Challenge: Post-mortems are valuable learning artifacts, but most organizations treat them as one-time documents rather than building institutional memory. Future teams can't benefit from past learnings if they can't find or don't know about relevant post-mortems. Knowledge is effectively lost.

Refinement: Systematically build searchable post-mortem library: (1) Create centralized post-mortem repository (Confluence space, Notion database, internal wiki section) with consistent structure—every post-mortem uses same template for discoverability. (2) Tag each post-mortem with rich metadata: Project type (mobile app, backend migration, feature launch), Technologies involved (iOS, React, PostgreSQL), Outcome (success, failure, mixed), Key topics (performance, timeline management, cross-functional collaboration), Team (which org/team conducted this project). (3) Extract "reusable lessons" section at end of each post-mortem summarizing top 10 lessons in bullet format for quick scanning. (4) Cross-reference related post-mortems: "This project faced similar challenges to [Project X Post-Mortem]—see their solutions in Section 5." (5) Create quarterly "post-mortem synthesis" artifact: Review all post-mortems from quarter, identify recurring themes (e.g., "Performance testing gaps appeared in 3 of 5 projects"), escalate systemic issues to leadership with aggregated recommendations. (6) Make post-mortem library part of project kickoff ritual: Before starting new project, search library for similar past projects, extract top 10 lessons, explicitly plan mitigation in kickoff meeting. This transforms post-mortems from reactive autopsies into proactive playbooks. Organizations with mature post-mortem libraries report 25-35% reduction in repeated failures because teams learn from past mistakes before making them.

Member Menu

AiPro Institute™ Prompt Library

Post-Mortem Analysis

The Prompt

The Logic Behind This Prompt

1. Blameless Culture Framework (Psychological Safety First)

2. 5 Whys Root Cause Analysis (Drill Beyond Surface Symptoms)

3. Balanced Success-Failure Analysis (Celebrate What Worked)

4. Decision Quality vs. Outcome Quality Separation (Hindsight Analysis)

5. Actionable Recommendations with Owners, Deadlines, and Success Metrics

6. Forward-Looking Knowledge Transfer (Institutional Memory Capture)

Example Output Preview

Prompt Chain Strategy

🔗 Step 1: Data Collection & Timeline Reconstruction (Foundation)

🔗 Step 2: Root Cause Analysis & Pattern Identification (Investigation)

🔗 Step 3: Actionable Recommendations & Forward Planning (Implementation)

Human-in-the-Loop Refinements

1. Conduct Post-Mortem Meeting to Validate AI-Generated Analysis

2. Verify Root Causes Through "5 Whys" Exercise with Cross-Functional Participants

3. Pressure-Test Action Items with "Pre-Mortem on the Action Plan"

4. Conduct "Counterfactual Analysis" to Test Lesson Robustness

5. Establish Action Item Accountability Through Monthly Tracking Ritual

6. Build Searchable Post-Mortem Library with Tagging and Cross-Referencing

Author: aiinstituteadmin

Leave a Reply Cancel reply

Empower People with AI Education

Courses

Support

AiPro Institute™ Prompt Library

Post-Mortem Analysis

The Prompt

The Logic Behind This Prompt

1. Blameless Culture Framework (Psychological Safety First)

2. 5 Whys Root Cause Analysis (Drill Beyond Surface Symptoms)

3. Balanced Success-Failure Analysis (Celebrate What Worked)

4. Decision Quality vs. Outcome Quality Separation (Hindsight Analysis)

5. Actionable Recommendations with Owners, Deadlines, and Success Metrics

6. Forward-Looking Knowledge Transfer (Institutional Memory Capture)

Example Output Preview

Prompt Chain Strategy

🔗 Step 1: Data Collection & Timeline Reconstruction (Foundation)

🔗 Step 2: Root Cause Analysis & Pattern Identification (Investigation)

🔗 Step 3: Actionable Recommendations & Forward Planning (Implementation)

Human-in-the-Loop Refinements

1. Conduct Post-Mortem Meeting to Validate AI-Generated Analysis

2. Verify Root Causes Through "5 Whys" Exercise with Cross-Functional Participants

3. Pressure-Test Action Items with "Pre-Mortem on the Action Plan"

4. Conduct "Counterfactual Analysis" to Test Lesson Robustness

5. Establish Action Item Accountability Through Monthly Tracking Ritual

6. Build Searchable Post-Mortem Library with Tagging and Cross-Referencing

Author: aiinstituteadmin

Related Posts

Leave a Reply Cancel reply

Empower People with AI Education

Courses

Support