pre-mortem

what it does

Run a pre-mortem risk analysis on a PRD or launch plan. Categorizes risks as Tigers (real problems), Paper Tigers (overblown concerns), and Elephants (unspoken worries), then classifies as launch-blocking, fast-follow, or track. Use when preparing for launch, stress-testing a product plan, or identifying what could go wrong.

by Pawel Huryn · Pawel Huryn, MIT · version 1 · license MIT

Verified Before and after: 2 models 1 try per case View source Download .zip

Compare the answers

Answers from Claude Sonnet 5.5 and GPT-6.1 Sol · try 1 of 1

Same request, same model, once with the skill and once without. Read both and judge for yourself.

“We launch in two weeks. Run a pre-mortem on this plan.”

Source material given with the request

Product: Tallyhub accounting, launch of the new invoice engine on Monday, November 9. - All 48,000 customer accounts have their invoice history migrated overnight on Sunday, Nov 8. - Dry run: migrated 2,400 accounts (5%) in 3 hours. No errors. - Rollback plan: TBD. - Marketing email to all customers goes out Nov 9 at 9:00 am. - Support team briefing: Nov 6. - Sales is worried that competitor Ledgerfox might announce a similar feature this month.

with the skill

# Pre-Mortem Analysis: Tallyhub New Invoice Engine **Launch:** Monday, Nov 9 | **Migration:** Sunday night, Nov 8 | **Assumed today:** ~Oct 26 (dates below assume this) **Failure story:** It's Nov 10. The migration was still running when the 9:00 am email went out. Customers saw missing or wrong invoice history, support was swamped with no playbook, and we couldn't roll back. Customers lost trust in the numbers in their accounting system. --- ## Tigers (Real Risks) ### 1. The migration math doesn't fit the window (Launch-Blocking) - The dry run migrated 2,400 accounts in 3 hours. At that rate, 48,000 accounts (20x) takes about **60 hours**, not an overnight window. - Parallelization might fix this, but nobody has shown it. The dry run also may not reflect production: load, concurrency, and large accounts could all change throughput. - 5% is a small sample. If it was random, it likely under-represents the largest accounts with the longest invoice histories, which are the slowest and riskiest. ### 2. Rollback plan is "TBD" (Launch-Blocking) - A one-way migration of financial records for every customer with no tested way back is the biggest risk in this plan. - "No errors" in the dry run shows the process didn't crash. It doesn't show the data is correct (totals, tax, currency, invoice numbering, statuses). - Without a rollback, any problem discovered Monday morning becomes a live incident affecting all 48,000 accounts.

Show the rest (58 more lines)

