Fupan comes from Go players replaying a game to learn from it. In Chinese companies it is the standard way to review a project, campaign, or launch, whatever the outcome. Its four familiar steps are: review the goal, assess the result, analyse the causes, and draw reusable rules. The value lies in the last step, turning one experience into a rule the team can reuse. This skill runs all four and keeps the tone blame-free.
Write the output in Simplified Chinese unless asked otherwise. For an incident postmortem, see incident-postmortem; for a sprint retrospective, see retro-analysis.
What This Skill Produces
- The retrospective document in the four standard steps
- Root causes, split into controllable and uncontrollable
- Lessons as rules: each stated so the team can apply it next time
- Actions with owners and dates
- A meeting agenda if the retrospective is held as a group session
Required Inputs
Ask for these if not provided:
- What is being reviewed: project, campaign, launch, quarter
- The original goal, with the numbers set at the start
- The actual result, with the same numbers
- The timeline and key decisions
- Who took part, and whether this is for a group meeting or an individual review
Framework
- Review the goal: what was the goal, exactly, and how was success defined at the time? If the goal was vague, say so; that is itself a finding.
- Assess the result: actual against target, metric by metric. Highlights and shortfalls, both with evidence.
- Analyse the causes: for each big gap or success, ask "why" until reaching a cause the team could act on. Split into:
- Subjective / controllable: decisions, process, preparation
- Objective / uncontrollable: market, policy, external events. Name them, then move on; dwelling here teaches nothing.
- Draw reusable rules: express each lesson as a rule: "When [situation], take [action], because [reason]." A useful rule would change a future decision.
- Action plan: what changes now, with an owner and a date.
Tone: discuss decisions and systems, not people. Say "The review process lacked data validation" rather than "So-and-so did not look at the data".
Output Format
Retrospective: [project / activity name] | [date]
1. Review the goal | Goal | Original success measure | Target value |
2. Assess the result | Metric | Target value | Actual value | Completion rate | Notes |
- Highlights: ...
- Shortfalls: ...
3. Analyse why | Symptom | Root cause | Subjective controllable / Objective uncontrollable |
4. Draw the rules
- When [situation], we should [action], because [reason].
5. Action plan | Action | Owner | Due date |
Appendix: 复盘 meeting agenda(if needed, 60 minutes)
Quality Checks
- The original goal is stated with its original numbers
- Every large gap has a root cause that is actionable
- Controllable and uncontrollable causes are separated
- Every lesson is phrased as a reusable rule
- Every action has an owner and a date
- No individual is blamed by name
Anti-Patterns
- Only reviewing failures. Successes hide lessons too; review them the same way.
- Stopping at "objective reasons". If every cause is external, the team learns nothing.
- Lessons as slogans ("strengthen communication"). A rule says when and what to do.
- Blame. It ends honest discussion at the next retrospective.
Example Trigger Phrases
- "Help me do a 复盘 of the Double 11 campaign."
- "The project was delayed; help me write a 复盘 report."
- "How do you run a 复盘 meeting? Give me an agenda."
- "Run a fupan on our product launch, in Chinese."