Choosing which lifecycle programs to build first

Three factors. Revenue leak, executability, provability. The right build order optimises all three at once. In practice that's rarely the program you were planning to build, which is the whole reason this guide exists.

Revenue leak — money walking past your current lifecycle stack every week that a new program would catch. The bigger the puddle on the floor, the higher the priority.
Executability — does your ESP, your data pipeline, your content team, and your stakeholder bandwidth actually support shipping this well? A program you can't execute is worse than no program. It just looks like one on the org chart.
Provability— when you ship it, can you run a holdout — a randomly held-out group you don't message, used as the control — and know if it actually worked? Programs you can't measure become political footballs the first time a CFO asks "what did this do?"

An ecom retailer and a SaaS product don't lose money in the same way, and treating them the same way is how lifecycle teams end up shipping the wrong program first. The #1 program for an online store is often not even top three for a subscription product. Start from your actual business model — how customers find you, pay you, and stop paying you — not from someone else's program inventory.

Team size doesn't change which program leaks the most revenue. It changes how many programs you can build at once without one of them quietly rotting.

Solo operator (lifecycle of one).You can't build and run five programs in parallel. Build one. Make it great. Ship the next one when the first is actually generating measurable revenue and is resilient to a week of you being away. The temptation is to stand up thin versions of three programs at once. The result is three programs that all underperform a single program done properly.

Two-to-three-person team.Two programs in parallel, a third building in the background. The limit isn't sending capacity — ESPs handle volume fine — it's QA, iteration, and post-launch measurement. Every program you ship adds a maintenance tax. Underestimate that tax and your "launched" programs quietly decay, which is somehow worse than not having them.

Four-plus team with a specialist.Now you can build programs in parallel and invest in shared infrastructure (templates, Liquid libraries — Liquid is the templating language ESPs use to inject personalised values like a first name into emails — automated test rigs). The frame doesn't change. Revenue leak × executability × provability still picks the order. A larger team just loosens the executability constraint. You still don't ship a program you can't prove worked.

The Lifecycle Audit skill exists for exactly this situation: walk into a new company and quickly size up what's in place, what's leaking, and what the ROI-ordered build queue should look like.

Every program has a data prerequisite. Skip it and the program technically ships but fires off wrong signals — emailing people who already bought, sunsetting users who are still active, recommending products from a category they don't shop. The classic version: a cart program that confidently nags people about a basket they checked out twenty minutes ago, because nobody wired up the "purchased" event to stop the flow.

Cart abandonment.Needs clean cart events flowing into your ESP or CDP — customer data platform, the layer that unifies behaviour from your site, app, and order system — with item-level data (name, image, price, URL). Needs a reliable "purchased" event to stop the flow. Without both, your cart program will fire at people who already bought, and you'll burn list credibility fast.

Win-back.Needs a reliable "last meaningful activity" timestamp. Most ESPs default to "last email open" — but Apple MPP (Mail Privacy Protection — Apple pre-fetches emails for users on Apple Mail, which makes opens basically meaningless) corrupted that signal in 2021 and most teams haven't adjusted. You need a behavioural signal: last purchase, last app open, last active session. Run win-back off open data alone and you'll sunset engaged users who happen to read on iOS.

Post-purchase / replenishment.Needs order data in the ESP with items, amounts, and dates. Replenishment specifically needs repeat-purchase interval data — the typical gap between buying the same thing twice. If you don't know the typical cycle, the replenishment send goes out on vibes, and it shows.

Welcome. The lowest data bar in the business. You need the signup event. That's it. Which is exactly why welcome gets built first everywhere — least friction to ship, fastest to demo, easiest to brief a designer on. Fine, but don't confuse "easiest to build" with "highest priority." For ecom, welcome often isn't in the top three. Custom attribute design

A few programs operators are constantly asked to build where waiting is the right call, and saying so out loud is part of the gig.

Birthday and anniversary emails. Beloved by CEOs, barely move the needle in measurable terms. They need a data point most signups don't willingly hand over (their actual birthday), the daily send volume is too thin to meaningfully impact revenue, and the incremental lift is rarely above noise. Build these last, if at all, and certainly not before your cart program. Honest assessment

SMS before email is solid. SMS — text-message sends, billed per message — is a powerful channel, and it compounds whatever email habits you've built. Bad cadence in email becomes worse cadence in SMS, just faster and more expensive per send. Adding SMS before your email lifecycle is measurable adds complexity you can't diagnose. Solid email first, then layer SMS into the moments with the highest revenue per send. SMS playbook

Loyalty and referral programs pre-scale. These are scale plays. They work when you have enough volume that even small referral rates produce meaningful new users. Build them too early and you produce a beautiful program with 40 enrolments and zero economic impact — operationally expensive to run, embarrassingly small in the dashboard. Wait until you have an audience that can move the needle on word of mouth.

"AI personalisation" without a measurement baseline.The pitch is compelling. AI personalisation needs a clean baseline to beat, a long enough test window, and a holdout — and all three require the foundational lifecycle measurement to be in place first. Bolting AI personalisation onto an unmeasured email program just makes the unmeasurement more expensive. Skip the foundation and you've bought a faster way to fail.

A pragmatic quarter-long build queue for a new CRM lead at a typical mid-size ecom or SaaS company. Week ranges, not promises — every company has its own dragons.

Weeks 1-2 — audit and baseline. Don't ship anything yet. Inventory what's already running, what the ESP and data will support, and establish the metrics baseline so future work has something concrete to beat. The lifecycle audit checklist walks the full sweep.

Then weeks 3-5 — ship program #1. Pick the program with the biggest revenue leak for your business type, using the framework above. Ship it with a holdout from the first send so you can measure incrementality — the lift the program causes, separate from what would have happened anyway — honestly. Holdout group design

Across weeks 6-8 — measure and iterate. Let the holdout data accumulate. Iterate creative, segment, and cadence based on what the numbers say, not on what was on the brief. Every program takes 4-6 weeks to produce trustworthy data. Shipping the next one before this one has been measured is how lifecycle teams end up with a dozen half-working programs and no idea which ones to turn off.

Finally weeks 9-12 — program #2 plus infrastructure.Second-biggest revenue leak gets the next program. Alongside it, invest in reusable infrastructure: template library, Liquid snippets, naming conventions, segmentation patterns. Payoff on infra doesn't show up in program #2 — it shows up in #3 and every program after that, where the build cost halves because the rails already exist.

You've got the queue. Here are the canonical program playbooks in roughly the order you'll need them.

Start with onboarding email flows for building the welcome and activation sequence properly, then move into abandoned cart emails — the cart recovery playbook — followed by win-back flows for reactivation sequencing.

When you're ready to push deeper, post-purchase emails covers turning one-time into repeat, holdout group design shows how to measure any of this honestly, personalisation not creepy covers when to crank the dial and when to dial back, and lifecycle metrics dashboard walks proving impact to the rest of the business.