Post-launch review: measuring what shipped and learning from it
A post-launch review compares what shipped with the goal set beforehand. Learn when to run it, what to measure, and how to close it with owned actions.
What is a post-launch review?
It closes a loop many teams leave open. The team ships, celebrates, and moves on without knowing whether the feature did its job. The review exists to answer two questions: did what we shipped work, and what will we do differently next time?
Two parts are worth separating. The first is measurement: what happened to users and the business. The second is the retrospective: what happened to the process, the decisions, and the collaboration.
When should you run it?
The guides do not agree on one universal timing, so adapt it to the type of change. Rational PM suggests measuring for at least four weeks on updates that do not require customers to act: in the first week, look at early adoption; in weeks two and three, feedback and how usage stabilizes; and in week four, a prediction against the target. If the launch requires customers to upgrade, follow-up can last months.
A practical point: do not wait until the end to think about the review. Set the date before launch and put it on the team calendar.
What should you compare against?
The most important thing is the goal defined before shipping. Rational PM uses week four to predict whether the target will be hit, and suggests measuring stickiness metrics such as the ratio of daily to monthly active users (DAU/MAU).
A useful goal reads like this: “we expect registration completion to rise from X to Y within six weeks, without hurting retention.” It has one metric, a concrete change, and a timeframe, and it also watches for harm to another key metric.
If you have no baseline, the review becomes a story. That is why you should capture current data before launch, not after.
| What to measure | Why |
|---|---|
| Adoption | How many people use the feature, and how often |
| Target metric | Whether it moved in the expected direction and amount |
| Health metrics | Whether the change hurt something important (retention, support volume) |
| Feedback | What users say, with numbers and with interviews |
Product-Led Alliance’s template lists acquisition, revenue, engagement, and retention among its indicators, and asks you to analyze product reception and assign owners and dates to action items. You define the targets and baselines.
How do you run the retrospective?
Rational PM proposes questions that work well in the session: what went well, were the requirements clear, was the schedule reasonable, did supporting teams have what they needed, were there surprises, and where were the bottlenecks? And at the end: was the launch successful?
The retrospective is about understanding the process, not hunting for culprits. If the conversation turns into a search for someone to blame, people will stop telling the truth in the next one.
How do you close with actions?
Every finding should become an action with an owner and a date. A list of “learnings” without owners changes nothing.
A simple format:
- Action: what we will change.
- Owner: one person, not a team.
- Date: when it will be checked.
- Where it lives: in the next project, not in a forgotten document.
Rational PM stresses applying the conclusions to the next project and recommends sharing the lessons learned across the company. The second matters: a review nobody else reads does not reduce the cost of repeated mistakes.
When is a formal review overkill?
If the change was minor, reversible, and did not affect important metrics, a long review is not justified. A three-line note saying what shipped, what happened, and what changed is enough.
Be careful about copying incident formats, too. Google’s SRE guidance describes postmortems with clear triggers and a blameless approach, but it is written for system failures. Adapt it to a feature launch rather than transplanting it as is.
Example
Illustrative example: a team launched a new search filter in an online store. The goal was to cut the clicks needed to reach a product by 20%. Four weeks later, adoption is high, but clicks dropped only 8%. Reviewing the feedback, the team finds that users do not understand the difference between “brand” and “category”. The action is clear: the design team rewrites the labels, the feature’s designer owns the change, and the next measurement date is set. The review did not say the filter failed; it identified a specific comprehension problem.
Common mistakes
- Not defining the goal before launch, and then choosing whichever metric did improve.
- Not capturing a baseline, which makes it impossible to know whether the change was responsible.
- Measuring success only, and ignoring health metrics that might have worsened.
- Running the retrospective with culprits and losing the team’s candor.
- Leaving actions without owners, so nobody carries them out.
- Never closing the review, with a meeting that has no conclusion or document.
To decide which metrics to keep watching after launch, KPIs help you choose what to look at, and DesignOps metrics help you measure the team’s own work. If the launch came from a hypothesis, concept testing is a way to validate it before investing. And for the full design process, the UX design process shows where the review fits.