### 3. Big-bang cutover with no go/no-go gate (Launch-Blocking) - Migrating everyone at once means any defect hits 100% of customers. There's no staged exposure and no decision point between "migration finished" and "email sent." - The email is scheduled for a fixed time (9:00 am Nov 9) regardless of migration status or validation results. ### 4. Support readiness is too thin and too late (Launch-Blocking) - The briefing is Nov 6, before the migration has happened, so support is briefed on a hypothetical. Only one business day separates it from launch. - There's no mention of an escalation path, known-issues doc, weekend/Monday staffing, or a status page template. - If migration problems occur, support is the first place customers hit them. ### 5. No post-migration data validation (Launch-Blocking) - Nothing in the plan describes reconciliation: invoice counts, totals, and balances per account, old vs. new. - For accounting software, silent data errors do far more damage than visible failures. ### 6. Live activity during the migration window (Fast-Follow, escalate to Launch-Blocking if unanswered) - What happens to invoices created, edited, or paid while migration runs? Are accounts frozen, and is that communicated? A delta/catch-up pass is needed or data will be lost or duplicated. --- ## Paper Tigers (Overblown Concerns) ### Ledgerfox announcing a similar feature - Sales' worry is understandable, but a competitor announcement doesn't change whether our launch succeeds. Customers on Tallyhub aren't switching over a feature announcement within weeks, especially with migration friction on their side. - Delaying launch to "beat" them would cost more than it saves. A broken launch hands Ledgerfox a better story than a feature announcement would. - Worth a light response: a one-page competitive talking-point sheet for Sales. No more investment than that. --- ## Elephants (Unspoken Worries) | Elephant | Why it matters | How to investigate | |---|---|---| | **Is the dry-run environment representative?** | Same hardware, load, and data shape as production? | Ask Eng for the environment spec and account-size distribution of the 2,400 sample vs. all 48,000 | | **Email timing vs. time zones** | 9:00 am in which zone? Customers in earlier zones get it before or during any cleanup | Confirm send time; consider staggering or gating on a health check | | **Compliance / audit trail** | Invoice history is a legal and tax record. Does the migration preserve numbering, timestamps, and audit logs? | Finance and Legal review of data-mapping rules | | **Integrations** | Do connected tools (payment processors, bank feeds, exports, API users) depend on old invoice formats or IDs? | Inventory integrations and test the top ones against migrated data | | **Old engine fate** | Is it turned off at cutover? If so, rollback is even harder | Decide and document whether old engine stays read-only for N days | | **Team fatigue / weekend coverage** | Who is actually on call Sunday night and Monday, and have they done this before? | Name the on-call roster and decision-maker | | **What does "success" mean?** | No adoption or health metrics are defined | Define 3-4 launch metrics and thresholds that trigger action | --- ## Action Plans for Launch-Blocking Tigers | # | Risk | Mitigation | Owner | Due | |---|---|---|---|---| | 1 | Migration doesn't fit window | Run a full-scale (or 25%+) rehearsal on production-like infrastructure with a representative sample including the largest accounts. Produce a measured throughput figure and a time estimate with buffer. If it doesn't fit in the window, switch to **phased migration** (e.g., pre-migrate in the days before and sync deltas Sunday). | Engineering lead | Rehearsal complete **Oct 30**; decision **Nov 2** | | 2 | No rollback plan | Write, build, and **test** a rollback: snapshot/backup of pre-migration data, a documented restore procedure, a time estimate, and a defined trigger ("if X by Y time, we roll back"). Keep old engine available read-only for at least 7 days. | Engineering + Infra/DBA | Plan **Oct 30**; tested in rehearsal by **Nov 4** | | 3 | Big-bang cutover, no gate | Define a go/no-go checklist (migration complete, validation passed, rollback ready, support ready) with a named decision-maker. Make the email **conditional**: scheduled but held until the gate passes. Consider a phased customer rollout (e.g., 10% → 50% → 100% over the first days). | Product manager (decision owner) with Eng | Checklist **Nov 2**; go/no-go meeting **Sun Nov 8 evening** and **Mon Nov 9, 7:30 am** | | 4 | Support unprepared | Move the briefing earlier (by ~Nov 4) and follow with a short update after the migration. Deliver FAQ, known-issues doc, escalation path to Eng, canned responses, status-page template, and Monday surge staffing. | Support lead + Product | Materials **Nov 3**; briefing **Nov 4**; refresher **Nov 9, 8:00 am** | | 5 | No data validation | Build automated reconciliation (invoice counts, totals, balances, tax, numbering per account) and run it on the rehearsal and again post-migration. Define an acceptable discrepancy threshold (ideally zero for financial totals). Manually spot-check a sample of large and unusual accounts. | Engineering + Finance/QA | Tooling **Nov 2**; run on rehearsal **Nov 4** | | 6 | Activity during migration | Decide: freeze edits during the window, or run a delta sync. Communicate it to customers in advance. | Product + Engineering | Decision **Oct 30**; customer notice **Nov 4–5** | --- ## Bottom Line The plan is **not ready to launch as written**. The two things that most need attention this week are the throughput math (60 hours vs. an overnight window) and the missing rollback. If either can't be resolved by **Nov 2**, the right move is to phase the migration or slip the launch date. Revisit this pre-mortem around **Nov 2** to verify mitigations are on track. **Note:** I can't write files in this conversation, so I haven't saved this. To save it, copy it into `PreMortem-Tallyhub-Invoice-Engine-2026-10-26.md`. If you share details like infrastructure, parallelism, or the account-size distribution, I can tighten the timeline estimate.

without

# Pre-mortem: Tallyhub invoice engine launch *It's Nov 10. The launch went badly. Here's why.* ## Most likely failure stories **1. The migration didn't finish by Monday morning.** The dry run moved 2,400 accounts in 3 hours. Scaled linearly, 48,000 accounts take about 60 hours, not an overnight window. Maybe it parallelizes, but the dry run doesn't show that. At 9:00 the email goes out and customers land in a half-migrated system with missing or duplicated invoice history. - *Unknowns:* Was the dry run single-threaded? Does throughput hold at 20x load? Was the 5% sample random, or skewed toward small accounts? Large accounts with tens of thousands of invoices are usually the slow, error-prone tail. **2. "No errors" hid bad data.** Zero exceptions isn't the same as correct output. For accounting data, the questions are whether totals, tax amounts, statuses, currencies, and invoice numbering reconcile between old and new, and whether anyone checked. Silent corruption in financial records is the worst outcome here, because customers find it weeks later during reconciliation or an audit. **3. Something breaks and there's no way back.** "Rollback: TBD" two weeks out is the biggest red flag. Once customers create new invoices in the new engine, a rollback means reconciling two diverging datasets. Without a decision made in advance, you'll be improvising at 6 a.m. Monday with the wrong people awake. **4. The email amplifies the problem.** It goes to 100% of customers at 9:00, regardless of migration state. If anything is wrong, you've sent all 48,000 customers to the broken thing at once and spiked support volume. **5. Support is underprepared and overwhelmed.**

