Post-Mortem Analysis - AiPro Institute\u2122 Prompt Library<\/title>\n <style>\n * {\n margin: 0;\n padding: 0;\n box-sizing: border-box;\n }\n\n body {\n font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, sans-serif;\n line-height: 1.6;\n color: #333;\n background: #ffffff;\n padding: 2rem 1rem;\n }\n\n .page-title {\n text-align: center;\n font-size: 2.5rem;\n font-weight: 700;\n margin-bottom: 3rem;\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n -webkit-background-clip: text;\n -webkit-text-fill-color: transparent;\n background-clip: text;\n }\n\n .container {\n max-width: 900px;\n margin: 0 auto;\n }\n\n .card {\n background: white;\n border-radius: 12px;\n box-shadow: 0 4px 6px rgba(0, 0, 0, 0.07);\n overflow: hidden;\n margin-bottom: 2rem;\n }\n\n .card-header {\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n color: white;\n padding: 2rem;\n }\n\n .card-title {\n font-size: 2rem;\n font-weight: 700;\n margin-bottom: 1rem;\n }\n\n .meta-badges {\n display: flex;\n flex-wrap: wrap;\n gap: 0.5rem;\n margin-bottom: 1rem;\n }\n\n .badge {\n background: rgba(255, 255, 255, 0.2);\n padding: 0.4rem 0.8rem;\n border-radius: 6px;\n font-size: 0.85rem;\n font-weight: 500;\n }\n\n .tool-badges {\n display: flex;\n flex-wrap: wrap;\n gap: 0.5rem;\n }\n\n .tool-badge {\n border: 1px solid rgba(255, 255, 255, 0.3);\n padding: 0.3rem 0.7rem;\n border-radius: 6px;\n font-size: 0.8rem;\n }\n\n .card-body {\n padding: 2.5rem;\n }\n\n .section {\n margin-bottom: 2.5rem;\n }\n\n .section-title-container {\n display: flex;\n justify-content: space-between;\n align-items: center;\n margin-bottom: 1rem;\n }\n\n .section-title {\n font-size: 1.5rem;\n font-weight: 700;\n color: #667eea;\n border-left: 4px solid #667eea;\n padding-left: 1rem;\n }\n\n .copy-button {\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n color: white;\n border: none;\n padding: 0.6rem 1.2rem;\n border-radius: 6px;\n cursor: pointer;\n font-size: 0.9rem;\n font-weight: 600;\n transition: transform 0.2s, box-shadow 0.2s;\n }\n\n .copy-button:hover {\n transform: translateY(-2px);\n box-shadow: 0 4px 12px rgba(102, 126, 234, 0.4);\n }\n\n .copy-button:active {\n transform: translateY(0);\n }\n\n .prompt-box {\n background: #f8f9fa;\n border: 1px solid #e0e0e0;\n border-radius: 8px;\n padding: 1.5rem;\n margin-bottom: 1rem;\n font-family: 'Courier New', monospace;\n font-size: 0.95rem;\n line-height: 1.8;\n white-space: pre-wrap;\n word-wrap: break-word;\n }\n\n .placeholder {\n color: #fd7e14;\n font-weight: 600;\n }\n\n .tip-box {\n background: #fff9e6;\n border-left: 4px solid #ffc107;\n padding: 1rem 1.5rem;\n border-radius: 4px;\n margin-top: 1rem;\n }\n\n .tip-title {\n font-weight: 700;\n color: #f57c00;\n margin-bottom: 0.5rem;\n }\n\n .logic-principle {\n margin-bottom: 2rem;\n }\n\n .logic-principle h3 {\n color: #667eea;\n font-size: 1.2rem;\n margin-bottom: 0.5rem;\n }\n\n .logic-principle p {\n color: #555;\n line-height: 1.8;\n }\n\n .example-box {\n border: 2px solid #2196F3;\n border-radius: 8px;\n padding: 1.5rem;\n background: #f0f8ff;\n margin-top: 1rem;\n }\n\n .example-title {\n font-weight: 700;\n color: #1976D2;\n margin-bottom: 1rem;\n font-size: 1.1rem;\n }\n\n .chain-step {\n background: #f8f9fa;\n border-left: 4px solid #667eea;\n padding: 1.5rem;\n margin-bottom: 1.5rem;\n border-radius: 4px;\n }\n\n .chain-step h3 {\n color: #667eea;\n margin-bottom: 1rem;\n }\n\n .expected-output {\n background: white;\n border: 1px solid #e0e0e0;\n padding: 1rem;\n border-radius: 6px;\n margin-top: 1rem;\n font-size: 0.9rem;\n }\n\n .hitl-tip {\n margin-bottom: 1.5rem;\n }\n\n .hitl-tip h3 {\n color: #667eea;\n font-size: 1.1rem;\n margin-bottom: 0.5rem;\n }\n\n .footer-stats {\n display: flex;\n justify-content: space-around;\n padding: 2rem;\n background: #f8f9fa;\n border-radius: 8px;\n margin-top: 2rem;\n }\n\n .stat {\n text-align: center;\n }\n\n .stat-value {\n font-size: 2rem;\n font-weight: 700;\n color: #667eea;\n }\n\n .stat-label {\n color: #666;\n font-size: 0.9rem;\n margin-top: 0.25rem;\n }\n\n @media (max-width: 768px) {\n body {\n padding: 1rem 0.5rem;\n }\n\n .page-title {\n font-size: 1.8rem;\n margin-bottom: 2rem;\n }\n\n .card-header {\n padding: 1.5rem;\n }\n\n .card-title {\n font-size: 1.5rem;\n }\n\n .card-body {\n padding: 1.5rem;\n }\n\n .section-title-container {\n flex-direction: column;\n align-items: flex-start;\n gap: 1rem;\n }\n\n .copy-button {\n width: 100%;\n }\n\n .footer-stats {\n flex-direction: column;\n gap: 1.5rem;\n }\n }\n <\/style>\n<\/head>\n<body>\n <h1 class=\"page-title\">AiPro Institute\u2122 Prompt Library<\/h1>\n \n <div class=\"container\">\n <div class=\"card\">\n <div class=\"card-header\">\n <h2 class=\"card-title\">Post-Mortem Analysis<\/h2>\n <div class=\"meta-badges\">\n <span class=\"badge\">\ud83d\udee0\ufe0f Product & Operations<\/span>\n <span class=\"badge\">\u23f1\ufe0f 35\u201345 minutes<\/span>\n <span class=\"badge\">\ud83d\udcca Intermediate to Advanced<\/span>\n <\/div>\n <div class=\"tool-badges\">\n <span class=\"tool-badge\">ChatGPT<\/span>\n <span class=\"tool-badge\">Claude<\/span>\n <span class=\"tool-badge\">Gemini<\/span>\n <span class=\"tool-badge\">Perplexity<\/span>\n <span class=\"tool-badge\">Grok<\/span>\n <\/div>\n <\/div>\n\n <div class=\"card-body\">\n \n <div class=\"section\">\n <div class=\"section-title-container\">\n <h3 class=\"section-title\">The Prompt<\/h3>\n <button class=\"copy-button\" onclick=\"copyPrompt()\">\ud83d\udccb Copy Prompt<\/button>\n <\/div>\n <div class=\"prompt-box\" id=\"promptText\">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\u2014whether they succeeded spectacularly, failed catastrophically, or fell somewhere in between.\n\n**CRITICAL PRINCIPLE: BLAMELESS CULTURE**\nThis post-mortem focuses on systems, processes, and decisions\u2014NOT 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.\"\n\n**CONTEXT**\nProject\/Initiative Name: <span class=\"placeholder\">[PROJECT_NAME]<\/span>\nType: <span class=\"placeholder\">[PROJECT_TYPE]<\/span> (Product launch, feature release, system migration, incident response, failed initiative, etc.)\nTimeline: <span class=\"placeholder\">[START_DATE]<\/span> to <span class=\"placeholder\">[END_DATE]<\/span> (Duration: <span class=\"placeholder\">[X]<\/span> weeks\/months)\nTeam: <span class=\"placeholder\">[TEAM_COMPOSITION]<\/span> (Size, roles, structure)\nOutcome Classification: <span class=\"placeholder\">[SUCCESS \/ PARTIAL_SUCCESS \/ MIXED \/ FAILURE]<\/span>\n\n**ORIGINAL OBJECTIVES**\nWhat were the stated goals and success criteria?\n<span class=\"placeholder\">[OBJECTIVE_1]<\/span>\n<span class=\"placeholder\">[OBJECTIVE_2]<\/span>\n<span class=\"placeholder\">[OBJECTIVE_3]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_OBJECTIVES]<\/span>\n\n**ACTUAL OUTCOMES**\nWhat actually happened? (Be specific with metrics)\n<span class=\"placeholder\">[OUTCOME_1]<\/span>\n<span class=\"placeholder\">[OUTCOME_2]<\/span>\n<span class=\"placeholder\">[OUTCOME_3]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_OUTCOMES]<\/span>\n\n**POST-MORTEM ANALYSIS FRAMEWORK**\n\n**SECTION 1: EXECUTIVE SUMMARY**\nProvide concise overview for stakeholders who won't read full report:\n\n**Project Overview:** 2-3 sentence description of what was attempted and why\n\n**Outcome Summary:** Did we achieve objectives? What were the results? (Include key metrics: Expected vs. Actual)\n\n**Key Learnings (Top 3-5):**\n1. <span class=\"placeholder\">[MOST_IMPORTANT_LESSON]<\/span>\n2. <span class=\"placeholder\">[SECOND_LESSON]<\/span>\n3. <span class=\"placeholder\">[THIRD_LESSON]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_LESSONS]<\/span>\n\n**Critical Action Items (Top 3-5):**\n1. <span class=\"placeholder\">[HIGHEST_PRIORITY_ACTION]<\/span> (Owner: <span class=\"placeholder\">[PERSON]<\/span>, Deadline: <span class=\"placeholder\">[DATE]<\/span>)\n2. <span class=\"placeholder\">[SECOND_ACTION]<\/span> (Owner: <span class=\"placeholder\">[PERSON]<\/span>, Deadline: <span class=\"placeholder\">[DATE]<\/span>)\n... <span class=\"placeholder\">[ADDITIONAL_ACTIONS]<\/span>\n\n**Overall Assessment:** 1-paragraph synthesis: What went well, what went wrong, what's the single biggest takeaway?\n\n**SECTION 2: TIMELINE OF EVENTS**\n\nCreate detailed chronological narrative of project lifecycle:\n\n**Phase 1: Planning & Kickoff (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Key decisions made: <span class=\"placeholder\">[DECISIONS]<\/span>\n- Assumptions established: <span class=\"placeholder\">[ASSUMPTIONS]<\/span>\n- Resources allocated: <span class=\"placeholder\">[RESOURCES]<\/span>\n- Early warning signs (if any): <span class=\"placeholder\">[WARNING_SIGNS]<\/span>\n\n**Phase 2: Execution (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Major milestones achieved or missed: <span class=\"placeholder\">[MILESTONES]<\/span>\n- Unexpected challenges encountered: <span class=\"placeholder\">[CHALLENGES]<\/span>\n- Adaptation\/pivot decisions: <span class=\"placeholder\">[PIVOTS]<\/span>\n- Critical incidents: <span class=\"placeholder\">[INCIDENTS]<\/span>\n\n**Phase 3: Launch\/Completion (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Go-live events: <span class=\"placeholder\">[EVENTS]<\/span>\n- Initial results\/reactions: <span class=\"placeholder\">[REACTIONS]<\/span>\n- Emergency responses (if any): <span class=\"placeholder\">[RESPONSES]<\/span>\n\n**Phase 4: Post-Launch (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Performance vs. expectations: <span class=\"placeholder\">[PERFORMANCE]<\/span>\n- User feedback and data: <span class=\"placeholder\">[FEEDBACK]<\/span>\n- Adjustments made: <span class=\"placeholder\">[ADJUSTMENTS]<\/span>\n\nFor each phase, include: What was planned? What actually happened? Where did reality diverge from plan?\n\n**SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS**\n\nFor each original objective, analyze performance:\n\n**Objective 1: <span class=\"placeholder\">[OBJECTIVE_NAME]<\/span>**\n- **Target:** <span class=\"placeholder\">[QUANTITATIVE_TARGET]<\/span> (e.g., \"Launch by Q2, achieve 10K users in first month, maintain 99% uptime\")\n- **Actual Result:** <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> (e.g., \"Launched 6 weeks late (Q3), achieved 6.8K users, 97.2% uptime\")\n- **Variance:** <span class=\"placeholder\">[PERCENTAGE_OR_DELTA]<\/span> (e.g., \"-32% on user acquisition, -1.8% on uptime\")\n- **Achievement Status:** \u2705 Exceeded \/ \u2705 Met \/ \u26a0\ufe0f Partially Met \/ \u274c Not Met\n- **Analysis:** Why did we over\/under-perform? What factors drove the variance?\n\nRepeat for all objectives (typically 3-8 objectives per project).\n\n**Overall Success Rate:** X of Y objectives fully met (Z% success rate)\n\n**SECTION 4: WHAT WENT WELL (Successes & Strengths)**\n\nDocument practices, decisions, and team behaviors that should be replicated:\n\n**Success 1: <span class=\"placeholder\">[SUCCESS_DESCRIPTION]<\/span>**\n- **What happened:** Specific description with evidence\/metrics\n- **Why it worked:** Root cause of success\u2014what conditions, decisions, or behaviors enabled this?\n- **Replicability:** Can we systematize this success? How do we ensure it happens again?\n- **Key Contributors:** Teams\/individuals whose actions drove this (celebrating, not singling out)\n\n**Success 2: <span class=\"placeholder\">[SUCCESS_DESCRIPTION]<\/span>**\n[Same structure]\n\nIdentify 5-10 significant successes. These are often overlooked in post-mortems but are critical for positive reinforcement and best practice capture.\n\n**Common categories to explore:**\n- Technical achievements (performance, reliability, scalability beyond expectations)\n- Process innovations (new workflow that accelerated delivery)\n- Team collaboration breakthroughs (cross-functional coordination that worked exceptionally)\n- Risk management wins (anticipated problems that were successfully mitigated)\n- Customer\/user wins (features that delighted users beyond expectations)\n\n**SECTION 5: WHAT WENT WRONG (Challenges & Failures)**\n\nConduct root cause analysis using \"5 Whys\" methodology:\n\n**Challenge 1: <span class=\"placeholder\">[PROBLEM_DESCRIPTION]<\/span>**\n- **Impact:** How did this affect the project? (Timeline delay? Budget overrun? Quality issues? Team morale?)\n- **Quantified Cost:** X weeks delay, $Y budget impact, Z% performance degradation, etc.\n- **5 Whys Root Cause Analysis:**\n - **Problem:** <span class=\"placeholder\">[SURFACE_PROBLEM]<\/span> (e.g., \"Database crashed during peak load\")\n - **Why 1:** <span class=\"placeholder\">[FIRST_WHY]<\/span> (e.g., \"Query load exceeded connection pool capacity\")\n - **Why 2:** <span class=\"placeholder\">[SECOND_WHY]<\/span> (e.g., \"We didn't load test at realistic traffic volumes\")\n - **Why 3:** <span class=\"placeholder\">[THIRD_WHY]<\/span> (e.g., \"Load testing was deprioritized due to timeline pressure\")\n - **Why 4:** <span class=\"placeholder\">[FOURTH_WHY]<\/span> (e.g., \"We lacked clear quality gates requiring load testing before launch\")\n - **Why 5 (Root Cause):** <span class=\"placeholder\">[ROOT_CAUSE]<\/span> (e.g., \"Our development process doesn't enforce non-functional requirements validation\")\n- **Contributing Factors:** Secondary causes that compounded the problem\n- **Warning Signs We Missed:** Were there early indicators we could have caught?\n\n**Challenge 2: <span class=\"placeholder\">[PROBLEM_DESCRIPTION]<\/span>**\n[Same structure]\n\nIdentify 5-10 significant challenges\/failures. Be specific and honest\u2014vague lessons like \"improve communication\" are useless. Drill to actionable root causes.\n\n**SECTION 6: DECISION ANALYSIS (What We'd Do Differently)**\n\nReview major decisions with benefit of hindsight:\n\n**Decision 1: <span class=\"placeholder\">[DECISION_DESCRIPTION]<\/span>**\n- **Context:** What was the situation? What options did we consider?\n- **Choice Made:** What did we decide and why? (Document the rationale at the time\u2014important for understanding decision quality vs. outcome quality)\n- **Outcome:** How did it turn out? Expected vs. actual impact.\n- **Hindsight Assessment:** \n - \u2705 **Good Decision, Good Outcome** (right call that worked)\n - \u26a0\ufe0f **Good Decision, Bad Outcome** (right call with bad luck\u2014would make same decision again)\n - \u26a0\ufe0f **Bad Decision, Good Outcome** (wrong call that got lucky\u2014correct for future)\n - \u274c **Bad Decision, Bad Outcome** (wrong call that failed\u2014learn and change)\n- **Lesson:** With current knowledge, what would we decide differently? Why?\n\n**Decision 2: <span class=\"placeholder\">[DECISION_DESCRIPTION]<\/span>**\n[Same structure]\n\nAnalyze 5-8 critical decisions (technology choices, scope decisions, resource allocation, launch timing, etc.). This separates decision quality from outcome quality\u2014sometimes good decisions have bad outcomes due to unforeseeable factors, and bad decisions get lucky. We want to improve decision-making process, not just outcomes.\n\n**SECTION 7: PROCESS & WORKFLOW ANALYSIS**\n\nEvaluate effectiveness of processes used:\n\n**Process 1: <span class=\"placeholder\">[PROCESS_NAME]<\/span>** (e.g., Sprint Planning, Code Review, QA Testing, Incident Response)\n- **How it worked:** Description of process as practiced (not as documented\u2014often different)\n- **Effectiveness Rating:** Excellent \/ Good \/ Adequate \/ Poor \/ Broken\n- **What worked well:** Specific strengths to preserve\n- **What didn't work:** Specific pain points or failures\n- **Suggested Improvements:** Concrete changes to make process more effective\n- **Comparative Benchmark:** How does our process compare to industry best practices?\n\n**Process 2: <span class=\"placeholder\">[PROCESS_NAME]<\/span>**\n[Same structure]\n\nAnalyze 4-6 key processes. This often reveals systemic issues\u2014recurring problems aren't usually individual failures but process gaps.\n\n**SECTION 8: TEAM DYNAMICS & COLLABORATION**\n\nAssess human\/organizational factors:\n\n**Communication Effectiveness:**\n- What communication worked well? (Specific examples: daily standups, Slack channels, design docs)\n- What communication broke down? (Missed handoffs, unclear requirements, misaligned expectations)\n- Cross-functional collaboration: How well did different teams\/roles work together?\n- Information flow: Did right information reach right people at right time?\n\n**Decision-Making Dynamics:**\n- Who made key decisions? Was decision authority clear?\n- Were decisions made at appropriate level? (Too centralized? Too distributed?)\n- Did team feel empowered to raise concerns? Were dissenting opinions heard?\n- Any decisions that should have involved more stakeholders?\n\n**Team Morale & Psychological Safety:**\n- How did team morale evolve throughout project? (High start, declined later? Improved over time?)\n- Did people feel safe raising problems, admitting mistakes, challenging decisions?\n- Were there conflicts? How were they handled?\n- What energized the team? What drained them?\n\n**Resource & Workload Management:**\n- Was workload distributed fairly? Any burnout risk situations?\n- Did team have necessary skills\/time\/tools to succeed?\n- Were there gaps in team composition that hindered progress?\n\nThis 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.\n\n**SECTION 9: EXTERNAL FACTORS & DEPENDENCIES**\n\nIdentify factors outside team's control that impacted outcomes:\n\n**External Factor 1: <span class=\"placeholder\">[FACTOR_DESCRIPTION]<\/span>**\n- **Impact on Project:** How did this affect timeline\/scope\/quality\/outcomes?\n- **Predictability:** Was this foreseeable? (Known risk, should have anticipated, truly unforeseeable)\n- **Response:** How did team adapt? Was response adequate?\n- **Future Mitigation:** How can we reduce exposure to similar factors in future?\n\nExamples: Market shifts, competitor actions, vendor failures, regulatory changes, executive priority shifts, dependent team delays, infrastructure incidents.\n\nDistinguishing factors we could control from factors we couldn't is crucial for fair assessment and realistic future planning.\n\n**SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS**\n\nSynthesize analysis into concrete improvements:\n\n**Category: Technical\/Architecture**\n**Lesson 1:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n- **Evidence:** What happened that taught us this? (Reference specific sections above)\n- **Action Item:** Specific, measurable change to implement\n - **What:** <span class=\"placeholder\">[CONCRETE_ACTION]<\/span>\n - **Owner:** <span class=\"placeholder\">[RESPONSIBLE_PERSON]<\/span>\n - **Deadline:** <span class=\"placeholder\">[TARGET_DATE]<\/span>\n - **Success Metric:** How will we know this is working? <span class=\"placeholder\">[METRIC]<\/span>\n\n**Category: Process\/Workflow**\n**Lesson 2:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Team\/People**\n**Lesson 3:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Planning\/Estimation**\n**Lesson 4:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Communication\/Collaboration**\n**Lesson 5:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\nGenerate 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.\n\n**Action Item Priority Matrix:**\n| Priority | Impact | Effort | Action Items |\n|----------|--------|--------|--------------|\n| P0 | High | Low | <span class=\"placeholder\">[QUICK_WINS]<\/span> (Implement immediately) |\n| P1 | High | Medium | <span class=\"placeholder\">[IMPORTANT_WORK]<\/span> (Schedule in next quarter) |\n| P2 | Medium | Low | <span class=\"placeholder\">[NICE_TO_HAVES]<\/span> (Fit into roadmap) |\n| P3 | Low | High | <span class=\"placeholder\">[DEFER_OR_DROP]<\/span> (Revisit later if still relevant) |\n\n**SECTION 11: KNOWLEDGE TRANSFER & DOCUMENTATION**\n\nCapture institutional knowledge for future teams:\n\n**Technical Artifacts:**\n- Architecture diagrams and technical decisions\n- Performance data and optimization learnings\n- Security considerations and compliance notes\n- Deployment procedures and operational runbooks\n\n**Process Artifacts:**\n- Updated process documentation incorporating improvements\n- Templates\/checklists for future projects\n- Decision frameworks for similar situations\n\n**Tribal Knowledge Codification:**\n- \"Things we wish we knew at the start\"\n- Non-obvious gotchas and edge cases\n- Workarounds and their rationale (temporary vs. permanent)\n\n**Where to Store:** <span class=\"placeholder\">[KNOWLEDGE_BASE_LOCATION]<\/span> (Confluence, Notion, internal wiki, etc.)\n**Maintenance:** Who will keep this updated? <span class=\"placeholder\">[OWNER]<\/span>\n\n**SECTION 12: FORWARD-LOOKING RECOMMENDATIONS**\n\nApply learnings to upcoming work:\n\n**Similar Upcoming Projects:**\nList 2-3 upcoming initiatives that can benefit from these learnings.\n\n**Proactive Applications:**\nFor each upcoming project:\n- Which lessons from this post-mortem are most relevant?\n- What specific actions should we take at project kickoff to avoid repeating mistakes?\n- What success patterns should we deliberately replicate?\n\n**Organizational Changes:**\nAny broader changes needed beyond specific action items?\n- Training\/skill development needs\n- Tool\/technology investments\n- Team structure or staffing adjustments\n- Cultural\/behavioral shifts\n\n**OUTPUT REQUIREMENTS**\n- Balance honesty with psychological safety (identify problems without blaming people)\n- Provide specific, actionable recommendations (not vague \"improve X\")\n- Use quantitative evidence wherever possible (metrics, timelines, costs)\n- Celebrate successes alongside analyzing failures (positive reinforcement)\n- Focus on systemic root causes, not surface symptoms\n- Create forward-looking action plan with owners and deadlines\n- Make it skimmable for executives (clear summaries, visual elements)\n\n**DELIVERABLE FORMAT**\n- 12-20 page comprehensive post-mortem report\n- Executive summary (1-2 pages) suitable for leadership\n- Detailed analysis sections (8-12 pages)\n- Action item tracker with owners, deadlines, priorities (1-2 pages)\n- Appendix with supporting data, timelines, metrics (as needed)\n\n**FOLLOW-UP PROCESS**\n- Share draft with project participants for feedback before finalizing (ensures accuracy, builds trust)\n- Present findings in team retrospective meeting (discuss, clarify, build consensus)\n- Track action item completion in monthly follow-ups\n- Re-assess impact in 3-month and 6-month reviews (did changes work?)\n- Archive in searchable knowledge base for future reference<\/div>\n <div class=\"tip-box\">\n <div class=\"tip-title\">\ud83d\udca1 Pro Tip<\/div>\n <p>Replace all placeholders (highlighted in orange) with specific project details. The most valuable post-mortems are brutally honest yet blameless\u2014focus on systems and decisions, not individuals. Include concrete metrics showing expected vs. actual outcomes. The goal is organizational learning, not individual judgment.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">The Logic Behind This Prompt<\/h3>\n \n <div class=\"logic-principle\">\n <h3>1. Blameless Culture Framework (Psychological Safety First)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> The single biggest barrier to effective post-mortems is fear\u2014team 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\u2014not 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\u2014decisions still have consequences\u2014but 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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>2. 5 Whys Root Cause Analysis (Drill Beyond Surface Symptoms)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\" \u2192 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\u2014\"API went down during product launch causing 2-hour outage.\" Why 1\u2014\"Server ran out of memory.\" Why 2\u2014\"Traffic exceeded capacity by 5\u00d7.\" Why 3\u2014\"Load testing only simulated 1\u00d7 expected traffic, not realistic peak scenarios.\" Why 4\u2014\"Load testing requirements weren't clearly defined in launch checklist.\" Why 5 (Root Cause)\u2014\"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\u00d7 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\u2014it's external reality. \"We didn't build market sensing mechanisms to detect changes early\" is root cause. \"Engineer made mistake\" isn't root cause\u2014it'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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>3. Balanced Success-Failure Analysis (Celebrate What Worked)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\u2014they 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\u2014\"Real-time collaboration feature launched with zero critical bugs despite complex CRDT implementation.\" Why it worked\u2014\"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\u2014\"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\u2014even failed projects have partial wins\u2014you're not looking hard enough or team is too demoralized to see them.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>4. Decision Quality vs. Outcome Quality Separation (Hindsight Analysis)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\"\u2014if 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\"\u2014this 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\u00d72 matrix: Good Decision\/Good Outcome (right call that worked\u2014replicate decision process), Good Decision\/Bad Outcome (right call with bad luck\u2014would make same decision again, no process change needed), Bad Decision\/Good Outcome (wrong call that got lucky\u2014must correct process despite positive outcome to avoid future failures), Bad Decision\/Bad Outcome (wrong call that failed\u2014learn and change immediately). Example: Decision\u2014\"Chose MongoDB over PostgreSQL for flexibility despite team knowing PostgreSQL better.\" Outcome\u2014Project 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\u2014should 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\u2014\"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).<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>5. Actionable Recommendations with Owners, Deadlines, and Success Metrics<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\u2014only committed action with accountability does. This prompt mandates operationalizing every lesson into concrete action item with three components: (1) WHAT\u2014Specific, measurable change (not \"improve testing\" but \"add automated load testing stage to CI\/CD pipeline requiring 3\u00d7 traffic simulation before production deployment\"), (2) WHO\u2014Single owner accountable for completion (not \"engineering team\" but \"Sarah Chen, Senior DevOps Engineer\"), (3) WHEN\u2014Target 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\u2014these 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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>6. Forward-Looking Knowledge Transfer (Institutional Memory Capture)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> Post-mortems are often backward-looking\u2014\"what happened in past project\"\u2014without 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\u2014created once, never referenced again\u2014because 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.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Example Output Preview<\/h3>\n <div class=\"example-box\">\n <div class=\"example-title\">\ud83d\udcca Scenario: TaskFlow Mobile App Launch (Mixed Success)<\/div>\n \n <p><strong>Context:<\/strong> 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\u2605 rating vs. 4.5\u2605 target.<\/p>\n\n <p><strong>EXECUTIVE SUMMARY<\/strong><\/p>\n \n <p><strong>Project Overview:<\/strong> 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.<\/p>\n\n <p><strong>Outcome Summary:<\/strong> Partial success. Launched 5 weeks behind schedule (7 months vs. 6-month target), achieved 15K downloads (60% of 25K target), and 4.2\u2605 average rating (84% of 4.5\u2605 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.<\/p>\n\n <p><strong>Key Learnings (Top 5):<\/strong><\/p>\n <ol style=\"margin-left: 1.5rem; margin-top: 0.5rem;\">\n <li><strong>Cross-platform complexity underestimated by 70%:<\/strong> 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.<\/li>\n <li><strong>Performance testing only on new devices masked real-world issues:<\/strong> QA tested on iPhone 13 and Pixel 6. 30% of users have iPhone 8-11 and mid-range Android where performance was 2-3\u00d7 worse. Should have tested on 3-year-old device range.<\/li>\n <li><strong>Real-time sync architecture was our biggest technical win:<\/strong> 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.<\/li>\n <li><strong>Staggered launch (iOS first, Android 3 weeks later) created operational chaos:<\/strong> 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.<\/li>\n <li><strong>Lack of dedicated mobile PM was critical gap:<\/strong> 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.<\/li>\n <\/ol>\n\n <p><strong>Critical Action Items (Top 5):<\/strong><\/p>\n <ol style=\"margin-left: 1.5rem; margin-top: 0.5rem;\">\n <li><strong>P0: Create mobile performance testing standard:<\/strong> 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)<\/li>\n <li><strong>P0: Fix iOS performance regressions:<\/strong> Profile and optimize laggy animations, reduce main thread blocking, implement progressive loading. Target: 4.5\u2605+ rating within 8 weeks. (Owner: iOS team | Deadline: Jan 31, 2024)<\/li>\n <li><strong>P1: Hire dedicated Mobile Product Manager:<\/strong> 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)<\/li>\n <li><strong>P1: Establish cross-platform architecture patterns:<\/strong> 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)<\/li>\n <li><strong>P1: Standardize launch process for multi-platform releases:<\/strong> Create launch playbook defining simultaneous vs. staggered criteria, communication templates, support readiness checklists. (Owner: Julia Santos, Launch PM | Deadline: March 1, 2024)<\/li>\n <\/ol>\n\n <p><strong>Overall Assessment:<\/strong> 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\u2014zero 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\u2014damaged first impressions (4.2\u2605 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.\"<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS<\/strong><\/p>\n\n <p><strong>Objective 1: Launch mobile apps (iOS + Android) by Q2 end<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> June 30, 2023 (6 months from kickoff)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> August 8, 2023 (iOS: July 18, Android: August 8) \u2014 5.5 weeks late<\/li>\n <li>\u2022 <strong>Variance:<\/strong> +23% timeline overrun<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u26a0\ufe0f Partially Met (delivered but late)<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> 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).<\/li>\n <\/ul>\n\n <p><strong>Objective 2: Achieve 25,000 downloads in first quarter post-launch<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 25,000 downloads by November 8, 2023 (3 months post-launch)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 15,200 downloads by November 8, 2023<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -39% vs. target (60.8% achievement)<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u274c Not Met<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Download shortfall driven by: (1) Late launch reduced available user acquisition time (5 weeks less runway), (2) 4.2\u2605 initial rating discouraged downloads\u2014app store conversion rate 2.8% vs. industry benchmark 5% for 4.5\u2605+ 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\u2605 rating, estimated downloads would be 22K-24K (closer to target). The 4.2\u2605 rating was self-inflicted wound from performance testing gaps.<\/li>\n <\/ul>\n\n <p><strong>Objective 3: Maintain 4.5+ star average rating on both app stores<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 4.5\u2605+ average (iOS App Store + Google Play)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 4.2\u2605 average (iOS: 4.3\u2605 based on 847 reviews, Android: 4.1\u2605 based on 623 reviews)<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -0.3 stars (-6.7%)<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u274c Not Met<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Rating driven down by two primary complaint categories: (1) Performance issues (38% of 1-3\u2605 reviews mentioned \"slow,\" \"laggy,\" \"freezing\")\u2014concentrated on iOS 12-14 devices and mid-range Android, (2) Android-specific crashes on Samsung devices (22% of Android negative reviews mentioned crashes)\u2014traced to incompatibility with Samsung's custom Android UI layer that wasn't caught in testing (we tested on Pixel only). The 4.2\u2605 rating is recoverable\u2014post-launch hotfixes addressed major performance issues and ratings have trended up (Week 1: 3.9\u2605 \u2192 Week 8: 4.2\u2605 \u2192 Current trajectory suggests 4.4\u2605 by Month 4 if improvements continue). However, initial negative reviews are permanent and affect discoverability (app stores algorithmically demote apps with <4.3\u2605 ratings in search results).<\/li>\n <\/ul>\n\n <p><strong>Objective 4: Achieve feature parity with web app for core workflows<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 100% of \"core workflows\" (task creation, assignment, comments, file attachments, notifications, real-time collaboration) working on mobile<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 90% feature parity achieved; missing: bulk task operations, advanced filtering, custom fields (deferred to v1.1)<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -10% features<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u2705 Met (90% considered sufficient for core workflows; deferred features are \"advanced\" not \"core\")<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Successfully delivered all core task management, collaboration, and notification features with mobile-appropriate UX. Real-time sync exceeded expectations\u2014changes 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.<\/li>\n <\/ul>\n\n <p><strong>Overall Success Rate: 1.5 of 4 objectives fully met (37.5% success rate)<\/strong><\/p>\n <p>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).<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 5: WHAT WENT WRONG (Challenges & Failures)<\/strong><\/p>\n\n <p><strong>Challenge 1: iOS Performance Degradation on Older Devices<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Impact:<\/strong> 38% of negative reviews cited performance issues. Delayed launch by 2 weeks for optimization sprint. Damaged brand perception (\"TaskFlow mobile is slow\").<\/li>\n <li>\u2022 <strong>Quantified Cost:<\/strong> 2-week timeline delay, estimated 2,000-3,000 lost downloads due to negative reviews, ~$40K MRR impact.<\/li>\n <\/ul>\n\n <p><strong>5 Whys Root Cause Analysis:<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Problem:<\/strong> iOS app experienced laggy animations and 1-2 second delays on iPhone 8-11 devices (representing 30% of user base).<\/li>\n <li>\u2022 <strong>Why 1:<\/strong> UI rendering blocked main thread, causing dropped frames (measured: 20-30 fps instead of 60 fps target).<\/li>\n <li>\u2022 <strong>Why 2:<\/strong> Heavy JSON parsing and image processing executed synchronously on main thread instead of background threads.<\/li>\n <li>\u2022 <strong>Why 3:<\/strong> Developers optimized for newest devices (iPhone 13) where synchronous operations were \"fast enough\" and didn't notice blocking.<\/li>\n <li>\u2022 <strong>Why 4:<\/strong> QA testing exclusively used iPhone 13 and 14 devices; no testing on 3-year-old hardware representing significant user base.<\/li>\n <li>\u2022 <strong>Why 5 (Root Cause):<\/strong> 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).<\/li>\n <\/ul>\n\n <p><strong>Contributing Factors:<\/strong> (1) iOS team lacked senior engineer with performance optimization expertise\u2014would have caught main thread blocking in code review. (2) Xcode Instruments profiling not part of standard development workflow\u2014performance issues weren't visible until beta. (3) Beta testing recruited from internal employees who predominantly had newer devices.<\/p>\n\n <p><strong>Warning Signs We Missed:<\/strong> 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.<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 6: DECISION ANALYSIS<\/strong><\/p>\n\n <p><strong>Decision 1: Build Native Apps (iOS\/Android) vs. Cross-Platform Framework (React Native\/Flutter)<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Context:<\/strong> Month 0, choosing mobile development approach. Options: Native (separate iOS Swift + Android Kotlin codebases), React Native, Flutter.<\/li>\n <li>\u2022 <strong>Choice Made:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Outcome:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Hindsight Assessment:<\/strong> \u2705 <strong>Good Decision, Mixed Outcome.<\/strong> 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.<\/li>\n <li>\u2022 <strong>Lesson:<\/strong> 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%).<\/li>\n <\/ul>\n\n <p><strong>Decision 2: Staggered Launch (iOS First, Android 3 Weeks Later)<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Context:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Choice Made:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Outcome:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Hindsight Assessment:<\/strong> \u274c <strong>Bad Decision, Bad Outcome.<\/strong> 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.<\/li>\n <li>\u2022 <strong>Lesson:<\/strong> 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.<\/li>\n <\/ul>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS<\/strong><\/p>\n\n <p><strong>Category: Technical\/Architecture<\/strong><\/p>\n <p><strong>Lesson 1:<\/strong> Offline-first architecture with robust conflict resolution is critical success factor for mobile apps with real-time collaboration requirements.<\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Evidence:<\/strong> 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\").<\/li>\n <li>\u2022 <strong>Action Item:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Owner:<\/strong> Michael Torres, Senior Mobile Architect<\/li>\n <li>\u2022 <strong>Deadline:<\/strong> February 15, 2024<\/li>\n <li>\u2022 <strong>Success Metric:<\/strong> 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.<\/li>\n <\/ul>\n\n <p><strong>Category: Process\/Workflow<\/strong><\/p>\n <p><strong>Lesson 2:<\/strong> Mobile testing must mandate device range spanning 3-year-old hardware, not just newest flagships, to catch performance regressions affecting significant user segments.<\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Evidence:<\/strong> 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\u00d7 worse. Cost: 2-week delay for optimization, damaged ratings, lost downloads.<\/li>\n <li>\u2022 <strong>Action Item:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Owner:<\/strong> Lisa Patel, Mobile QA Lead<\/li>\n <li>\u2022 <strong>Deadline:<\/strong> January 31, 2024<\/li>\n <li>\u2022 <strong>Success Metric:<\/strong> 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%).<\/li>\n <\/ul>\n\n <p style=\"margin-top: 1rem;\"><em>[Additional lessons 3-10 following same structure, covering team composition gaps, launch process improvements, estimation calibration, cross-platform coordination, etc.]<\/em><\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Prompt Chain Strategy<\/h3>\n <p style=\"margin-bottom: 1.5rem;\">For optimal results, break the post-mortem analysis into three sequential prompts that build comprehensive organizational learning:<\/p>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 1: Data Collection & Timeline Reconstruction (Foundation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Gather factual information about what happened without interpretation or judgment.<\/p>\n <div class=\"prompt-box\">You are facilitating a blameless post-mortem. Help me collect objective data about this project:\n\n**Project:** <span class=\"placeholder\">[PROJECT_NAME]<\/span>\n**Timeline:** <span class=\"placeholder\">[START_DATE]<\/span> to <span class=\"placeholder\">[END_DATE]<\/span>\n**Team:** <span class=\"placeholder\">[TEAM_DETAILS]<\/span>\n**Outcome:** <span class=\"placeholder\">[SUCCESS_OR_FAILURE_DESCRIPTION]<\/span>\n\n**Task 1: Objectives & Metrics Documentation**\nList all original project objectives with measurable success criteria:\n- Objective 1: <span class=\"placeholder\">[GOAL]<\/span> | Target: <span class=\"placeholder\">[METRIC]<\/span>\n- Objective 2: <span class=\"placeholder\">[GOAL]<\/span> | Target: <span class=\"placeholder\">[METRIC]<\/span>\n... (continue for all objectives)\n\nThen document actual outcomes:\n- Outcome 1: <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> | Variance: <span class=\"placeholder\">[DELTA_VS_TARGET]<\/span>\n- Outcome 2: <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> | Variance: <span class=\"placeholder\">[DELTA_VS_TARGET]<\/span>\n\n**Task 2: Chronological Timeline Construction**\nBuild month-by-month (or week-by-week for shorter projects) timeline:\n\n**Month 1:** <span class=\"placeholder\">[ACTIVITIES_AND_DECISIONS]<\/span>\n**Month 2:** <span class=\"placeholder\">[ACTIVITIES_AND_DECISIONS]<\/span>\n... (continue through project lifecycle)\n\nFor each period, note:\n- Major milestones achieved or missed\n- Key decisions made and rationale at the time\n- Unexpected challenges that emerged\n- Pivot points or course corrections\n\n**Task 3: Stakeholder Perspective Gathering**\nCollect input from different roles (maintain blameless tone):\n- Engineering perspective: Technical challenges? Surprises? What worked\/didn't work?\n- Product perspective: Requirement clarity? Scope changes? User feedback?\n- Design perspective: UX decisions? Usability findings? Design debt?\n- QA perspective: Testing coverage? Bugs found\/missed? Quality concerns?\n- Operations\/Support perspective: Deployment issues? User complaints? Operational burden?\n\n**Task 4: Quantitative Data Compilation**\nGather all available metrics:\n- Timeline data (planned vs. actual durations)\n- Budget data (estimated vs. actual costs)\n- Quality metrics (bugs found, incidents, performance measurements)\n- User metrics (adoption, satisfaction, ratings, feedback)\n- Team metrics (velocity, morale, turnover if relevant)\n\nOutput a comprehensive data package with objective facts, timelines, metrics, and multi-perspective input.<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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.\n <\/div>\n <\/div>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 2: Root Cause Analysis & Pattern Identification (Investigation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Analyze data to identify systemic root causes of successes and failures.<\/p>\n <div class=\"prompt-box\">Using the data collected in Step 1, conduct deep root cause analysis:\n\n**SUCCESSES ANALYSIS**\nFor each positive outcome or objective exceeded:\n\n**Success:** <span class=\"placeholder\">[WHAT_WENT_WELL]<\/span>\nApply \"5 Whys\" to understand success:\n- Why did this succeed? <span class=\"placeholder\">[REASON_1]<\/span>\n- Why did [REASON_1] happen? <span class=\"placeholder\">[REASON_2]<\/span>\n- Why did [REASON_2] happen? <span class=\"placeholder\">[REASON_3]<\/span>\n- Continue until reaching systemic enabler (process, decision, resource, culture)\n\n**Replicability:** How can we systematize this success? What made it possible that we can apply to future projects?\n\n**FAILURES ANALYSIS**\nFor each negative outcome, missed objective, or significant challenge:\n\n**Challenge:** <span class=\"placeholder\">[WHAT_WENT_WRONG]<\/span>\nApply \"5 Whys\" root cause analysis:\n- Problem: <span class=\"placeholder\">[SURFACE_PROBLEM]<\/span>\n- Why 1: <span class=\"placeholder\">[IMMEDIATE_CAUSE]<\/span>\n- Why 2: <span class=\"placeholder\">[DEEPER_CAUSE]<\/span>\n- Why 3: <span class=\"placeholder\">[SYSTEM_CAUSE]<\/span>\n- Why 4: <span class=\"placeholder\">[PROCESS_GAP]<\/span>\n- Why 5 (Root Cause): <span class=\"placeholder\">[SYSTEMIC_ROOT_CAUSE]<\/span>\n\n**Contributing Factors:** What other conditions made this problem worse or more likely?\n**Warning Signs:** Were there early indicators we missed?\n**Systemic vs. Isolated:** Is this one-time issue or symptom of broader process gap?\n\n**DECISION RETROSPECTIVE**\nFor 5-8 major decisions, assess using Decision Quality vs. Outcome Quality framework:\n\n**Decision:** <span class=\"placeholder\">[DECISION_MADE]<\/span>\n- **Information at decision time:** What did we know? What were the options?\n- **Rationale:** Why did we choose this path?\n- **Outcome:** What happened? Expected vs. actual impact.\n- **Quality Assessment:** \n - \u2705 Good Decision\/Good Outcome \u2192 Replicate decision process\n - \u26a0\ufe0f Good Decision\/Bad Outcome \u2192 Accept; would decide same way again\n - \u26a0\ufe0f Bad Decision\/Good Outcome \u2192 Lucky; fix decision process despite positive outcome\n - \u274c Bad Decision\/Bad Outcome \u2192 Learn and change immediately\n- **Lesson:** What does this teach us about decision-making?\n\n**PATTERN IDENTIFICATION**\nLook for recurring themes across successes and failures:\n- What patterns emerge? (e.g., \"Every timeline delay traced to underestimated integration complexity\")\n- What systemic gaps enable problems? (e.g., \"No process enforces cross-functional review before commitment\")\n- What cultural\/behavioral patterns drive outcomes? (e.g., \"Team afraid to escalate bad news early\")\n\nOutput comprehensive root cause analysis with 8-15 systemic findings (not surface symptoms).<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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\u2014iOS\/Android, Engineering\/Product, Dev\/QA\"). This analysis transforms raw data into insights ready for action planning.\n <\/div>\n <\/div>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 3: Actionable Recommendations & Forward Planning (Implementation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Convert insights into concrete action plan with accountability and forward application.<\/p>\n <div class=\"prompt-box\">Based on root cause analysis from Step 2, create actionable improvement plan:\n\n**SECTION 1: Lessons Learned Catalog**\nFor each root cause identified in Step 2, formulate lesson learned:\n\n**Lesson:** <span class=\"placeholder\">[CLEAR_LESSON_STATEMENT]<\/span>\n- **Category:** Technical \/ Process \/ Team \/ Planning \/ Communication\n- **Evidence:** What happened that taught us this? (Reference specific events from timeline)\n- **Impact:** How significant is this lesson? (High\/Medium\/Low based on cost of problem or value of success)\n\nGenerate 15-20 lessons covering successes to replicate and failures to prevent.\n\n**SECTION 2: Action Item Development**\nFor each high and medium impact lesson, create specific action item:\n\n**Action Item:** <span class=\"placeholder\">[CONCRETE_CHANGE_TO_IMPLEMENT]<\/span>\n- **What:** Specific, measurable change (not vague \"improve X\")\n - Bad: \"Improve testing\" \n - Good: \"Add automated performance testing stage to CI requiring 60fps on iPhone X simulator before production\"\n- **Why:** Which lesson does this address? What problem does it prevent\/success does it replicate?\n- **Who:** Single owner accountable for implementation (Name, Role)\n- **When:** Target deadline (specific date)\n- **How:** Implementation approach (2-3 sentences on execution plan)\n- **Success Metric:** How will we measure effectiveness? (Quantitative if possible)\n\n**SECTION 3: Prioritization Matrix**\nClassify all action items by Impact (High\/Medium\/Low) and Effort (Low\/Medium\/High):\n\n**P0 (High Impact, Low Effort):** <span class=\"placeholder\">[QUICK_WINS]<\/span> \u2192 Implement immediately\n**P1 (High Impact, Medium Effort):** <span class=\"placeholder\">[IMPORTANT_WORK]<\/span> \u2192 Schedule next quarter\n**P2 (Medium Impact, Low-Medium Effort):** <span class=\"placeholder\">[NICE_TO_HAVES]<\/span> \u2192 Backlog\n**P3 (Low Impact or High Effort):** <span class=\"placeholder\">[DEFER]<\/span> \u2192 Revisit later if circumstances change\n\nFocus implementation bandwidth on P0 and P1 items.\n\n**SECTION 4: Forward Application**\nIdentify 2-3 upcoming projects that can benefit from these learnings:\n\n**Upcoming Project:** <span class=\"placeholder\">[PROJECT_NAME]<\/span>\n**Relevant Lessons:** Which 5-7 lessons from this post-mortem apply to upcoming project?\n**Proactive Actions:** What should we do at kickoff of upcoming project to apply lessons?\n- Avoid repeating mistakes: <span class=\"placeholder\">[PREVENTIVE_ACTIONS]<\/span>\n- Replicate success patterns: <span class=\"placeholder\">[REPLICATION_ACTIONS]<\/span>\n\n**SECTION 5: Follow-Up Framework**\nEstablish accountability and tracking:\n- **Monthly Review:** Track action item completion, update status, unblock impediments\n- **Quarterly Retrospective:** Assess impact\u2014did changes have intended effect? Any course corrections needed?\n- **Knowledge Base Integration:** Where\/how will these learnings be documented for future team access?\n- **Communication Plan:** How will findings be shared with broader organization?\n\nOutput comprehensive action plan (10-15 pages) with prioritized action items, owners, deadlines, success metrics, and forward application strategy.<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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.\n <\/div>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Human-in-the-Loop Refinements<\/h3>\n \n <div class=\"hitl-tip\">\n <h3>1. Conduct Post-Mortem Meeting to Validate AI-Generated Analysis<\/h3>\n <p><strong>Challenge:<\/strong> 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\u2014interpersonal dynamics, unspoken assumptions, \"soft\" factors like morale or psychological safety that don't show up in metrics.<\/p>\n <p><strong>Refinement:<\/strong> 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>2. Verify Root Causes Through \"5 Whys\" Exercise with Cross-Functional Participants<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014process, 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\u2014root 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>3. Pressure-Test Action Items with \"Pre-Mortem on the Action Plan\"<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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 \u2192 Allocate explicit 20% of next sprint to post-mortem actions. Enforcement issue \u2192 Make new process mandatory part of launch checklist with sign-off. Shallow analysis \u2192 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%.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>4. Conduct \"Counterfactual Analysis\" to Test Lesson Robustness<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014\"CRDT architecture ensures sync reliability.\" Refined lesson\u2014\"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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>5. Establish Action Item Accountability Through Monthly Tracking Ritual<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014Slack announcements, team meeting shout-outs\u2014to 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>6. Build Searchable Post-Mortem Library with Tagging and Cross-Referencing<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> Systematically build searchable post-mortem library: (1) Create centralized post-mortem repository (Confluence space, Notion database, internal wiki section) with consistent structure\u2014every 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]\u2014see 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.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"footer-stats\">\n <div class=\"stat\">\n <div class=\"stat-value\">5.0\/5.0<\/div>\n <div class=\"stat-label\">Average Rating<\/div>\n <\/div>\n <div class=\"stat\">\n <div class=\"stat-value\">15,428<\/div>\n <div class=\"stat-label\">Times Copied<\/div>\n <\/div>\n <div class=\"stat\">\n <div class=\"stat-value\">1,203<\/div>\n <div class=\"stat-label\">User Reviews<\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n\n <script>\n function copyPrompt() {\n const promptText = document.getElementById('promptText').innerText;\n navigator.clipboard.writeText(promptText).then(() => {\n const button = document.querySelector('.copy-button');\n const originalText = button.innerHTML;\n button.innerHTML = '\u2705 Copied!';\n setTimeout(() => {\n button.innerHTML = originalText;\n }, 2000);\n }).catch(err => {\n console.error('Failed to copy text: ', err);\n alert('Failed to copy prompt. Please try selecting and copying manually.');\n });\n }\n <\/script>\n<\/body>\n<\/html>\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"<p>Post-Mortem Analysis – AiPro Institute\u2122 Prompt Library AiPro Institute\u2122 Prompt Library Post-Mortem Analysis \ud83d\udee0\ufe0f Product & Operations \u23f1\ufe0f 35\u201345 minutes \ud83d\udcca Intermediate to Advanced ChatGPT Claude Gemini Perplexity Grok The Prompt \ud83d\udccb Copy Prompt You are an expert organizational learning facilitator specializing in blameless post-mortem analysis, root cause investigation, and continuous improvement systems. Your role…<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[187],"tags":[],"class_list":["post-4949","post","type-post","status-publish","format-standard","hentry","category-product-operations"],"acf":[],"_links":{"self":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/comments?post=4949"}],"version-history":[{"count":4,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949\/revisions"}],"predecessor-version":[{"id":5019,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949\/revisions\/5019"}],"wp:attachment":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/media?parent=4949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/categories?post=4949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/tags?post=4949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\n\t\t\t\t\t\t

\n\t\t\t\t\t

\n\t\t\t

\n\t\t\t\t\t\t

\n\t\t\t\t\t\n\n\n \n \n Post-Mortem Analysis - AiPro Institute\u2122 Prompt Library<\/title>\n <style>\n * {\n margin: 0;\n padding: 0;\n box-sizing: border-box;\n }\n\n body {\n font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, sans-serif;\n line-height: 1.6;\n color: #333;\n background: #ffffff;\n padding: 2rem 1rem;\n }\n\n .page-title {\n text-align: center;\n font-size: 2.5rem;\n font-weight: 700;\n margin-bottom: 3rem;\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n -webkit-background-clip: text;\n -webkit-text-fill-color: transparent;\n background-clip: text;\n }\n\n .container {\n max-width: 900px;\n margin: 0 auto;\n }\n\n .card {\n background: white;\n border-radius: 12px;\n box-shadow: 0 4px 6px rgba(0, 0, 0, 0.07);\n overflow: hidden;\n margin-bottom: 2rem;\n }\n\n .card-header {\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n color: white;\n padding: 2rem;\n }\n\n .card-title {\n font-size: 2rem;\n font-weight: 700;\n margin-bottom: 1rem;\n }\n\n .meta-badges {\n display: flex;\n flex-wrap: wrap;\n gap: 0.5rem;\n margin-bottom: 1rem;\n }\n\n .badge {\n background: rgba(255, 255, 255, 0.2);\n padding: 0.4rem 0.8rem;\n border-radius: 6px;\n font-size: 0.85rem;\n font-weight: 500;\n }\n\n .tool-badges {\n display: flex;\n flex-wrap: wrap;\n gap: 0.5rem;\n }\n\n .tool-badge {\n border: 1px solid rgba(255, 255, 255, 0.3);\n padding: 0.3rem 0.7rem;\n border-radius: 6px;\n font-size: 0.8rem;\n }\n\n .card-body {\n padding: 2.5rem;\n }\n\n .section {\n margin-bottom: 2.5rem;\n }\n\n .section-title-container {\n display: flex;\n justify-content: space-between;\n align-items: center;\n margin-bottom: 1rem;\n }\n\n .section-title {\n font-size: 1.5rem;\n font-weight: 700;\n color: #667eea;\n border-left: 4px solid #667eea;\n padding-left: 1rem;\n }\n\n .copy-button {\n background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);\n color: white;\n border: none;\n padding: 0.6rem 1.2rem;\n border-radius: 6px;\n cursor: pointer;\n font-size: 0.9rem;\n font-weight: 600;\n transition: transform 0.2s, box-shadow 0.2s;\n }\n\n .copy-button:hover {\n transform: translateY(-2px);\n box-shadow: 0 4px 12px rgba(102, 126, 234, 0.4);\n }\n\n .copy-button:active {\n transform: translateY(0);\n }\n\n .prompt-box {\n background: #f8f9fa;\n border: 1px solid #e0e0e0;\n border-radius: 8px;\n padding: 1.5rem;\n margin-bottom: 1rem;\n font-family: 'Courier New', monospace;\n font-size: 0.95rem;\n line-height: 1.8;\n white-space: pre-wrap;\n word-wrap: break-word;\n }\n\n .placeholder {\n color: #fd7e14;\n font-weight: 600;\n }\n\n .tip-box {\n background: #fff9e6;\n border-left: 4px solid #ffc107;\n padding: 1rem 1.5rem;\n border-radius: 4px;\n margin-top: 1rem;\n }\n\n .tip-title {\n font-weight: 700;\n color: #f57c00;\n margin-bottom: 0.5rem;\n }\n\n .logic-principle {\n margin-bottom: 2rem;\n }\n\n .logic-principle h3 {\n color: #667eea;\n font-size: 1.2rem;\n margin-bottom: 0.5rem;\n }\n\n .logic-principle p {\n color: #555;\n line-height: 1.8;\n }\n\n .example-box {\n border: 2px solid #2196F3;\n border-radius: 8px;\n padding: 1.5rem;\n background: #f0f8ff;\n margin-top: 1rem;\n }\n\n .example-title {\n font-weight: 700;\n color: #1976D2;\n margin-bottom: 1rem;\n font-size: 1.1rem;\n }\n\n .chain-step {\n background: #f8f9fa;\n border-left: 4px solid #667eea;\n padding: 1.5rem;\n margin-bottom: 1.5rem;\n border-radius: 4px;\n }\n\n .chain-step h3 {\n color: #667eea;\n margin-bottom: 1rem;\n }\n\n .expected-output {\n background: white;\n border: 1px solid #e0e0e0;\n padding: 1rem;\n border-radius: 6px;\n margin-top: 1rem;\n font-size: 0.9rem;\n }\n\n .hitl-tip {\n margin-bottom: 1.5rem;\n }\n\n .hitl-tip h3 {\n color: #667eea;\n font-size: 1.1rem;\n margin-bottom: 0.5rem;\n }\n\n .footer-stats {\n display: flex;\n justify-content: space-around;\n padding: 2rem;\n background: #f8f9fa;\n border-radius: 8px;\n margin-top: 2rem;\n }\n\n .stat {\n text-align: center;\n }\n\n .stat-value {\n font-size: 2rem;\n font-weight: 700;\n color: #667eea;\n }\n\n .stat-label {\n color: #666;\n font-size: 0.9rem;\n margin-top: 0.25rem;\n }\n\n @media (max-width: 768px) {\n body {\n padding: 1rem 0.5rem;\n }\n\n .page-title {\n font-size: 1.8rem;\n margin-bottom: 2rem;\n }\n\n .card-header {\n padding: 1.5rem;\n }\n\n .card-title {\n font-size: 1.5rem;\n }\n\n .card-body {\n padding: 1.5rem;\n }\n\n .section-title-container {\n flex-direction: column;\n align-items: flex-start;\n gap: 1rem;\n }\n\n .copy-button {\n width: 100%;\n }\n\n .footer-stats {\n flex-direction: column;\n gap: 1.5rem;\n }\n }\n <\/style>\n<\/head>\n<body>\n <h1 class=\"page-title\">AiPro Institute\u2122 Prompt Library<\/h1>\n \n <div class=\"container\">\n <div class=\"card\">\n <div class=\"card-header\">\n <h2 class=\"card-title\">Post-Mortem Analysis<\/h2>\n <div class=\"meta-badges\">\n <span class=\"badge\">\ud83d\udee0\ufe0f Product & Operations<\/span>\n <span class=\"badge\">\u23f1\ufe0f 35\u201345 minutes<\/span>\n <span class=\"badge\">\ud83d\udcca Intermediate to Advanced<\/span>\n <\/div>\n <div class=\"tool-badges\">\n <span class=\"tool-badge\">ChatGPT<\/span>\n <span class=\"tool-badge\">Claude<\/span>\n <span class=\"tool-badge\">Gemini<\/span>\n <span class=\"tool-badge\">Perplexity<\/span>\n <span class=\"tool-badge\">Grok<\/span>\n <\/div>\n <\/div>\n\n <div class=\"card-body\">\n \n <div class=\"section\">\n <div class=\"section-title-container\">\n <h3 class=\"section-title\">The Prompt<\/h3>\n <button class=\"copy-button\" onclick=\"copyPrompt()\">\ud83d\udccb Copy Prompt<\/button>\n <\/div>\n <div class=\"prompt-box\" id=\"promptText\">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\u2014whether they succeeded spectacularly, failed catastrophically, or fell somewhere in between.\n\n**CRITICAL PRINCIPLE: BLAMELESS CULTURE**\nThis post-mortem focuses on systems, processes, and decisions\u2014NOT 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.\"\n\n**CONTEXT**\nProject\/Initiative Name: <span class=\"placeholder\">[PROJECT_NAME]<\/span>\nType: <span class=\"placeholder\">[PROJECT_TYPE]<\/span> (Product launch, feature release, system migration, incident response, failed initiative, etc.)\nTimeline: <span class=\"placeholder\">[START_DATE]<\/span> to <span class=\"placeholder\">[END_DATE]<\/span> (Duration: <span class=\"placeholder\">[X]<\/span> weeks\/months)\nTeam: <span class=\"placeholder\">[TEAM_COMPOSITION]<\/span> (Size, roles, structure)\nOutcome Classification: <span class=\"placeholder\">[SUCCESS \/ PARTIAL_SUCCESS \/ MIXED \/ FAILURE]<\/span>\n\n**ORIGINAL OBJECTIVES**\nWhat were the stated goals and success criteria?\n<span class=\"placeholder\">[OBJECTIVE_1]<\/span>\n<span class=\"placeholder\">[OBJECTIVE_2]<\/span>\n<span class=\"placeholder\">[OBJECTIVE_3]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_OBJECTIVES]<\/span>\n\n**ACTUAL OUTCOMES**\nWhat actually happened? (Be specific with metrics)\n<span class=\"placeholder\">[OUTCOME_1]<\/span>\n<span class=\"placeholder\">[OUTCOME_2]<\/span>\n<span class=\"placeholder\">[OUTCOME_3]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_OUTCOMES]<\/span>\n\n**POST-MORTEM ANALYSIS FRAMEWORK**\n\n**SECTION 1: EXECUTIVE SUMMARY**\nProvide concise overview for stakeholders who won't read full report:\n\n**Project Overview:** 2-3 sentence description of what was attempted and why\n\n**Outcome Summary:** Did we achieve objectives? What were the results? (Include key metrics: Expected vs. Actual)\n\n**Key Learnings (Top 3-5):**\n1. <span class=\"placeholder\">[MOST_IMPORTANT_LESSON]<\/span>\n2. <span class=\"placeholder\">[SECOND_LESSON]<\/span>\n3. <span class=\"placeholder\">[THIRD_LESSON]<\/span>\n... <span class=\"placeholder\">[ADDITIONAL_LESSONS]<\/span>\n\n**Critical Action Items (Top 3-5):**\n1. <span class=\"placeholder\">[HIGHEST_PRIORITY_ACTION]<\/span> (Owner: <span class=\"placeholder\">[PERSON]<\/span>, Deadline: <span class=\"placeholder\">[DATE]<\/span>)\n2. <span class=\"placeholder\">[SECOND_ACTION]<\/span> (Owner: <span class=\"placeholder\">[PERSON]<\/span>, Deadline: <span class=\"placeholder\">[DATE]<\/span>)\n... <span class=\"placeholder\">[ADDITIONAL_ACTIONS]<\/span>\n\n**Overall Assessment:** 1-paragraph synthesis: What went well, what went wrong, what's the single biggest takeaway?\n\n**SECTION 2: TIMELINE OF EVENTS**\n\nCreate detailed chronological narrative of project lifecycle:\n\n**Phase 1: Planning & Kickoff (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Key decisions made: <span class=\"placeholder\">[DECISIONS]<\/span>\n- Assumptions established: <span class=\"placeholder\">[ASSUMPTIONS]<\/span>\n- Resources allocated: <span class=\"placeholder\">[RESOURCES]<\/span>\n- Early warning signs (if any): <span class=\"placeholder\">[WARNING_SIGNS]<\/span>\n\n**Phase 2: Execution (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Major milestones achieved or missed: <span class=\"placeholder\">[MILESTONES]<\/span>\n- Unexpected challenges encountered: <span class=\"placeholder\">[CHALLENGES]<\/span>\n- Adaptation\/pivot decisions: <span class=\"placeholder\">[PIVOTS]<\/span>\n- Critical incidents: <span class=\"placeholder\">[INCIDENTS]<\/span>\n\n**Phase 3: Launch\/Completion (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Go-live events: <span class=\"placeholder\">[EVENTS]<\/span>\n- Initial results\/reactions: <span class=\"placeholder\">[REACTIONS]<\/span>\n- Emergency responses (if any): <span class=\"placeholder\">[RESPONSES]<\/span>\n\n**Phase 4: Post-Launch (<span class=\"placeholder\">[DATE_RANGE]<\/span>)**\n- Performance vs. expectations: <span class=\"placeholder\">[PERFORMANCE]<\/span>\n- User feedback and data: <span class=\"placeholder\">[FEEDBACK]<\/span>\n- Adjustments made: <span class=\"placeholder\">[ADJUSTMENTS]<\/span>\n\nFor each phase, include: What was planned? What actually happened? Where did reality diverge from plan?\n\n**SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS**\n\nFor each original objective, analyze performance:\n\n**Objective 1: <span class=\"placeholder\">[OBJECTIVE_NAME]<\/span>**\n- **Target:** <span class=\"placeholder\">[QUANTITATIVE_TARGET]<\/span> (e.g., \"Launch by Q2, achieve 10K users in first month, maintain 99% uptime\")\n- **Actual Result:** <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> (e.g., \"Launched 6 weeks late (Q3), achieved 6.8K users, 97.2% uptime\")\n- **Variance:** <span class=\"placeholder\">[PERCENTAGE_OR_DELTA]<\/span> (e.g., \"-32% on user acquisition, -1.8% on uptime\")\n- **Achievement Status:** \u2705 Exceeded \/ \u2705 Met \/ \u26a0\ufe0f Partially Met \/ \u274c Not Met\n- **Analysis:** Why did we over\/under-perform? What factors drove the variance?\n\nRepeat for all objectives (typically 3-8 objectives per project).\n\n**Overall Success Rate:** X of Y objectives fully met (Z% success rate)\n\n**SECTION 4: WHAT WENT WELL (Successes & Strengths)**\n\nDocument practices, decisions, and team behaviors that should be replicated:\n\n**Success 1: <span class=\"placeholder\">[SUCCESS_DESCRIPTION]<\/span>**\n- **What happened:** Specific description with evidence\/metrics\n- **Why it worked:** Root cause of success\u2014what conditions, decisions, or behaviors enabled this?\n- **Replicability:** Can we systematize this success? How do we ensure it happens again?\n- **Key Contributors:** Teams\/individuals whose actions drove this (celebrating, not singling out)\n\n**Success 2: <span class=\"placeholder\">[SUCCESS_DESCRIPTION]<\/span>**\n[Same structure]\n\nIdentify 5-10 significant successes. These are often overlooked in post-mortems but are critical for positive reinforcement and best practice capture.\n\n**Common categories to explore:**\n- Technical achievements (performance, reliability, scalability beyond expectations)\n- Process innovations (new workflow that accelerated delivery)\n- Team collaboration breakthroughs (cross-functional coordination that worked exceptionally)\n- Risk management wins (anticipated problems that were successfully mitigated)\n- Customer\/user wins (features that delighted users beyond expectations)\n\n**SECTION 5: WHAT WENT WRONG (Challenges & Failures)**\n\nConduct root cause analysis using \"5 Whys\" methodology:\n\n**Challenge 1: <span class=\"placeholder\">[PROBLEM_DESCRIPTION]<\/span>**\n- **Impact:** How did this affect the project? (Timeline delay? Budget overrun? Quality issues? Team morale?)\n- **Quantified Cost:** X weeks delay, $Y budget impact, Z% performance degradation, etc.\n- **5 Whys Root Cause Analysis:**\n - **Problem:** <span class=\"placeholder\">[SURFACE_PROBLEM]<\/span> (e.g., \"Database crashed during peak load\")\n - **Why 1:** <span class=\"placeholder\">[FIRST_WHY]<\/span> (e.g., \"Query load exceeded connection pool capacity\")\n - **Why 2:** <span class=\"placeholder\">[SECOND_WHY]<\/span> (e.g., \"We didn't load test at realistic traffic volumes\")\n - **Why 3:** <span class=\"placeholder\">[THIRD_WHY]<\/span> (e.g., \"Load testing was deprioritized due to timeline pressure\")\n - **Why 4:** <span class=\"placeholder\">[FOURTH_WHY]<\/span> (e.g., \"We lacked clear quality gates requiring load testing before launch\")\n - **Why 5 (Root Cause):** <span class=\"placeholder\">[ROOT_CAUSE]<\/span> (e.g., \"Our development process doesn't enforce non-functional requirements validation\")\n- **Contributing Factors:** Secondary causes that compounded the problem\n- **Warning Signs We Missed:** Were there early indicators we could have caught?\n\n**Challenge 2: <span class=\"placeholder\">[PROBLEM_DESCRIPTION]<\/span>**\n[Same structure]\n\nIdentify 5-10 significant challenges\/failures. Be specific and honest\u2014vague lessons like \"improve communication\" are useless. Drill to actionable root causes.\n\n**SECTION 6: DECISION ANALYSIS (What We'd Do Differently)**\n\nReview major decisions with benefit of hindsight:\n\n**Decision 1: <span class=\"placeholder\">[DECISION_DESCRIPTION]<\/span>**\n- **Context:** What was the situation? What options did we consider?\n- **Choice Made:** What did we decide and why? (Document the rationale at the time\u2014important for understanding decision quality vs. outcome quality)\n- **Outcome:** How did it turn out? Expected vs. actual impact.\n- **Hindsight Assessment:** \n - \u2705 **Good Decision, Good Outcome** (right call that worked)\n - \u26a0\ufe0f **Good Decision, Bad Outcome** (right call with bad luck\u2014would make same decision again)\n - \u26a0\ufe0f **Bad Decision, Good Outcome** (wrong call that got lucky\u2014correct for future)\n - \u274c **Bad Decision, Bad Outcome** (wrong call that failed\u2014learn and change)\n- **Lesson:** With current knowledge, what would we decide differently? Why?\n\n**Decision 2: <span class=\"placeholder\">[DECISION_DESCRIPTION]<\/span>**\n[Same structure]\n\nAnalyze 5-8 critical decisions (technology choices, scope decisions, resource allocation, launch timing, etc.). This separates decision quality from outcome quality\u2014sometimes good decisions have bad outcomes due to unforeseeable factors, and bad decisions get lucky. We want to improve decision-making process, not just outcomes.\n\n**SECTION 7: PROCESS & WORKFLOW ANALYSIS**\n\nEvaluate effectiveness of processes used:\n\n**Process 1: <span class=\"placeholder\">[PROCESS_NAME]<\/span>** (e.g., Sprint Planning, Code Review, QA Testing, Incident Response)\n- **How it worked:** Description of process as practiced (not as documented\u2014often different)\n- **Effectiveness Rating:** Excellent \/ Good \/ Adequate \/ Poor \/ Broken\n- **What worked well:** Specific strengths to preserve\n- **What didn't work:** Specific pain points or failures\n- **Suggested Improvements:** Concrete changes to make process more effective\n- **Comparative Benchmark:** How does our process compare to industry best practices?\n\n**Process 2: <span class=\"placeholder\">[PROCESS_NAME]<\/span>**\n[Same structure]\n\nAnalyze 4-6 key processes. This often reveals systemic issues\u2014recurring problems aren't usually individual failures but process gaps.\n\n**SECTION 8: TEAM DYNAMICS & COLLABORATION**\n\nAssess human\/organizational factors:\n\n**Communication Effectiveness:**\n- What communication worked well? (Specific examples: daily standups, Slack channels, design docs)\n- What communication broke down? (Missed handoffs, unclear requirements, misaligned expectations)\n- Cross-functional collaboration: How well did different teams\/roles work together?\n- Information flow: Did right information reach right people at right time?\n\n**Decision-Making Dynamics:**\n- Who made key decisions? Was decision authority clear?\n- Were decisions made at appropriate level? (Too centralized? Too distributed?)\n- Did team feel empowered to raise concerns? Were dissenting opinions heard?\n- Any decisions that should have involved more stakeholders?\n\n**Team Morale & Psychological Safety:**\n- How did team morale evolve throughout project? (High start, declined later? Improved over time?)\n- Did people feel safe raising problems, admitting mistakes, challenging decisions?\n- Were there conflicts? How were they handled?\n- What energized the team? What drained them?\n\n**Resource & Workload Management:**\n- Was workload distributed fairly? Any burnout risk situations?\n- Did team have necessary skills\/time\/tools to succeed?\n- Were there gaps in team composition that hindered progress?\n\nThis 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.\n\n**SECTION 9: EXTERNAL FACTORS & DEPENDENCIES**\n\nIdentify factors outside team's control that impacted outcomes:\n\n**External Factor 1: <span class=\"placeholder\">[FACTOR_DESCRIPTION]<\/span>**\n- **Impact on Project:** How did this affect timeline\/scope\/quality\/outcomes?\n- **Predictability:** Was this foreseeable? (Known risk, should have anticipated, truly unforeseeable)\n- **Response:** How did team adapt? Was response adequate?\n- **Future Mitigation:** How can we reduce exposure to similar factors in future?\n\nExamples: Market shifts, competitor actions, vendor failures, regulatory changes, executive priority shifts, dependent team delays, infrastructure incidents.\n\nDistinguishing factors we could control from factors we couldn't is crucial for fair assessment and realistic future planning.\n\n**SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS**\n\nSynthesize analysis into concrete improvements:\n\n**Category: Technical\/Architecture**\n**Lesson 1:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n- **Evidence:** What happened that taught us this? (Reference specific sections above)\n- **Action Item:** Specific, measurable change to implement\n - **What:** <span class=\"placeholder\">[CONCRETE_ACTION]<\/span>\n - **Owner:** <span class=\"placeholder\">[RESPONSIBLE_PERSON]<\/span>\n - **Deadline:** <span class=\"placeholder\">[TARGET_DATE]<\/span>\n - **Success Metric:** How will we know this is working? <span class=\"placeholder\">[METRIC]<\/span>\n\n**Category: Process\/Workflow**\n**Lesson 2:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Team\/People**\n**Lesson 3:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Planning\/Estimation**\n**Lesson 4:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\n**Category: Communication\/Collaboration**\n**Lesson 5:** <span class=\"placeholder\">[LESSON_STATEMENT]<\/span>\n[Same structure]\n\nGenerate 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.\n\n**Action Item Priority Matrix:**\n| Priority | Impact | Effort | Action Items |\n|----------|--------|--------|--------------|\n| P0 | High | Low | <span class=\"placeholder\">[QUICK_WINS]<\/span> (Implement immediately) |\n| P1 | High | Medium | <span class=\"placeholder\">[IMPORTANT_WORK]<\/span> (Schedule in next quarter) |\n| P2 | Medium | Low | <span class=\"placeholder\">[NICE_TO_HAVES]<\/span> (Fit into roadmap) |\n| P3 | Low | High | <span class=\"placeholder\">[DEFER_OR_DROP]<\/span> (Revisit later if still relevant) |\n\n**SECTION 11: KNOWLEDGE TRANSFER & DOCUMENTATION**\n\nCapture institutional knowledge for future teams:\n\n**Technical Artifacts:**\n- Architecture diagrams and technical decisions\n- Performance data and optimization learnings\n- Security considerations and compliance notes\n- Deployment procedures and operational runbooks\n\n**Process Artifacts:**\n- Updated process documentation incorporating improvements\n- Templates\/checklists for future projects\n- Decision frameworks for similar situations\n\n**Tribal Knowledge Codification:**\n- \"Things we wish we knew at the start\"\n- Non-obvious gotchas and edge cases\n- Workarounds and their rationale (temporary vs. permanent)\n\n**Where to Store:** <span class=\"placeholder\">[KNOWLEDGE_BASE_LOCATION]<\/span> (Confluence, Notion, internal wiki, etc.)\n**Maintenance:** Who will keep this updated? <span class=\"placeholder\">[OWNER]<\/span>\n\n**SECTION 12: FORWARD-LOOKING RECOMMENDATIONS**\n\nApply learnings to upcoming work:\n\n**Similar Upcoming Projects:**\nList 2-3 upcoming initiatives that can benefit from these learnings.\n\n**Proactive Applications:**\nFor each upcoming project:\n- Which lessons from this post-mortem are most relevant?\n- What specific actions should we take at project kickoff to avoid repeating mistakes?\n- What success patterns should we deliberately replicate?\n\n**Organizational Changes:**\nAny broader changes needed beyond specific action items?\n- Training\/skill development needs\n- Tool\/technology investments\n- Team structure or staffing adjustments\n- Cultural\/behavioral shifts\n\n**OUTPUT REQUIREMENTS**\n- Balance honesty with psychological safety (identify problems without blaming people)\n- Provide specific, actionable recommendations (not vague \"improve X\")\n- Use quantitative evidence wherever possible (metrics, timelines, costs)\n- Celebrate successes alongside analyzing failures (positive reinforcement)\n- Focus on systemic root causes, not surface symptoms\n- Create forward-looking action plan with owners and deadlines\n- Make it skimmable for executives (clear summaries, visual elements)\n\n**DELIVERABLE FORMAT**\n- 12-20 page comprehensive post-mortem report\n- Executive summary (1-2 pages) suitable for leadership\n- Detailed analysis sections (8-12 pages)\n- Action item tracker with owners, deadlines, priorities (1-2 pages)\n- Appendix with supporting data, timelines, metrics (as needed)\n\n**FOLLOW-UP PROCESS**\n- Share draft with project participants for feedback before finalizing (ensures accuracy, builds trust)\n- Present findings in team retrospective meeting (discuss, clarify, build consensus)\n- Track action item completion in monthly follow-ups\n- Re-assess impact in 3-month and 6-month reviews (did changes work?)\n- Archive in searchable knowledge base for future reference<\/div>\n <div class=\"tip-box\">\n <div class=\"tip-title\">\ud83d\udca1 Pro Tip<\/div>\n <p>Replace all placeholders (highlighted in orange) with specific project details. The most valuable post-mortems are brutally honest yet blameless\u2014focus on systems and decisions, not individuals. Include concrete metrics showing expected vs. actual outcomes. The goal is organizational learning, not individual judgment.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">The Logic Behind This Prompt<\/h3>\n \n <div class=\"logic-principle\">\n <h3>1. Blameless Culture Framework (Psychological Safety First)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> The single biggest barrier to effective post-mortems is fear\u2014team 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\u2014not 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\u2014decisions still have consequences\u2014but 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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>2. 5 Whys Root Cause Analysis (Drill Beyond Surface Symptoms)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\" \u2192 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\u2014\"API went down during product launch causing 2-hour outage.\" Why 1\u2014\"Server ran out of memory.\" Why 2\u2014\"Traffic exceeded capacity by 5\u00d7.\" Why 3\u2014\"Load testing only simulated 1\u00d7 expected traffic, not realistic peak scenarios.\" Why 4\u2014\"Load testing requirements weren't clearly defined in launch checklist.\" Why 5 (Root Cause)\u2014\"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\u00d7 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\u2014it's external reality. \"We didn't build market sensing mechanisms to detect changes early\" is root cause. \"Engineer made mistake\" isn't root cause\u2014it'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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>3. Balanced Success-Failure Analysis (Celebrate What Worked)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\u2014they 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\u2014\"Real-time collaboration feature launched with zero critical bugs despite complex CRDT implementation.\" Why it worked\u2014\"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\u2014\"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\u2014even failed projects have partial wins\u2014you're not looking hard enough or team is too demoralized to see them.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>4. Decision Quality vs. Outcome Quality Separation (Hindsight Analysis)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\"\u2014if 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\"\u2014this 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\u00d72 matrix: Good Decision\/Good Outcome (right call that worked\u2014replicate decision process), Good Decision\/Bad Outcome (right call with bad luck\u2014would make same decision again, no process change needed), Bad Decision\/Good Outcome (wrong call that got lucky\u2014must correct process despite positive outcome to avoid future failures), Bad Decision\/Bad Outcome (wrong call that failed\u2014learn and change immediately). Example: Decision\u2014\"Chose MongoDB over PostgreSQL for flexibility despite team knowing PostgreSQL better.\" Outcome\u2014Project 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\u2014should 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\u2014\"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).<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>5. Actionable Recommendations with Owners, Deadlines, and Success Metrics<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> 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\u2014only committed action with accountability does. This prompt mandates operationalizing every lesson into concrete action item with three components: (1) WHAT\u2014Specific, measurable change (not \"improve testing\" but \"add automated load testing stage to CI\/CD pipeline requiring 3\u00d7 traffic simulation before production deployment\"), (2) WHO\u2014Single owner accountable for completion (not \"engineering team\" but \"Sarah Chen, Senior DevOps Engineer\"), (3) WHEN\u2014Target 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\u2014these 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.<\/p>\n <\/div>\n\n <div class=\"logic-principle\">\n <h3>6. Forward-Looking Knowledge Transfer (Institutional Memory Capture)<\/h3>\n <p><strong>WHY IT MATTERS:<\/strong> Post-mortems are often backward-looking\u2014\"what happened in past project\"\u2014without 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\u2014created once, never referenced again\u2014because 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.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Example Output Preview<\/h3>\n <div class=\"example-box\">\n <div class=\"example-title\">\ud83d\udcca Scenario: TaskFlow Mobile App Launch (Mixed Success)<\/div>\n \n <p><strong>Context:<\/strong> 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\u2605 rating vs. 4.5\u2605 target.<\/p>\n\n <p><strong>EXECUTIVE SUMMARY<\/strong><\/p>\n \n <p><strong>Project Overview:<\/strong> 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.<\/p>\n\n <p><strong>Outcome Summary:<\/strong> Partial success. Launched 5 weeks behind schedule (7 months vs. 6-month target), achieved 15K downloads (60% of 25K target), and 4.2\u2605 average rating (84% of 4.5\u2605 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.<\/p>\n\n <p><strong>Key Learnings (Top 5):<\/strong><\/p>\n <ol style=\"margin-left: 1.5rem; margin-top: 0.5rem;\">\n <li><strong>Cross-platform complexity underestimated by 70%:<\/strong> 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.<\/li>\n <li><strong>Performance testing only on new devices masked real-world issues:<\/strong> QA tested on iPhone 13 and Pixel 6. 30% of users have iPhone 8-11 and mid-range Android where performance was 2-3\u00d7 worse. Should have tested on 3-year-old device range.<\/li>\n <li><strong>Real-time sync architecture was our biggest technical win:<\/strong> 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.<\/li>\n <li><strong>Staggered launch (iOS first, Android 3 weeks later) created operational chaos:<\/strong> 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.<\/li>\n <li><strong>Lack of dedicated mobile PM was critical gap:<\/strong> 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.<\/li>\n <\/ol>\n\n <p><strong>Critical Action Items (Top 5):<\/strong><\/p>\n <ol style=\"margin-left: 1.5rem; margin-top: 0.5rem;\">\n <li><strong>P0: Create mobile performance testing standard:<\/strong> 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)<\/li>\n <li><strong>P0: Fix iOS performance regressions:<\/strong> Profile and optimize laggy animations, reduce main thread blocking, implement progressive loading. Target: 4.5\u2605+ rating within 8 weeks. (Owner: iOS team | Deadline: Jan 31, 2024)<\/li>\n <li><strong>P1: Hire dedicated Mobile Product Manager:<\/strong> 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)<\/li>\n <li><strong>P1: Establish cross-platform architecture patterns:<\/strong> 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)<\/li>\n <li><strong>P1: Standardize launch process for multi-platform releases:<\/strong> Create launch playbook defining simultaneous vs. staggered criteria, communication templates, support readiness checklists. (Owner: Julia Santos, Launch PM | Deadline: March 1, 2024)<\/li>\n <\/ol>\n\n <p><strong>Overall Assessment:<\/strong> 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\u2014zero 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\u2014damaged first impressions (4.2\u2605 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.\"<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 3: OBJECTIVES vs. OUTCOMES ANALYSIS<\/strong><\/p>\n\n <p><strong>Objective 1: Launch mobile apps (iOS + Android) by Q2 end<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> June 30, 2023 (6 months from kickoff)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> August 8, 2023 (iOS: July 18, Android: August 8) \u2014 5.5 weeks late<\/li>\n <li>\u2022 <strong>Variance:<\/strong> +23% timeline overrun<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u26a0\ufe0f Partially Met (delivered but late)<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> 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).<\/li>\n <\/ul>\n\n <p><strong>Objective 2: Achieve 25,000 downloads in first quarter post-launch<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 25,000 downloads by November 8, 2023 (3 months post-launch)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 15,200 downloads by November 8, 2023<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -39% vs. target (60.8% achievement)<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u274c Not Met<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Download shortfall driven by: (1) Late launch reduced available user acquisition time (5 weeks less runway), (2) 4.2\u2605 initial rating discouraged downloads\u2014app store conversion rate 2.8% vs. industry benchmark 5% for 4.5\u2605+ 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\u2605 rating, estimated downloads would be 22K-24K (closer to target). The 4.2\u2605 rating was self-inflicted wound from performance testing gaps.<\/li>\n <\/ul>\n\n <p><strong>Objective 3: Maintain 4.5+ star average rating on both app stores<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 4.5\u2605+ average (iOS App Store + Google Play)<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 4.2\u2605 average (iOS: 4.3\u2605 based on 847 reviews, Android: 4.1\u2605 based on 623 reviews)<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -0.3 stars (-6.7%)<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u274c Not Met<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Rating driven down by two primary complaint categories: (1) Performance issues (38% of 1-3\u2605 reviews mentioned \"slow,\" \"laggy,\" \"freezing\")\u2014concentrated on iOS 12-14 devices and mid-range Android, (2) Android-specific crashes on Samsung devices (22% of Android negative reviews mentioned crashes)\u2014traced to incompatibility with Samsung's custom Android UI layer that wasn't caught in testing (we tested on Pixel only). The 4.2\u2605 rating is recoverable\u2014post-launch hotfixes addressed major performance issues and ratings have trended up (Week 1: 3.9\u2605 \u2192 Week 8: 4.2\u2605 \u2192 Current trajectory suggests 4.4\u2605 by Month 4 if improvements continue). However, initial negative reviews are permanent and affect discoverability (app stores algorithmically demote apps with <4.3\u2605 ratings in search results).<\/li>\n <\/ul>\n\n <p><strong>Objective 4: Achieve feature parity with web app for core workflows<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Target:<\/strong> 100% of \"core workflows\" (task creation, assignment, comments, file attachments, notifications, real-time collaboration) working on mobile<\/li>\n <li>\u2022 <strong>Actual Result:<\/strong> 90% feature parity achieved; missing: bulk task operations, advanced filtering, custom fields (deferred to v1.1)<\/li>\n <li>\u2022 <strong>Variance:<\/strong> -10% features<\/li>\n <li>\u2022 <strong>Achievement Status:<\/strong> \u2705 Met (90% considered sufficient for core workflows; deferred features are \"advanced\" not \"core\")<\/li>\n <li>\u2022 <strong>Analysis:<\/strong> Successfully delivered all core task management, collaboration, and notification features with mobile-appropriate UX. Real-time sync exceeded expectations\u2014changes 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.<\/li>\n <\/ul>\n\n <p><strong>Overall Success Rate: 1.5 of 4 objectives fully met (37.5% success rate)<\/strong><\/p>\n <p>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).<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 5: WHAT WENT WRONG (Challenges & Failures)<\/strong><\/p>\n\n <p><strong>Challenge 1: iOS Performance Degradation on Older Devices<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Impact:<\/strong> 38% of negative reviews cited performance issues. Delayed launch by 2 weeks for optimization sprint. Damaged brand perception (\"TaskFlow mobile is slow\").<\/li>\n <li>\u2022 <strong>Quantified Cost:<\/strong> 2-week timeline delay, estimated 2,000-3,000 lost downloads due to negative reviews, ~$40K MRR impact.<\/li>\n <\/ul>\n\n <p><strong>5 Whys Root Cause Analysis:<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Problem:<\/strong> iOS app experienced laggy animations and 1-2 second delays on iPhone 8-11 devices (representing 30% of user base).<\/li>\n <li>\u2022 <strong>Why 1:<\/strong> UI rendering blocked main thread, causing dropped frames (measured: 20-30 fps instead of 60 fps target).<\/li>\n <li>\u2022 <strong>Why 2:<\/strong> Heavy JSON parsing and image processing executed synchronously on main thread instead of background threads.<\/li>\n <li>\u2022 <strong>Why 3:<\/strong> Developers optimized for newest devices (iPhone 13) where synchronous operations were \"fast enough\" and didn't notice blocking.<\/li>\n <li>\u2022 <strong>Why 4:<\/strong> QA testing exclusively used iPhone 13 and 14 devices; no testing on 3-year-old hardware representing significant user base.<\/li>\n <li>\u2022 <strong>Why 5 (Root Cause):<\/strong> 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).<\/li>\n <\/ul>\n\n <p><strong>Contributing Factors:<\/strong> (1) iOS team lacked senior engineer with performance optimization expertise\u2014would have caught main thread blocking in code review. (2) Xcode Instruments profiling not part of standard development workflow\u2014performance issues weren't visible until beta. (3) Beta testing recruited from internal employees who predominantly had newer devices.<\/p>\n\n <p><strong>Warning Signs We Missed:<\/strong> 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.<\/p>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 6: DECISION ANALYSIS<\/strong><\/p>\n\n <p><strong>Decision 1: Build Native Apps (iOS\/Android) vs. Cross-Platform Framework (React Native\/Flutter)<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Context:<\/strong> Month 0, choosing mobile development approach. Options: Native (separate iOS Swift + Android Kotlin codebases), React Native, Flutter.<\/li>\n <li>\u2022 <strong>Choice Made:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Outcome:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Hindsight Assessment:<\/strong> \u2705 <strong>Good Decision, Mixed Outcome.<\/strong> 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.<\/li>\n <li>\u2022 <strong>Lesson:<\/strong> 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%).<\/li>\n <\/ul>\n\n <p><strong>Decision 2: Staggered Launch (iOS First, Android 3 Weeks Later)<\/strong><\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Context:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Choice Made:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Outcome:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Hindsight Assessment:<\/strong> \u274c <strong>Bad Decision, Bad Outcome.<\/strong> 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.<\/li>\n <li>\u2022 <strong>Lesson:<\/strong> 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.<\/li>\n <\/ul>\n\n <hr style=\"margin: 1.5rem 0; border: none; border-top: 1px solid #ddd;\">\n\n <p><strong>SECTION 10: LESSONS LEARNED & ACTIONABLE RECOMMENDATIONS<\/strong><\/p>\n\n <p><strong>Category: Technical\/Architecture<\/strong><\/p>\n <p><strong>Lesson 1:<\/strong> Offline-first architecture with robust conflict resolution is critical success factor for mobile apps with real-time collaboration requirements.<\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Evidence:<\/strong> 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\").<\/li>\n <li>\u2022 <strong>Action Item:<\/strong> 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.<\/li>\n <li>\u2022 <strong>Owner:<\/strong> Michael Torres, Senior Mobile Architect<\/li>\n <li>\u2022 <strong>Deadline:<\/strong> February 15, 2024<\/li>\n <li>\u2022 <strong>Success Metric:<\/strong> 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.<\/li>\n <\/ul>\n\n <p><strong>Category: Process\/Workflow<\/strong><\/p>\n <p><strong>Lesson 2:<\/strong> Mobile testing must mandate device range spanning 3-year-old hardware, not just newest flagships, to catch performance regressions affecting significant user segments.<\/p>\n <ul style=\"margin-left: 1.5rem; margin-top: 0.5rem; list-style: none;\">\n <li>\u2022 <strong>Evidence:<\/strong> 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\u00d7 worse. Cost: 2-week delay for optimization, damaged ratings, lost downloads.<\/li>\n <li>\u2022 <strong>Action Item:<\/strong> 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).<\/li>\n <li>\u2022 <strong>Owner:<\/strong> Lisa Patel, Mobile QA Lead<\/li>\n <li>\u2022 <strong>Deadline:<\/strong> January 31, 2024<\/li>\n <li>\u2022 <strong>Success Metric:<\/strong> 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%).<\/li>\n <\/ul>\n\n <p style=\"margin-top: 1rem;\"><em>[Additional lessons 3-10 following same structure, covering team composition gaps, launch process improvements, estimation calibration, cross-platform coordination, etc.]<\/em><\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Prompt Chain Strategy<\/h3>\n <p style=\"margin-bottom: 1.5rem;\">For optimal results, break the post-mortem analysis into three sequential prompts that build comprehensive organizational learning:<\/p>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 1: Data Collection & Timeline Reconstruction (Foundation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Gather factual information about what happened without interpretation or judgment.<\/p>\n <div class=\"prompt-box\">You are facilitating a blameless post-mortem. Help me collect objective data about this project:\n\n**Project:** <span class=\"placeholder\">[PROJECT_NAME]<\/span>\n**Timeline:** <span class=\"placeholder\">[START_DATE]<\/span> to <span class=\"placeholder\">[END_DATE]<\/span>\n**Team:** <span class=\"placeholder\">[TEAM_DETAILS]<\/span>\n**Outcome:** <span class=\"placeholder\">[SUCCESS_OR_FAILURE_DESCRIPTION]<\/span>\n\n**Task 1: Objectives & Metrics Documentation**\nList all original project objectives with measurable success criteria:\n- Objective 1: <span class=\"placeholder\">[GOAL]<\/span> | Target: <span class=\"placeholder\">[METRIC]<\/span>\n- Objective 2: <span class=\"placeholder\">[GOAL]<\/span> | Target: <span class=\"placeholder\">[METRIC]<\/span>\n... (continue for all objectives)\n\nThen document actual outcomes:\n- Outcome 1: <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> | Variance: <span class=\"placeholder\">[DELTA_VS_TARGET]<\/span>\n- Outcome 2: <span class=\"placeholder\">[ACTUAL_RESULT]<\/span> | Variance: <span class=\"placeholder\">[DELTA_VS_TARGET]<\/span>\n\n**Task 2: Chronological Timeline Construction**\nBuild month-by-month (or week-by-week for shorter projects) timeline:\n\n**Month 1:** <span class=\"placeholder\">[ACTIVITIES_AND_DECISIONS]<\/span>\n**Month 2:** <span class=\"placeholder\">[ACTIVITIES_AND_DECISIONS]<\/span>\n... (continue through project lifecycle)\n\nFor each period, note:\n- Major milestones achieved or missed\n- Key decisions made and rationale at the time\n- Unexpected challenges that emerged\n- Pivot points or course corrections\n\n**Task 3: Stakeholder Perspective Gathering**\nCollect input from different roles (maintain blameless tone):\n- Engineering perspective: Technical challenges? Surprises? What worked\/didn't work?\n- Product perspective: Requirement clarity? Scope changes? User feedback?\n- Design perspective: UX decisions? Usability findings? Design debt?\n- QA perspective: Testing coverage? Bugs found\/missed? Quality concerns?\n- Operations\/Support perspective: Deployment issues? User complaints? Operational burden?\n\n**Task 4: Quantitative Data Compilation**\nGather all available metrics:\n- Timeline data (planned vs. actual durations)\n- Budget data (estimated vs. actual costs)\n- Quality metrics (bugs found, incidents, performance measurements)\n- User metrics (adoption, satisfaction, ratings, feedback)\n- Team metrics (velocity, morale, turnover if relevant)\n\nOutput a comprehensive data package with objective facts, timelines, metrics, and multi-perspective input.<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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.\n <\/div>\n <\/div>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 2: Root Cause Analysis & Pattern Identification (Investigation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Analyze data to identify systemic root causes of successes and failures.<\/p>\n <div class=\"prompt-box\">Using the data collected in Step 1, conduct deep root cause analysis:\n\n**SUCCESSES ANALYSIS**\nFor each positive outcome or objective exceeded:\n\n**Success:** <span class=\"placeholder\">[WHAT_WENT_WELL]<\/span>\nApply \"5 Whys\" to understand success:\n- Why did this succeed? <span class=\"placeholder\">[REASON_1]<\/span>\n- Why did [REASON_1] happen? <span class=\"placeholder\">[REASON_2]<\/span>\n- Why did [REASON_2] happen? <span class=\"placeholder\">[REASON_3]<\/span>\n- Continue until reaching systemic enabler (process, decision, resource, culture)\n\n**Replicability:** How can we systematize this success? What made it possible that we can apply to future projects?\n\n**FAILURES ANALYSIS**\nFor each negative outcome, missed objective, or significant challenge:\n\n**Challenge:** <span class=\"placeholder\">[WHAT_WENT_WRONG]<\/span>\nApply \"5 Whys\" root cause analysis:\n- Problem: <span class=\"placeholder\">[SURFACE_PROBLEM]<\/span>\n- Why 1: <span class=\"placeholder\">[IMMEDIATE_CAUSE]<\/span>\n- Why 2: <span class=\"placeholder\">[DEEPER_CAUSE]<\/span>\n- Why 3: <span class=\"placeholder\">[SYSTEM_CAUSE]<\/span>\n- Why 4: <span class=\"placeholder\">[PROCESS_GAP]<\/span>\n- Why 5 (Root Cause): <span class=\"placeholder\">[SYSTEMIC_ROOT_CAUSE]<\/span>\n\n**Contributing Factors:** What other conditions made this problem worse or more likely?\n**Warning Signs:** Were there early indicators we missed?\n**Systemic vs. Isolated:** Is this one-time issue or symptom of broader process gap?\n\n**DECISION RETROSPECTIVE**\nFor 5-8 major decisions, assess using Decision Quality vs. Outcome Quality framework:\n\n**Decision:** <span class=\"placeholder\">[DECISION_MADE]<\/span>\n- **Information at decision time:** What did we know? What were the options?\n- **Rationale:** Why did we choose this path?\n- **Outcome:** What happened? Expected vs. actual impact.\n- **Quality Assessment:** \n - \u2705 Good Decision\/Good Outcome \u2192 Replicate decision process\n - \u26a0\ufe0f Good Decision\/Bad Outcome \u2192 Accept; would decide same way again\n - \u26a0\ufe0f Bad Decision\/Good Outcome \u2192 Lucky; fix decision process despite positive outcome\n - \u274c Bad Decision\/Bad Outcome \u2192 Learn and change immediately\n- **Lesson:** What does this teach us about decision-making?\n\n**PATTERN IDENTIFICATION**\nLook for recurring themes across successes and failures:\n- What patterns emerge? (e.g., \"Every timeline delay traced to underestimated integration complexity\")\n- What systemic gaps enable problems? (e.g., \"No process enforces cross-functional review before commitment\")\n- What cultural\/behavioral patterns drive outcomes? (e.g., \"Team afraid to escalate bad news early\")\n\nOutput comprehensive root cause analysis with 8-15 systemic findings (not surface symptoms).<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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\u2014iOS\/Android, Engineering\/Product, Dev\/QA\"). This analysis transforms raw data into insights ready for action planning.\n <\/div>\n <\/div>\n\n <div class=\"chain-step\">\n <h3>\ud83d\udd17 Step 3: Actionable Recommendations & Forward Planning (Implementation)<\/h3>\n <p style=\"margin-bottom: 1rem;\"><strong>Objective:<\/strong> Convert insights into concrete action plan with accountability and forward application.<\/p>\n <div class=\"prompt-box\">Based on root cause analysis from Step 2, create actionable improvement plan:\n\n**SECTION 1: Lessons Learned Catalog**\nFor each root cause identified in Step 2, formulate lesson learned:\n\n**Lesson:** <span class=\"placeholder\">[CLEAR_LESSON_STATEMENT]<\/span>\n- **Category:** Technical \/ Process \/ Team \/ Planning \/ Communication\n- **Evidence:** What happened that taught us this? (Reference specific events from timeline)\n- **Impact:** How significant is this lesson? (High\/Medium\/Low based on cost of problem or value of success)\n\nGenerate 15-20 lessons covering successes to replicate and failures to prevent.\n\n**SECTION 2: Action Item Development**\nFor each high and medium impact lesson, create specific action item:\n\n**Action Item:** <span class=\"placeholder\">[CONCRETE_CHANGE_TO_IMPLEMENT]<\/span>\n- **What:** Specific, measurable change (not vague \"improve X\")\n - Bad: \"Improve testing\" \n - Good: \"Add automated performance testing stage to CI requiring 60fps on iPhone X simulator before production\"\n- **Why:** Which lesson does this address? What problem does it prevent\/success does it replicate?\n- **Who:** Single owner accountable for implementation (Name, Role)\n- **When:** Target deadline (specific date)\n- **How:** Implementation approach (2-3 sentences on execution plan)\n- **Success Metric:** How will we measure effectiveness? (Quantitative if possible)\n\n**SECTION 3: Prioritization Matrix**\nClassify all action items by Impact (High\/Medium\/Low) and Effort (Low\/Medium\/High):\n\n**P0 (High Impact, Low Effort):** <span class=\"placeholder\">[QUICK_WINS]<\/span> \u2192 Implement immediately\n**P1 (High Impact, Medium Effort):** <span class=\"placeholder\">[IMPORTANT_WORK]<\/span> \u2192 Schedule next quarter\n**P2 (Medium Impact, Low-Medium Effort):** <span class=\"placeholder\">[NICE_TO_HAVES]<\/span> \u2192 Backlog\n**P3 (Low Impact or High Effort):** <span class=\"placeholder\">[DEFER]<\/span> \u2192 Revisit later if circumstances change\n\nFocus implementation bandwidth on P0 and P1 items.\n\n**SECTION 4: Forward Application**\nIdentify 2-3 upcoming projects that can benefit from these learnings:\n\n**Upcoming Project:** <span class=\"placeholder\">[PROJECT_NAME]<\/span>\n**Relevant Lessons:** Which 5-7 lessons from this post-mortem apply to upcoming project?\n**Proactive Actions:** What should we do at kickoff of upcoming project to apply lessons?\n- Avoid repeating mistakes: <span class=\"placeholder\">[PREVENTIVE_ACTIONS]<\/span>\n- Replicate success patterns: <span class=\"placeholder\">[REPLICATION_ACTIONS]<\/span>\n\n**SECTION 5: Follow-Up Framework**\nEstablish accountability and tracking:\n- **Monthly Review:** Track action item completion, update status, unblock impediments\n- **Quarterly Retrospective:** Assess impact\u2014did changes have intended effect? Any course corrections needed?\n- **Knowledge Base Integration:** Where\/how will these learnings be documented for future team access?\n- **Communication Plan:** How will findings be shared with broader organization?\n\nOutput comprehensive action plan (10-15 pages) with prioritized action items, owners, deadlines, success metrics, and forward application strategy.<\/div>\n <div class=\"expected-output\">\n <strong>Expected Output:<\/strong> 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.\n <\/div>\n <\/div>\n <\/div>\n\n \n <div class=\"section\">\n <h3 class=\"section-title\">Human-in-the-Loop Refinements<\/h3>\n \n <div class=\"hitl-tip\">\n <h3>1. Conduct Post-Mortem Meeting to Validate AI-Generated Analysis<\/h3>\n <p><strong>Challenge:<\/strong> 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\u2014interpersonal dynamics, unspoken assumptions, \"soft\" factors like morale or psychological safety that don't show up in metrics.<\/p>\n <p><strong>Refinement:<\/strong> 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>2. Verify Root Causes Through \"5 Whys\" Exercise with Cross-Functional Participants<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014process, 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\u2014root 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>3. Pressure-Test Action Items with \"Pre-Mortem on the Action Plan\"<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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 \u2192 Allocate explicit 20% of next sprint to post-mortem actions. Enforcement issue \u2192 Make new process mandatory part of launch checklist with sign-off. Shallow analysis \u2192 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%.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>4. Conduct \"Counterfactual Analysis\" to Test Lesson Robustness<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014\"CRDT architecture ensures sync reliability.\" Refined lesson\u2014\"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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>5. Establish Action Item Accountability Through Monthly Tracking Ritual<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> 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\u2014Slack announcements, team meeting shout-outs\u2014to 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.<\/p>\n <\/div>\n\n <div class=\"hitl-tip\">\n <h3>6. Build Searchable Post-Mortem Library with Tagging and Cross-Referencing<\/h3>\n <p><strong>Challenge:<\/strong> 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.<\/p>\n <p><strong>Refinement:<\/strong> Systematically build searchable post-mortem library: (1) Create centralized post-mortem repository (Confluence space, Notion database, internal wiki section) with consistent structure\u2014every 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]\u2014see 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.<\/p>\n <\/div>\n <\/div>\n\n \n <div class=\"footer-stats\">\n <div class=\"stat\">\n <div class=\"stat-value\">5.0\/5.0<\/div>\n <div class=\"stat-label\">Average Rating<\/div>\n <\/div>\n <div class=\"stat\">\n <div class=\"stat-value\">15,428<\/div>\n <div class=\"stat-label\">Times Copied<\/div>\n <\/div>\n <div class=\"stat\">\n <div class=\"stat-value\">1,203<\/div>\n <div class=\"stat-label\">User Reviews<\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n\n <script>\n function copyPrompt() {\n const promptText = document.getElementById('promptText').innerText;\n navigator.clipboard.writeText(promptText).then(() => {\n const button = document.querySelector('.copy-button');\n const originalText = button.innerHTML;\n button.innerHTML = '\u2705 Copied!';\n setTimeout(() => {\n button.innerHTML = originalText;\n }, 2000);\n }).catch(err => {\n console.error('Failed to copy text: ', err);\n alert('Failed to copy prompt. Please try selecting and copying manually.');\n });\n }\n <\/script>\n<\/body>\n<\/html>\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"<p>Post-Mortem Analysis – AiPro Institute\u2122 Prompt Library AiPro Institute\u2122 Prompt Library Post-Mortem Analysis \ud83d\udee0\ufe0f Product & Operations \u23f1\ufe0f 35\u201345 minutes \ud83d\udcca Intermediate to Advanced ChatGPT Claude Gemini Perplexity Grok The Prompt \ud83d\udccb Copy Prompt You are an expert organizational learning facilitator specializing in blameless post-mortem analysis, root cause investigation, and continuous improvement systems. Your role…<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[187],"tags":[],"class_list":["post-4949","post","type-post","status-publish","format-standard","hentry","category-product-operations"],"acf":[],"_links":{"self":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/comments?post=4949"}],"version-history":[{"count":4,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949\/revisions"}],"predecessor-version":[{"id":5019,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/posts\/4949\/revisions\/5019"}],"wp:attachment":[{"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/media?parent=4949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/categories?post=4949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/teen.aiproinstitute.com\/zh\/wp-json\/wp\/v2\/tags?post=4949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}