Use this when a client is preparing for launch and Kate wants to run a pre-mortem exercise, when Kate is assessing engagement risks for her own projects, or when any team needs to systematically identify what could go wrong before committing.
How it works
- You provide the product or plan being assessed, an approximate launch date, and any context
- The skill imagines failure, works backward, and categorizes risks using the Tigers/Paper Tigers/Elephants framework with a structured likelihood/impact matrix
- It returns a risk analysis that can be used two ways: as a client workshop artifact or as Kate's own engagement risk assessment
Prompt
You are conducting a pre-mortem risk analysis for Kate Makrigiannis. This is a dual-purpose tool: Kate uses it both to facilitate client launch readiness workshops and to assess risks in her own consulting engagements. Before writing, read knowledge/voice-tone-guide.md -- use the internal voice.
Inputs I will provide:
- Product or plan: {{PRODUCT_OR_PLAN}} (the product, feature, engagement, or initiative being assessed)
- Launch date: {{LAUNCH_DATE}} (target date or timeframe)
- Team (optional): {{TEAM}} (who is involved -- size, roles, experience level)
- Key dependencies (optional): {{DEPENDENCIES}} (other teams, APIs, approvals, vendor deliverables)
- Known constraints (optional): {{CONSTRAINTS}} (budget, technology choices, compliance requirements, organizational politics)
- Definition of success (optional): {{SUCCESS}} (how will you know this worked?)
- Context (optional): {{CONTEXT}} (PRD, engagement scope, team dynamics, market conditions, anything relevant)
Step 1: Understand what's being assessed Read any provided context thoroughly. Determine whether this is:
- Client launch prep: Kate is facilitating a pre-mortem for a client team preparing to ship something
- Engagement risk assessment: Kate is assessing risks in her own consulting engagement (scope creep, stakeholder alignment, delivery risks)
Adjust the lens accordingly, but use the same framework for both.
Step 2: Generate failure scenarios across risk categories
Imagine it is past the launch date. The project has failed. Work backward: what went wrong?
Generate failure scenarios across these categories:
| Category | What to consider |
|---|---|
| Technical | Architecture does not scale, integration breaks, performance issues, security vulnerabilities, tech debt compounds |
| Scope | Requirements were misunderstood, scope creep, underestimated complexity, missing edge cases |
| People & Team | Key person leaves, team lacks needed skills, collaboration breakdown, stakeholder misalignment |
| External Dependencies | API changes, vendor delays, partner does not deliver, regulatory changes |
| User Adoption | Users do not want this, UX is confusing, migration path is too painful, wrong problem solved |
| Timeline | Deadline was unrealistic, unplanned work displaced this, sequential dependencies created bottlenecks |
Step 3: Categorize risks using Tigers/Paper Tigers/Elephants
Reference knowledge/pm-execution-templates.md for the Tigers/Paper Tigers/Elephants framework.
Tigers -- Real problems that could derail this. Based on evidence, experience, or clear logic. These require action.
Paper Tigers -- Concerns that sound serious but are overblown. Worth documenting so stakeholders stop worrying about them. Explain why each is not a true threat.
Elephants -- Unspoken concerns nobody is validating. Could be real; unclear. These need investigation before launch.
Step 4: Assess likelihood and impact for each Tiger
For each Tiger, assign:
- Likelihood: High / Medium / Low (how probable is this?)
- Impact: High / Medium / Low (how bad is it if this happens?)
- Urgency level:
- Launch-blocking: Must be resolved before go-live. No exceptions.
- Fast-follow: Must be solved within 30 days post-launch.
- Track: Monitor post-launch; address if it becomes real.
Risk Summary Matrix
| # | Risk | Category | Likelihood | Impact | Urgency | Mitigation |
|---|---|---|---|---|---|---|
| 1 | (Risk description -- specific, not generic) | (category) | H/M/L | H/M/L | (Launch-blocking / Fast-follow / Track) | (specific action + owner) |
Step 5: Build action plans for launch-blocking Tigers For every launch-blocking Tiger, specify:
- The risk (one sentence)
- Mitigation action (concrete, specific)
- Fallback if the primary mitigation is not sufficient
- Suggested owner (role or function)
- Decision/completion deadline
Step 6: Identify early warning signals
For each top risk, define observable signals that would indicate the risk is materializing:
- (Signal) -- (what to look for and when to escalate)
Pre-Mortem Analysis: {{PRODUCT_OR_PLAN}}
Date: (today's date) Timeline: (ship date or milestone) Team: (size and composition, if provided) Definition of success: (what success looks like, if provided)
Tigers (Real Risks)
For each:
- Risk: [description]
- Category: [Technical / Scope / People / Dependencies / Adoption / Timeline]
- Likelihood: [H/M/L] -- (why this probability)
- Impact: [H/M/L] -- (what happens if this occurs)
- Urgency: [Launch-blocking / Fast-follow / Track]
- Evidence: [why this is real]
- Mitigation: [what to do about it]
- Fallback: [if the mitigation is not sufficient]
Paper Tigers (Overblown Concerns)
For each:
- Concern: [what people worry about]
- Why it's a Paper Tiger: [why it's not a real threat]
Elephants (Unspoken Worries)
For each:
- Concern: [the thing nobody is talking about]
- Investigation approach: [how to determine if it's real]
- Who should own this: [role/function]
Risk Summary Matrix
| # | Risk | Category | Likelihood | Impact | Urgency | Mitigation |
|---|---|---|---|---|---|---|
| 1 | [risk] | [category] | H/M/L | H/M/L | [urgency] | [action + owner] |
Launch-Blocking Action Plan
| Risk | Mitigation | Fallback | Owner | Deadline |
|---|---|---|---|---|
| [risk] | [action] | [fallback] | [who] | [when] |
Early Warning Signals
Watch for these indicators that a risk is materializing:
- (Signal) -- (what to look for and when to escalate)
Accepted Risks
These risks were identified but the team has decided to accept them:
- (Risk) -- accepted because (rationale: low likelihood, low impact, or cost of mitigation exceeds cost of risk)
Financial Risk Scenarios
For each Tiger identified, add a financial dimension:
- Revenue impact if it materializes: Estimate the dollar cost of this risk becoming real. Revenue delay, lost deals, reduced expansion, margin erosion. Range estimates are fine ("$X-Y impact over N months").
- Launch delay cost: What does each week or month of delay cost? Include: deferred revenue, competitive window closing, team carrying costs during the delay. If the product has seasonality or a market window, note when the delay becomes fatal rather than expensive.
- Runway impact: If multiple Tigers hit simultaneously (the bad scenario), how does it affect the company's financial runway? Does it change the fundraising timeline? Force a pivot? Accelerate burn without accelerating revenue?
Present as a summary table after the Tiger details:
| Tiger | Financial Impact | Delay Cost (per month) | Runway Effect |
|---|---|---|---|
| [risk] | [estimate] | [estimate] | [Negligible/Moderate/Severe] |
This is not about precision. It is about making risk conversations concrete. "We might lose customers" is abstract. "A 2-month delay costs us $X in deferred ARR and lets [competitor] ship first" is actionable. Flag numbers that are guesses with .
Kate's Facilitation Notes
- Suggested discussion questions for each category
- How to present Paper Tigers without dismissing the people who raised them
- How to surface Elephants without making the room defensive
For ongoing engagement risk monitoring, use the engagement-risk-radar skill. The pre-mortem is a point-in-time exercise; risk-radar provides continuous tracking. For surfacing cognitive biases before the pre-mortem, use bias-spotter.
Example Output
Input
- Product or plan: Launch of Meridian Health's patient-facing appointment self-scheduling portal, replacing the phone-based booking system across 14 clinic locations
- Launch date: March 3, 2025 (hard deadline tied to Q1 board commitment and contract end date for the legacy telephony vendor)
- Team: 8-person cross-functional team — 2 product managers (one junior), 3 engineers, 1 UX designer, 1 clinical operations lead, 1 IT security officer; no dedicated QA resource
- Key dependencies: Epic EHR integration via HL7 FHIR API (Epic sandbox access only as of today), patient notification via Twilio SMS, SSO through Okta, clinic staff training managed by a third-party vendor (HealthTrain Solutions)
- Known constraints: HIPAA compliance required; Epic production credentials need sign-off from Chief Medical Information Officer; budget is fixed at $1.2M with no contingency fund; two engineers are split across another active project
- Definition of success: 40% of appointments booked via self-service portal within 90 days of launch; call center volume reduced by 25%; zero HIPAA incidents in first 6 months
Output (abbreviated)
Pre-Mortem Analysis: Meridian Health Patient Self-Scheduling Portal
Date: January 14, 2025 Timeline: March 3, 2025 (47 days to launch) Team: 8 people — product, engineering, UX, clinical ops, IT security; no dedicated QA Definition of success: 40% self-service booking within 90 days; call center volume down 25%; zero HIPAA incidents in 6 months
Tigers (Real Risks)
Tiger 1
- Risk: Epic production API credentials are not approved by launch date, making the portal unable to read or write live appointment data
- Category: External Dependencies
- Likelihood: H — sandbox-only access with 47 days to go; CMIO approval involves legal, security, and Epic's own credentialing process, none of which are on the critical path yet
- Impact: H — without production API access, the portal cannot function. Full launch stop.
- Urgency: Launch-blocking
- Evidence: Epic credentialing in healthcare systems routinely takes 4–8 weeks and is frequently delayed by security review. The team has not started this process.
- Mitigation: Escalate CMIO sign-off to this week. Assign clinical operations lead as internal champion. Map every approval step; put it on a daily status tracker starting Monday.
- Fallback: If credentials are delayed past February 10, negotiate a 2-week soft launch at 2 pilot clinics only, buying time for full credential approval while still meeting the board milestone in spirit.
Tiger 2
- Risk: No dedicated QA resource means HIPAA-sensitive data flows (PHI in API payloads, session management, audit logging) are not adequately tested before go-live
- Category: Technical / People
- Likelihood: H — QA is explicitly absent from the team; engineers are split across two projects
- Impact: H — a HIPAA incident directly voids the definition of success, triggers OCR reporting obligations, and creates reputational damage that cannot be undone post-launch
- Urgency: Launch-blocking
- Evidence: PHI-handling bugs are consistently found during structured security QA, not during developer self-testing. Split engineering attention compounds this.
- Mitigation: Engage a HIPAA-specialized QA contractor immediately. Budget impact is approximately $25–35K; present to leadership as cost of launch insurance, not scope creep.
- Fallback: If budget is rejected, reallocate the IT security officer to run structured PHI data-flow testing for 2 dedicated weeks in February, with a written sign-off checklist.
Tiger 3
- Risk: HealthTrain Solutions does not complete clinic staff training across all 14 locations before March 3, leaving front-desk staff unable to support patients using the new portal
- Category: External Dependencies / People
- Likelihood: M — third-party vendor timeline has not been confirmed; 14 locations is a large training surface for a 47-day window
- Impact: H — undertrained staff will revert patients to phone booking, directly undermining the 40% self-service adoption target and eroding clinic confidence in the product
- Urgency: Launch-blocking
- Evidence: Third-party training vendors in healthcare commonly require 6–8 weeks for multi-site rollouts. No confirmed schedule exists.
- Mitigation: Require HealthTrain to submit a signed, location-by-location training schedule by January 21. Build in a February 14 checkpoint; if more than 3 locations are behind, trigger contingency.
- Fallback: Prioritize training at highest-volume clinics (top 5 by appointment count). Launch at those locations March 3; roll remaining 9 on a 2-week stagger.
Tiger 4
- Risk: Twilio SMS notification failures cause patients to miss appointment confirmations, leading to no-show rates that discredit the portal in the first 30 days
- Category: Technical / Adoption
- Likelihood: M — Twilio is reliable at scale, but phone number formatting across legacy patient records is inconsistent; undelivered messages are a known failure pattern
- Impact: M — no-show rates above baseline will be attributed to the new system by clinic leadership, creating a trust deficit that is hard to reverse
- Urgency: Fast-follow
- Evidence: Legacy telephony system data shows 12% of patient records have malformed or missing mobile numbers. Twilio will silently fail on these without a fallback notification path.
- Mitigation: Audit patient records for valid mobile numbers before launch. Build an email fallback for failed SMS. Add delivery confirmation logging to the dashboard from day one.
- Fallback: Default to email-only notifications for the first 30 days while SMS delivery rates are validated.
Paper Tigers (Overblown Concerns)
-
Concern: Patients won't trust a digital booking system and will refuse to use it Why it's a Paper Tiger: Meridian's patient population skews 35–65, a demographic that has adopted digital banking, telehealth, and pharmacy apps at high rates. The concern conflates "some patients prefer phone" with "patients won't adopt self-service." A well-designed opt-in flow accommodates both. The phone line stays open.
-
Concern: The Okta SSO integration will cause login friction and kill adoption Why it's a Paper Tiger: Okta is mature, well-documented, and already deployed in Meridian's environment. The integration is low-complexity relative to the Epic FHIR work. The UX designer can address login-screen friction in the current sprint without additional risk.
Elephants (Unspoken Worries)
-
Concern: Clinic physicians were not consulted on scheduling logic (buffer times, appointment type rules, double-booking constraints) and the portal's rules may not match how clinics actually operate Investigation approach: Run a structured review session with 3–4 physicians and 2 clinic managers before February 1. Map the scheduling rules in the system against actual clinic protocols. This is a 2-day effort with high return. Who should own this: Clinical operations lead, with product manager present
-
Concern: The fixed $1.2M budget with no contingency means that any of the above Tigers materializing forces a cut somewhere — and nobody has agreed on what gets cut Investigation approach: Facilitate a 90-minute budget triage session with the product leads and finance sponsor. Agree in advance on the priority stack: what gets descoped first if cost pressure hits. Do this before February 1, not during a crisis. Who should own this: Senior product manager and project sponsor
Risk Summary Matrix
| # | Risk | Category | Likelihood | Impact | Urgency | Mitigation |
|---|---|---|---|---|---|---|
| 1 | Epic production API credentials not approved by launch | Dependencies | H | H | Launch-blocking | Escalate CMIO approval this week; clinical ops lead owns daily tracking |
| 2 | No QA resource; PHI data flows untested | Technical / People | H | H | Launch-blocking | Engage HIPAA QA contractor by Jan 21; fallback: redirect IT security officer |
| 3 | HealthTrain training incomplete across 14 sites | Dependencies / People | M | H | Launch-blocking | Require signed location schedule by Jan 21; stagger launch if behind |
| 4 | Twilio |