Pmg Run Post Launch Review

---
name: pmg-run-post-launch-review
description: Runs an after-action review of one launch, setting what was intended against what actually happened, with the reasons, a keep and change list and a keep, fix or remove call on the feature. Use for "run pmg-run-post-launch-review", "post-launch review", "launch retrospective", "did the feature work", "nobody is using the new feature", "keep, fix or remove", "after-action review", "review the release", part of The Complete Claude Guide for Product Managers Pack by Polar Bear.
---

# Run the Post-Launch Review

## When To Use
Two weeks after launch, customers still use the old workflow. Or the release went out, the team moved on, and nobody has asked whether it did what it was for. This answers one question: given what customers actually did, do we keep this feature, fix it or remove it?

## When Not To Use
If the launch has not happened yet and you want to find what could go wrong, run Run the Pre-Mortem. If the question is how the team worked during the cycle rather than what the launch did, run Run the Retro. If nobody defined success before launch, run Set the Success Metrics first and date it honestly as after the fact.

## Inputs
- What was intended: the PRD goals, the success metrics or the experiment plan
- What happened: a usage export or dashboard summary, in aggregate, with its period
- Customer evidence: support tickets, interview notes or feedback, summarised as needs
If you have none of this, I start from the release description and mark the output as a first draft, with "actual" left open until data or customer evidence is in.

## Approach
The after-action review as set out in USAID's "After-Action Review Technical Guidance" (2006): four questions, asked in order, in a session about learning, not critique or complaint. The judgment: compare against what was written before launch, not what people now remember intending. The failure it prevents is the review that turns into blame, or into praise with no change, while the old workflow keeps winning.

## Workflow
1. Ask three questions: where the intended outcome is written down, which usage and customer evidence you have and for what period, and who makes the keep, fix or remove call.
2. What was expected to happen: copy the goals, metrics, targets and guardrails from the PRD, success metrics or experiment plan. If none were written, say so and use the release brief, marked as reconstructed.
3. What actually happened: fill each line from the user's data and customer evidence only, in aggregate, with its period. Where data is missing, leave the gap and name the role that could get it.
4. What went well, and why: the causes that held, in terms of product, process and assumptions.
5. What can be improved, and how: each gap between intended and actual with a likely cause. Check the usual ones: customers never found it, the old workflow is still easier, the job was different from the one assumed, or the metric measured something else. A cause is never a person.
6. Turn the answers into a keep and change list: each item a concrete change to the product, the process or the next spec, with an owning role and a date.
7. Draft the keep, fix and remove options, each with evidence for and against, and list what goes back to discovery. The review recommends; the decider makes the call.

## Output Format
```markdown
# Post-Launch Review
Feature: [name] | Launched: [date] | Review period: [dates] | Facilitator: [role] | Decider: [role]
## Intended Versus Actual
| Goal or metric | Intended (source) | Actual (period, source) | Gap |
|---|---|---|---|
| [metric] | [target from success metrics] | [from your data, or "missing"] | [difference or "unknown"] |
## Customer Evidence
- [Need or behaviour observed] | [source: tickets, interviews, feedback] | [how many, from your data]
## Went Well And Why / To Improve And How
- Well: [what held] | [cause: product, process or assumption]
- Improve: [gap] | [likely cause] | [evidence]
## Keep And Change List
| Item | Keep or change | Owning role | By |
|---|---|---|---|
| [item] | [keep / change] | [role] | [date] |
## Options
- Keep: [evidence for] / [evidence against]
- Fix: [evidence for] / [evidence against]
- Remove: [evidence for] / [evidence against]
## Decision
[The [head of product] makes the keep, fix or remove call by [date]; changes go to the next planning cycle on [date]; [open questions] go back to customers.]
```

## Done When
- Every "intended" line cites a document written before launch, or is marked reconstructed
- Every "actual" line cites data or customer evidence, or reads "missing"
- No cause names a person; each keep and change item has an owning role and a date

## Quality Bar
- Four questions, in order; skipping to "what went wrong" turns a review into a complaint session. Praise without a change fails it too.
- Usage data stays in aggregate: no per-user timelines, no scoring of users or team members, small groups suppressed at the minimum the user sets.
- No invented usage figures, quotes or findings; gaps stay in brackets.
- Customers' actual behaviour decides the review; a named person makes the keep, fix or remove call.

## Next
Run pmg-prepare-interview-guide (Prepare the Customer Interview Guide) to take what was learned back to customers.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).