Describe a project and Joy runs a pre-mortem: it imagines the launch has already failed, works backward to surface the likely failure modes, ranks them by likelihood and impact, and gives you an early warning sign and a concrete fix for each, so you close the gaps before you build.
Run a pre-mortem on our [new compliance training rollout launching in Q3] and flag the biggest risks.
An illustrative example. Your output will reflect your own sources, data, and prompts.
I assumed the rollout had already failed and worked backward, using your project plan and last year's rollout retro in the Knowledge Center to ground each risk. Here's the ranked read, with the two that stand out flagged.
I imagined it’s the end of Q3 and the rollout has gone badly, then worked backward from that failure using your project plan, the retro from last year’s rollout, and the stakeholder map in the Knowledge Center. Six failure modes explain most of the ways it could go wrong. I scored each as likelihood × impact on a 1–5 scale, so the risk score runs from 1 to 25. Two sit well ahead of the rest: low completion before the deadline (20) and content that’s outdated against the current regulation (16). Those are where I’d put your attention first.
Risk score by failure mode (likelihood × impact, 1–25)
Low completion before the deadline — score 20. Likelihood high (5), impact high (4). Last year’s retro shows completion stalling near 61% two weeks out, and this cohort is larger. If the week-two figure is under about 50%, treat it as the failure already in progress. The fix is to stagger assignment by team with a hard mid-quarter checkpoint and give each manager a weekly completion list for their own reports.
Content outdated against the current regulation — score 16. Likelihood high (4), impact high (4). The source policy was last reviewed before the latest rule change, so the course could teach a superseded requirement. The signal to watch for is no compliance sign-off on the final script; the fix is a dated legal and compliance review before build freeze rather than after launch.
The full ranking, with an early warning sign and a concrete mitigation for each, is below.
| Risk | Likelihood | Impact | Early warning sign | Mitigation |
|---|---|---|---|---|
| Low completion before the deadline | High | High | Week-two completion under about 50% | Stagger assignment by team with a hard mid-quarter checkpoint, and give managers a weekly completion list for their own reports |
| Content outdated vs the current regulation | High | High | No compliance sign-off on the final script | Get a dated legal and compliance review of the content before build freeze, not after launch |
| Manager buy-in missing | High | Med | Managers not forwarding the kickoff note to their teams | Brief managers first and hand each one a two-line script plus their own team’s list |
| Translation and localization delays | High | Med | Localized files not back by build freeze | Lock the source copy early and run localization in parallel with build, not after it |
| LMS and SSO access issues | Med | Med | Login failures for the test group in staging | Run an SSO smoke test with a small pilot group two weeks out |
| Survey fatigue skews feedback | Med | Low | Post-course survey response under about 20% | Keep the survey to three questions and embed it at the end of the final module |
If you harden two things before you build, make them the completion plan and the compliance sign-off — together they carry the two highest scores. The lower four (manager buy-in at 15, localization delays at 12, LMS and SSO access at 9, and survey fatigue at 6) each deserve a mitigation but shouldn’t hold up the launch.
Want me to turn the top risk into an owner and action checklist, or draft the full mitigation plan for one of these risks?
Project Pre-Mortem flips the post-mortem. You describe the project, and Joy assumes it has already failed, then works backward to name the specific ways that could happen. It ranks each failure mode by likelihood and impact, flags the early warning sign to watch for, and pairs it with a concrete mitigation, so the gaps are visible while you can still act on them.
Tell Joy what you're launching, when, and for whom. Point it at the project plan, past retros, and stakeholder map in your Knowledge Center so the risks are grounded in your real context.
Ask Joy to assume the project has failed and work backward. Use the /analyze command or just describe what you need. It surfaces the likely failure modes and scores each by likelihood and impact.
Joy returns a ranked risk table with an early warning sign and a mitigation for each, plus a chart of the risk scores so the top two are obvious. Push back or add context and it re-ranks.
Copy the risk table and mitigations into your project doc, kickoff deck, or RAID log. Joy surfaces the risks; you decide which ones to build guardrails for.
Save this ask as a custom command on the assistant your team already uses, so anyone can run it in one step.
Instead of a generic risk checklist, Joy assumes the project failed and reasons back to the specific ways it could, so the list is about your project, not any project.
Every risk gets a likelihood and impact rating and a 1–25 score, so the priority is obvious at a glance rather than a flat list to argue over.
Each risk comes with the concrete signal to watch for, so you can tell when a risk is turning into the failure while there's still time to act.
Joy pairs every risk with a specific mitigation you can drop straight into the plan, not a vague 'monitor closely'.
Run it on a new policy or process change to surface the adoption and communication risks before you announce it.
Point it at an LMS or platform migration to catch access, data, and timing risks before cutover.
Pressure-test next year's L&D plan before the budget is committed, so the shaky assumptions show up early.
Stress-test a certification or compliance deadline to see where completion and content risks concentrate.
A pre-mortem is a planning exercise where you imagine a project has already failed and work backward to name the reasons why. It surfaces risks earlier than a normal risk review because assuming failure makes the weak points easier to see. Joy runs the exercise on your project and returns a ranked list of failure modes with warning signs and fixes.
A post-mortem happens after a project ends and explains what went wrong. A pre-mortem happens before you build, while you can still change the plan. This recipe runs the pre-mortem, so the gaps show up early enough to close.
No. It's an on-demand analysis. You run it when it helps (before kickoff, before build freeze, before launch) and Joy reads the current plan and returns a fresh read. There's no standing board to keep up to date.
Joy rates each risk on likelihood and impact and multiplies them into a 1–25 score, then ranks the list by that score. The chart and table show the ratings so you can see the reasoning, adjust the assumptions, and ask Joy to re-rank.
Yes. Joy can draft an owner and action checklist for the top risk, or a fuller mitigation plan for any one risk, as text in the chat. You copy it into your project doc, RAID log, or kickoff deck. Joy drafts the plan; it doesn't assign owners or track the work for you.
Join the waitlist and be first to try this workflow when JoySuite launches.