Author: AILesson8 min setupTested with:Reviewed: 2026-08-29
Quick answer
Review observable outcomes, process conditions, and improvement experiments without assigning blame. Provide: Project baseline and outcomes, Participants and context, Retrospective scope. Expected result: A psychologically safer retrospective agenda with evidence prompts and bounded experiments.
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Create a project retrospective meeting agenda grounded in observable evidence.
Objectives, plan, actual outcomes, timeline, incidents, changes, and evidence:
[baseline]
Participants, power differences, confidentiality, conflict, accessibility, and facilitator:
[team]
Duration, scope, data, authority, decision limits, and follow-up:
[scope]
Separate outcomes, observations, interpretations, and proposed causes. Review system conditions and decision points without inferring intent or turning the meeting into individual performance evaluation. Offer equal input routes and a way to raise sensitive issues outside the group. Prioritize no more improvement experiments than the supplied capacity supports; each needs hypothesis, owner only if confirmed, evidence, duration, and review trigger. Return pre-work, timed agenda, evidence questions, facilitation safeguards, experiment template, parking lot, and follow-up review.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Project baseline and outcomes
Website migration planned 6 weeks, completed in 8. Forty pages moved; five had broken links at launch, fixed next day. Plan assumed content approval by week 2; 11 pages arrived in week 4. Two unplanned accessibility fixes added 3 days. No evidence identifying a single cause of the full delay.
Participants and context
Product, content, engineering and accessibility representatives; engineering manager attends with two engineers. Product Ops facilitates. Anonymous pre-input available. Individual performance is out of scope.
Retrospective scope
60 minutes. Data: plan, issue log, approval dates, launch checks. Team can approve at most two process experiments for next release. Sensitive staffing issues route to managers separately. Review experiments after four weeks.
Example output
Pre-work: timeline with planned/actual dates; issue log; approval dates; launch-check evidence. Participants label each note Observation, Interpretation, or Proposal; anonymous route remains open.
Agenda (60 minutes)
0–6 access, confidentiality, no-blame and no-performance boundary.
6–14 restate objective and recorded outcomes: 40 pages, eight weeks, five launch link issues fixed next day.
14–26 timeline review: content approvals, accessibility additions, dependencies. Ask 'What changed, when, and according to which record?' Do not ask who caused the delay.
26–36 patterns that helped or hindered; separate evidence from hypotheses.
36–46 generate process experiments silently first, then round-robin; staffing concerns route outside.
46–54 select no more than two using supplied authority and capacity.
54–60 confirm experiment record and four-week review.
Experiment template: hypothesis; specific process change; scope; confirmed owner; start/end; observable evidence; risks; stop/review trigger. Candidate experiment, not pre-approved: require content approval-status check at the end of week 1 and escalate pages lacking an approver. Evidence needed: whether this would have exposed the 11 late pages earlier.
Why this works
1
Evidence-status separation prevents confident causal stories from replacing what the project actually recorded.
2
Bounded experiments convert learning into testable change without overloading the team.
Check the result
Are observations separated from interpretations and causal hypotheses?
Does the agenda avoid individual performance judgment and motive inference?
Are experiments limited, owned only when confirmed, and reviewable?
Use it with confidence
Frequently asked questions
Practical answers about when to use this recipe, what to provide, and where human review still matters
What should I prepare before using “Create a project retrospective meeting agenda”?
For “Create a project retrospective meeting agenda,” prepare Project baseline and outcomes, Participants and context, and Retrospective scope. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.
When is the “Create a project retrospective meeting agenda” result not ready to use?
The result is not ready if it does not yet deliver the stated outcome—A psychologically safer retrospective agenda with evidence prompts and bounded experiments—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.
Which AI tools have recorded tests for “Create a project retrospective meeting agenda”?
No model run is recorded for “Create a project retrospective meeting agenda” as of 2026-08-29. Treat it as a model-portable template rather than a compatibility claim. Run the worked example first, keep every constraint visible, and compare the output with the result checks before using it on real material.
