# Run a regular product review

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-review/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-review/index.md
- **Module:** Retention
- **Time:** 60 minutes for the first 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.

## Outcome

A one-page review record with product health, three changes from the period, one key conclusion, and up to three owned decisions.

## The meeting exists to shrink the task list

In a single period the team may ship a release, change onboarding, and launch messages. The review answers: what happened to the user experience, which change could have caused it, and what we check next. The outcome is decisions, not a stack of slides.

## What you will need

- **Participants:** The product manager, an analyst or data owner, a technical representative, support, and a communications specialist.
- **One screen:** 5–7 indicators for quality, the first useful journey, retention, support requests, and communications over time.
- **Rhythm:** Weekly for a fast-changing product or monthly for a stable one; the same comparison period every time.

## Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

## 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.

## 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**
  - **Source:** Show the crash-free rate, first-journey conversion, FTD, D1/D7, support requests, and message response next to the previous period.
  - **If access is unavailable:** Without a single dashboard, collect seven numbers in a table and note the source, period, and owner of each.
- **Changelog**
  - **Source:** Write down the period's three main releases, experiments, or communications with dates and the expected effect.
  - **If access is unavailable:** If no log was kept, reconstruct the changes from tasks, store versions, and the send calendar.
- **Live signals**
  - **Source:** Add three recurring support or review themes and one concrete example of a user journey.
  - **If access is unavailable:** Ask support to pick five representative requests in advance instead of the general impression that “complaints are up.”

## Run a product review in 60 minutes

1. **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.
   - **Example:** Crash-free 99.6%, unchanged; first useful outcome +8 p.p.; D7 unchanged; status questions +40%.
2. **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.
   - **Example:** June 3 — onboarding shortened; June 7 — new status screen shipped; June 10 — push route changed.
3. **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.
   - **Example:** 12 users ask whether their transaction went through, although there is no technical error.
4. **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.
   - **Example:** The new screen works technically but does not explain the status — that creates requests and mistrust.
5. **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.
   - **Example:** Add the status — Anna — June 21 — requests on the theme and action completion.

## 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.

## Finished artifact: 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.

## Meeting checklist

Do not start the meeting until the data and changes are collected: the group's time should go to decisions.

- [ ] One screen shows 5–7 indicators with trends and a single period.
- [ ] The period's three main changes and their expected effect are named.
- [ ] Support brought recurring themes and concrete examples.
- [ ] One main conclusion is stated without unconfirmed causality.
- [ ] No more than three decisions are made, each with an owner, deadline, and check metric.

## 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.

## Key rule

A good product review shrinks the task list and leaves the team with a few decisions whose effect can be checked.

---

- [HTML version](https://playbook.affpartners.io/en/practices/retention-review/index.html)
- [All practices](https://playbook.affpartners.io/en/)