Show the rest (26 more lines)

A Friday briefing leaves one touchpoint before a Monday peak. If the engine or migration changes in the last week, the briefing is stale. Support also needs a known-issues doc, escalation paths, and a way to tell whether a customer's account was migrated correctly. **6. Competitor pressure distorts decisions.** If Ledgerfox announces, the pull will be to ship on schedule no matter what the checks show. Fear of being second is how a no-go becomes a go. ## Other risks to check - **Writes during migration:** What happens to customers who create or edit invoices Sunday night? Is there a freeze, and are customers told? - **Time zones:** Is "overnight Sunday" overnight for all customers, or only for some? - **Integrations:** Do exports, payment processors, tax filings, or API users depend on the old invoice format or IDs? - **Single point of failure:** Who runs the migration, and are they on call and rested Monday? ## What to do in the next two weeks 1. **Do the throughput math this week.** Run a larger dry run (25–50%, including your largest accounts) in a production-like environment and get a real time estimate with a 2x buffer. 2. **Define and rehearse rollback.** Decide the approach (snapshot and restore, a feature flag back to the old engine, or dual-write), set the decision deadline and the person who makes the call, and rehearse it at least once. 3. **Build a validation step.** Run automated reconciliation (counts, totals, tax, and status per account) and spot-check manually. "Migrated" should mean "migrated and verified." 4. **Decouple the migration from the announcement.** Migrate over the weekend or earlier, verify, then send the email. Better still, stage the email in waves (10%, then 50%, then 100%) and gate each wave on health metrics. 5. **Consider a phased migration.** A beta cohort of 1–5% first, then waves. This also gives you a story if Ledgerfox announces: "We're rolling out now." 6. **Move support prep earlier.** Hold the briefing by Nov 4 or earlier, add a second session after final changes, and write the known-issues doc, escalation path, and a customer-facing status page. 7. **Set go/no-go criteria now**, while you're calm. For example: validation passing at 100% on the full dry run, rollback rehearsed, support trained, and on-call staffed. Hold a go/no-go meeting around Nov 5. 8. **Prepare for Ledgerfox.** Draft a response and talking points for Sales now. A competitor announcement shouldn't change your readiness criteria, and being slightly later with a working product beats being first with a broken one. ## Bottom line As written, the plan has a good chance of failing on timing alone, and it has no recovery path if it does. If the throughput test and rollback rehearsal can't be completed by about Nov 4, move the date. A one- or two-week slip costs much less than a failed migration of 48,000 customers' financial records. If you share more about the architecture, such as whether the migration is parallelizable and whether there's a feature flag, I can make the rollback and phasing recommendations more specific.

Answers are shown exactly as the model wrote them, from the first try, and nothing is picked by hand.

The models

2 models

Claude Sonnet 5.5

made by Anthropic

claude-sonnet-5-5 · revision not reported by the provider

1 try per case · tested 3 Nov 2026

GPT-6.1 Sol

made by OpenAI

gpt-6.1-sol · revision not reported by the provider

1 try per case · tested 3 Nov 2026

The tasks

written by Carte Blanche

internal-tool-cutover

“Engineering is rolling out our new in-house support tool next month. Can you stress-test the plan?”

invoice-migration

“We launch in two weeks. Run a pre-mortem on this plan.”

meal-kit-city-launch

“We're launching meal-kit delivery in Rivertown on November 16. What could go wrong?”

per-seat-pricing

“We're switching from $299/month flat to $25 per seat per month on January 1. Poke holes in it.”

worry-list-triage

“Here's our launch plan and the team's worry list. Which of these should we actually worry about?”

Install

Download the .zip and unzip it. Put its files, in a folder named pre-mortem, here:

Claude Code~/.claude/skills/Every project. For one project only, use .claude/skills/ inside it.

Codex~/.agents/skills/Every project. For one repository only, use .agents/skills/ inside it.

Cursor~/.cursor/skills/Cursor also reads the Claude Code and Codex folders above.

Then start a new session and ask for what the skill does. Other agents that read SKILL.md have their own skills folder; check their docs.

Coming after launch: get skills from inside your agent, no download needed.