Practice 02.05 · Retention
Run a regular product review
A product review is not a meeting for presenting every number. The team connects changes to outcomes and chooses no more than three next decisions.
60 minutes for the first review
In plain language
The meeting exists to shrink the task list
What you will need
01
When to use it
The team ships changes but never returns to their effect; meetings become a numbers report, and the task list only grows.
In plain language
What to prepare before the meeting
Do not collect dozens of dashboards. Bring only the data, changes, and live signals needed for this period's decisions.
Health screen
Show the crash-free rate, first-journey conversion, FTD, D1/D7, support requests, and message response next to the previous period.
Without a single dashboard, collect seven numbers in a table and note the source, period, and owner of each.Changelog
Write down the period's three main releases, experiments, or communications with dates and the expected effect.
If no log was kept, reconstruct the changes from tasks, store versions, and the send calendar.Live signals
Add three recurring support or review themes and one concrete example of a user journey.
Ask support to pick five representative requests in advance instead of the general impression that “complaints are up.”02
Run a product review in 60 minutes
Show the product's health
Start with 5–7 indicators over time and flag only meaningful changes. Do not discuss every number in turn.
- Where to do it
- On one screen with the period, sources, and previous values.
- What the result looks like
- Crash-free 99.6%, unchanged; first useful outcome +8 p.p.; D7 unchanged; status questions +40%.
Put the changes next to the signals
Name the three main releases or communications with dates and the expected effect. Do not assign causality without a check.
- Where to do it
- In the second column of the record.
- What the result looks like
- June 3 — onboarding shortened; June 7 — new status screen shipped; June 10 — push route changed.
Add the user's voice
Show recurring questions and one typical journey. A qualitative signal helps explain what hides behind the metric.
- Where to do it
- Next to the matching indicator.
- What the result looks like
- 12 users ask whether their transaction went through, although there is no technical error.
Choose one main conclusion
State the problem or opportunity in one sentence. Do not blend quality, retention, and growth into one vague theme.
- Where to do it
- In a visible block before the decisions.
- What the result looks like
- The new screen works technically but does not explain the status — that creates requests and mistrust.
Cap the decisions at three
Each decision needs an owner, a deadline, and a signal to check at the next review. Explicitly set the other ideas aside.
- Where to do it
- In the last column of the record and the task list.
- What the result looks like
- Add the status — Anna — June 21 — requests on the theme and action completion.
03
Practical examples
A signal becomes a decision
After the new screen the technical indicators are stable, but status questions grew 40%. The conclusion — the process is unclear; the decision — add the status, an owner, and a request check.
Three decisions instead of twenty ideas
The team fixes the push route, explains the transaction status, and checks the next cohort. The remaining ideas are explicitly parked until the next review.
Product review record
Do not transcribe the whole discussion. Record the signal, its link to a change, and a decision that can be checked.
| Signal | What changed | Conclusion | Decision and owner |
|---|---|---|---|
| Crash-free stable | Release 4.3 | No technical regression | Observe · mobile team |
| First useful outcome +8 p.p. | Shorter onboarding | The change helps | Extend to Android · product |
| D7 flat | New journey live for 2 weeks | The effect has not arrived yet | Check the next cohort · analyst |
| Status questions +40% | New transaction screen | An explanation is missing | Add the status · design + support |
| Pushes opened, action flat | Generic deep link | Context is lost | Fix the route · communications |
Focus of the period: explain the transaction status. No more than three decisions: fix the route, update the status copy, check the next cohort. Everything else stays out of the plan until the next review.
04
Meeting checklist
Do not start the meeting until the data and changes are collected: the group's time should go to decisions.
05
How to know the review works
Decisions completed
The next meeting starts from the previous agreements and their actual results.
Focus kept
No more than three agreed actions are in progress, and new ideas do not displace them without cause.
Experience improves
The chosen quality, retention, or trust signals move after the decisions are done.
A good product review shrinks the task list and leaves the team with a few decisions whose effect can be checked.