Quarterly planning for lifecycle: what actually goes in the plan

A calendar answers "what are we sending, when". A plan answers "what are we trying to achieve, what's in the way, what specifically will we do about it". One of these survives a changing quarter. The other is a wall decoration.

Most lifecycle teams drift into calendars because calendars feel productive. You can fill them in. You can show a stakeholder a grid of campaigns and look organised. The trouble: the calendar doesn't help the team decide which of 20 possible campaigns actually matters. The plan does. If you've never had to defend why one campaign got built and another didn't, you've probably been working off a calendar.

Two pages. Five sections. That's the whole shape. Walk through them in order — each one earns its keep by answering a question the next section depends on.

Section 1: Where we are. One page of current state — the diagnostic before the prescription. Active audience size, revenue per send, complaint rate (the percentage of recipients who hit "mark as spam"), 30-day retention, deliverability health (whether your emails are landing in the inbox or spam). Compared to last quarter. What moved. What didn't. What's concerning. Without this, the priorities have nothing to anchor to.

Section 2: The three priorities for the quarter. Not ten. Not thirty. Three. Each priority is stated as a metric-level goal, not an activity. "Lift trial-to-paid conversion from 12% to 15%" is a priority. "Ship a trial email flow" is an activity. The distinction matters: goals survive activity pivots, activities don't. If the welcome flow you planned turns out to be the wrong intervention, the goal is still the goal — you swap the activity, not the target.

Section 3: For each priority, the plan. Three to five specific investments per priority. These are the activities — ship the trial flow, run the welcome test, improve the product reminder. Every activity maps to a priority it serves. Anything that doesn't map is a distraction dressed up as work, and you can tell by reading the document.

Section 4: What we're explicitly not doing. Five to ten things that will come up during the quarter and are NOT on the plan — requests from other teams, tempting campaign ideas below the priority bar, low-value maintenance work. Documenting the no-list stops you re-litigating it every time someone walks over with a "quick favour". The no-list is doing as much load-bearing work as the yes-list.

Section 5: What we'll learn regardless. Two to three experiments — controlled tests on your own list — that produce insight whether they "win" or not. Separate from the priorities. Learning investments. "Test whether send-time optimisation produces real lift on our list" is the shape. The point isn't to win the test, it's to know something next quarter you don't know now.

Most programs have more priority candidates than capacity. Everyone wants to fix everything. Three filters narrow the field, applied in this order — and yes, the order matters, because a candidate that fails any of them isn't actually a viable priority.

1. Evidence of room to move. Prior cohort analysis (looking at how groups of users behave over time), benchmark gaps, or experimental data showing real headroom. A priority backed by "we ran a test and saw a lift here" is sharper than one backed by "it feels like we should work on this". Feelings are a starting point, not a plan.

2. Team capacity. Honest estimate of engineering, design, copy, and data-science hours needed. Without capacity to execute, the priority is a fantasy. Requiring 400 hours from a team with 200 available is also a fantasy, dressed up in a spreadsheet. Do the math before you fall in love with the idea.

3. Dependency readiness. External teams or data availability the priority depends on. A retention priority that needs product telemetry — the in-app behavioural events you'd use to trigger re-engagement — that the product team is three months away from shipping is blocked. Pick something else.

Headroom plus capacity plus dependency-readiness usually leaves three to five candidates. Pick three. Rank the rest as contingent backups so you have a warm bench when something inevitably falls through. Something always falls through.

Plans are only useful if revisited. Write it once, never look at it again, and you might as well have written a calendar. Three rhythms keep it breathing:

Weekly: short check-in on activities against each priority. On track?

Monthly: broader review. Are the priorities still the right priorities? Has something shifted — competitor move, product change, data surprise?

End of quarter: retrospective. Did we move the metrics? What did we learn? What goes in the next plan?

One last thing on planning itself: it takes time. One to two weeks of concentrated work, not a single afternoon meeting. The work is cohort analysis to identify where the headroom sits, capacity math, and stakeholder alignment on priorities. Writing the document takes a few hours. The thinking takes two weeks. Compress it into an afternoon and you'll spend the rest of the quarter wondering why the plan didn't survive contact with February.

If you've done this before, some of these will sting. Good. They're the patterns that turn a useful document into a wall decoration:

Too many priorities. "Our three priorities" followed by a list of seven. Pick three. Everything else goes in Section 4, the no-list.

Priorities written as activities, not goals. "Ship the welcome flow" is an activity. "Lift week-1 activation from 30% to 38%" is a goal. The first dies the moment scope changes. The second outlasts whatever activity you ship in service of it.

No capacity math. Be honest about hours. Cut priorities until the math actually works. A plan that doesn't clear the capacity check becomes a plan to fail on three things instead of succeed on two.

No trade-offs documented. Saying yes to three things without saying no to anything isn't a plan. When it says yes to X and no to Y, it's a real plan. When it only lists yeses, it's a wish list with a header.

On stakeholder involvement: yes, share the plan outside the lifecycle team. It's the alignment artefact — the document that tells brand, product, sales, and exec what lifecycle is prioritising. Walk them through it. Get explicit agreement on the priorities and the no-list. This is how you avoid the week-six "why aren't you doing X" meeting, the one that wastes an afternoon every time it happens.

When something major lands mid-quarter that wasn't in the plan, decide explicitly. Does it replace one of the three priorities? Or does it get added to the not-doing list? Don't silently add and hope the team handles everything. If it truly replaces, re-plan. If it doesn't, defer to next quarter and move on.

includes quarterly plan production as a default output. Forcing the trade-offs is how the plan earns its keep — and "what we're not doing" is doing as much work as "what we are".