What is lifecycle marketing, and where teams get it wrong

Lifecycle marketing is deciding what to change next for the people who already use your product, and then changing it. Most definitions cover only the second half, which is how a lifecycle programme — every trigger, series and regular send a product runs — ends up as a calendar nobody in the company can explain.

In almost every programme I have inherited there was a trigger that had been firing since before anyone currently on the team joined. Built by someone who left. Still sending. Nobody turned it off, because nobody could say what it would break.

Fourteen years of this, across streaming, gaming marketplaces, edtech, job boards and fitness. The products had nothing to do with each other. The programmes failed the same way.

What it is not

The schedule is not it. A welcome series, a win-back, a monthly digest — those are outputs, and any competent marketer can have all three running by Friday. Plenty of teams do have all three running while retention slides.

Neither is the funnel diagram. Awareness, activation, retention, revenue, referral is a fine way to explain the shape of a business to someone outside it, and no help at all on Monday morning. Redrawing the stages has never fixed anything.

It also does not belong to email, though email usually gets the blame. Email is the cheapest channel and therefore the default one, so it inherits problems it cannot reach: a pricing page that confuses people, an app that asks for a card before showing anything, a retry schedule set once and never looked at again.

The unit of work is a hypothesis

The difference shows up in what a team asks itself at the start of the month. Usually the question is which sends are going out. The version that works is longer and less comfortable: what do we believe about these people, how would we find out we are wrong, and what would we change if we were?

A campaign ends at the send. A hypothesis is not finished until you know whether it was right — which means a number attached before it starts and a written answer afterwards, including when the answer is that nothing happened.

Most of what gets called a lifecycle programme contains no hypotheses at all. It contains a content calendar, a set of triggers with no owner, and a monthly report where open rate moves up and down for reasons nobody looks into.

The order that works

Find where it actually leaks. "Retention is down" is a symptom, and treating a symptom directly produces the send-more-emails reflex. Compare cohorts against each other until you can name a step — the second month, the third message of onboarding, the renewal that fails without telling anyone. A leak you can point at is a leak somebody can fix.

Ask why before you ask what to send. Teams skip this, and skipping it is exactly what produces the calendar. People who leave in month two and people who leave in month nine are leaving for unrelated reasons, and one message will not speak to both. Make the question narrow enough that it can come back wrong: not why do people churn, but what did the ones who left in month two do differently in their first week.

Then decide the change. The channel comes last. Sometimes the answer really is an email. Often it is a push two hours earlier, a different default in the product, a billing retry moved up by three days, or a screen that stops asking for something the person does not have yet. Picking the channel first is how a product problem gets a communications answer and stays unsolved for another quarter.

Measure against something honest. Convenient baselines flatter whatever you just shipped. People who opened the email retained better — they also retained better before the email existed, because opening is a symptom of intent rather than a cause of loyalty. If a change is worth three weeks of building, it is worth withholding from a random slice to find out whether it did anything.

Write down what happened. Failures especially. This step gets dropped first and costs the most, because without it the same test gets run again in eighteen months by somebody new who has no way of knowing.

Where it breaks

Starting at the channel is the most common one. "We need a welcome series" is not a hypothesis, it is a purchase order. It might even be the right thing to build. You will not know, and three weeks will be gone either way.

Then there is the habit of counting billing failures as churn. In the subscription products I have worked on, a serious share of what got reported as people leaving was cards that expired and payments that bounced. Those people made no decision. They received win-back campaigns asking why they were unhappy, which is useless and faintly insulting, when what they needed was a retry schedule and a working card-update link. Fixing the billing side is usually the cheapest retention work available in the whole company, and it almost never sits with the person who owns retention.

Treating engagement as the goal is subtler. Opens and clicks are diagnostics — they tell you whether a message worked as a message, and nothing about whether it changed behaviour. Optimising them directly ends somewhere unpleasant: subject lines that earn the open and spend the trust, a frequency that lifts total clicks while quietly burning the list underneath.

That list, by the way, is the number nobody watches. Not its size — the ratio between how many contacts you remove each month and how many you add. Once removal catches up with acquisition, every metric shaped like a rate keeps looking fine while the absolute numbers fall.

The last one is the most expensive and the hardest to see. Teams keep a folder of campaigns and no record of reasoning. Which tests ran, what came back, what it meant — gone with the last person who did the job. Nothing breaks when this happens. The work just gets done again.

What it looks like on an ordinary Tuesday

Less glamorous than the frameworks suggest.

You pull the numbers for the segment you were suspicious about last week. Most weeks they say nothing. Occasionally one cohort behaves differently enough to be worth an hour, and that hour is the job. Then you spend a second hour deciding whether the difference is real or an artefact of how you built the cohort, and it usually turns out to be an artefact.

When it is real, you write down what you think is causing it, what you would change, and what you expect to happen. Then you build the smallest version of that change that could still work, and you resist the urge to make it bigger.

Assembling the numbers takes most of the week. Deciding takes an hour. That ratio is the real problem with this discipline, and it is why so much lifecycle work never gets past keeping the existing thing alive.

If you are starting from nothing

The instinct is to gather everyone in a room and draw the journey map. A map built that way is a document about your assumptions, and it will be wrong in precisely the places that matter.

Build it out of behaviour instead. Collect the paths people actually take, lay them out in the order things happen, and mark where one action leads to the next. The triggers fall out of that graph on their own — they are the moves between states, not the boxes. Start with one question you cannot currently answer, usually some version of where do people go after this, and the map assembles itself while you answer it.

---

I am building RecurForge because of the ratio in that Tuesday paragraph. The deciding is the part worth paying someone for, and the assembling eats the week. If that is your week too, the form below is the only thing on this site that does anything yet — leave an address and I will write when there is something to show.