Hands-On: Materials In → Analysis Out → Action Forward

Main case: "AI Open Class · Back-to-School Special" — a pre-enrolment livestream run to promote a course.

All five material types are present: the kickoff minutes, the live-day stand-up minutes, a group chat excerpt (20 messages), a task list (12 tasks) and activity data (funnel / channel / live metrics / budget). Lines like these run through the materials:

You can follow records like these instantly, but they cannot be presented as they stand — five documents each tell their own story, the timeline has to be assembled by hand, the goals need their basis aligned, and the causes have not been dug into. The three prompts below turn this pile into three deliverables you can hand over.

The order matters. B takes A's timeline as input and C takes B's comparison table. Skip A and ask for root causes, and AI has no restored process to reason about — it guesses causes from outcomes, and you get conclusions like "execution was not solid enough" that cannot be acted on.

The most valuable columns in run A are not the timeline — they are "contradictions" and "information gaps".

In this case they look like this:

• Contradiction: the task list shows "design requirement document" as complete, noted "on time"; but the group chat shows the 9/2 email contained only the main headline, with no size list, sub-copy or QR position, and the designer had to ask twice. A document delivered "on time" but not up to standard is the starting point of every delay that followed. This is exactly the kind of "green status, broken contents" item that manual review misses.
• Contradiction: the kickoff minutes assume attendance at 60% of signups, the stand-up estimated 230 attendees, and the actual attendance rate in the activity data is 56%. Only side by side do you see the estimate was optimistic.
• Information gap: the kickoff minutes note that the operations owner dropped offline for about five minutes and the referral task was passed on in a private chat, with no written record. That message never landed in any file — AI should flag it, not slide past it.

If AI does not give you these two columns, or writes them up as "execution was broadly fine with some delays", re-send parts 2 and 3 on their own and force it to do only those two things.

Note the trap in that last row: 28 of the 43 were recovered by hand between 9/23 and 9/27.

Read only the 72% and you conclude "broadly acceptable"; include "28 were recovered afterwards" and the conclusion flips — what actually deserves the retrospective is the fact that nobody followed up in the golden 48 hours after the livestream.

So watch two things in run B: the measurement basis must quote the original (no self-completion), and numbers that should be split must be split (on-the-day versus recovered). That is also why the constraint says "state facts only, no evaluation" — once evaluation enters early, everything hidden in the basis disappears.

Run C stands or falls on one sentence: "if several problems converge on the same root cause, say so explicitly."

In this case the task list carries four delayed items: poster +3 days, article +3 days, promotion shifted, referral window compressed. Ask AI to analyse them one by one and you get four parallel causes, each of which sounds like "tighten up management".

But tracing back along the timeline, they are one chain:

Requirement doc gave only a headline, no size list or sub-copy
      ↓
Poster went through 3 rounds, finalised +3 days late
      ↓
Article shifted 3 days, promotion window shortened
      ↓
Referral launched 9/14 → 9/15, window cut from 5 days to 3
      ↓
386 signups, 114 short of target

The root cause is not "the designer was slow" or "the owner did not explain it well". It is this rule: upstream deliverables have no acceptance checklist, so as long as the email went out, it counts as complete — task T02 turning green is exactly that rule at work.

Two more examples from the same case:

• 10 minutes of stuttering: the direct cause was insufficient home broadband upstream capacity; the root cause is that the "streaming stress test" task (T09) was on the list but no pass criteria were ever defined — the presenter test-streamed for 10 minutes the night before and called it tested. The fix is not attitude, it is acceptance criteria.
• Missing the golden 48 hours: the direct cause was that people lost during the stutter never received follow-up; the root cause is that export permission for the trial-user list sat with one person and there was no handover plan, and that person happened to be travelling for three days.

If AI returns "communication needs strengthening" or "sense of responsibility needs improving", send it back and add: "In the root cause column, anything you could write as a person's name is not a root cause."

The left column is the root cause; the four columns to its right are what a retrospective actually delivers. The fastest way to judge whether a retrospective is useful is the last column — if you cannot write acceptance criteria, the root cause was not dug deep enough.

Class reminder: anonymise before practising on a real project — client names, internal pricing, unpublished data and people's names all become placeholders. The structure of a retrospective has nothing to do with sensitive data, but what you send out cannot be taken back.