Implementation worksheet · 6 min read
A Weekly Lifecycle Optimization Review Agenda
Run 45 minutes in five fixed blocks: health first (anything broken or harming customers), then running experiments (status only), last week's launches, decisions, and next week's queue. A pre-read generated the day before carries the numbers, so the meeting spends its time on exceptions. The rule that keeps it honest: an experiment is read only on the readout date set before it launched. Checking significance every week and stopping on a good week makes a false positive more likely than the nominal rate, and Johari and colleagues call p-values 'wholly unreliable' when sample size is chosen by continuous monitoring. Every decision leaves the room as a logged entry with an owner and a date.
Scope: the lifecycle lead who chairs a weekly review with an analyst, someone who can change journeys, and the deliverability or compliance owner when a health item is open. Starting state: live journeys, dashboards, and a meeting that has drifted into status updates. Boundary: one team's lifecycle programs at a weekly cadence; quarterly planning is separate. Intended outcome: a decision log that grows every week, and no experiment read before its time.
Put it into practice
1. Generate the pre-read, not a slide deck
One page, produced automatically the day before: for each live journey, weekly entries, sends, delivery failures, unsubscribes and complaints, and its primary outcome against its own trailing four weeks. Anything outside a threshold set in advance is highlighted. People read it before the meeting, and the meeting discusses only the highlights.
2. Open with health, against written thresholds
Ten minutes on what is broken or harming customers: a journey with zero entries for a week, a spike in delivery failures, complaints above your alert. Gmail's sender guidelines require everyone sending to Gmail accounts to keep the spam rate reported in Postmaster Tools below 0.3% (as of September 2026); put your internal alert well under that ceiling, not at it. Every health item leaves with a named fixer.
3. Review experiments for status, not results
For each running test: sample collected against plan, a check that the observed split matches the intended one, the readout date, and any guardrail breach. That's all. The only early stop is for harm, on a guardrail defined before launch. Results are discussed once, at the readout.
4. Treat last week's launches as smoke tests
What went live, whether it entered the expected number of people, whether anything broke. A first-week conversion number for a change without a holdout is not a verdict, and discussing it as one is how the meeting starts arguing about noise.
5. Decide rather than discuss
Each proposal arrives written: the change, the evidence, the cost and the reversal plan. It leaves as ship, kill or park, with an owner and a date, in the decision log. A proposal without a written version waits a week.
6. Pull next week's queue from the prioritization worksheet
Five minutes on the top items that can start next week, and who owns each. The ranking itself happens in the worksheet beforehand, not live in the room.
7. Worked example (illustrative, synthetic)
The pre-read shows the trial day-3 nudge with zero entries since Tuesday: a product release renamed its trigger event. In the health block, the engineer who owns the event contract fixes the mapping, and the lifecycle marketer decides whether the users who were missed should still get the nudge or be let go. A win-back subject-line test is at 62% of its planned sample, the split check passes and the readout is on the 19th, so its results are not discussed. A proposal to add SMS to cart abandonment is parked until the consent records are audited.
Weekly review agenda
Copy this structure into your review document and record your observed result for each row.
| Block | Minutes | Input | Question answered | Output |
|---|---|---|---|---|
| Pre-read | 0 (read beforehand) | Auto-generated one-page snapshot | What is outside its threshold? | Highlights that set the agenda |
| Health | 10 | Entries, sends, failures, complaints, unsubscribes | Is anything broken or harming customers? | Fix tickets with named owners |
| Experiments | 10 | Sample progress, split check, readout date, guardrails | Is each test running as designed? | On track, investigate, or stop for harm |
| Last week's launches | 10 | Change log since the previous review | Did anything break at launch? | Smoke-test notes, no verdicts |
| Decisions | 10 | Written proposals with evidence and a reversal plan | Ship, kill or park? | Decision log entries with owner and date |
| Queue | 5 | Top of the prioritization worksheet | What starts next week? | Up to three named items |
| Readouts | Only on scheduled dates | The analysis defined before launch | What did the test show? | A result entry in the team's learning record |
A failure worth checking
The Tuesday winner. In week two of a planned five-week test, the review sees the new variant ahead with p = 0.03 and ships it. Nobody records that the readout was brought forward. A quarter later a rerun finds no difference. The early look didn't break the arithmetic; the decision rule did, because checking every week and stopping at the first good one gives chance several opportunities to cross the line instead of one. Verification: flag in the decision log every test stopped before its readout date, and compare those effects with reruns or with tests that ran their full length.
Common questions
Who should attend?
The lifecycle lead as chair, an analyst, someone with permission to change journeys, and the deliverability or compliance owner when a health item is open. Adding more people tends to turn the decisions block back into a status meeting.
What if there's nothing to decide this week?
Skip the decisions block, never the health block. If three weeks pass without a decision, the meeting has become a status update; shrink it to the health check and a written summary.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.