I think a lot of growth teams are better at writing prompts than retiring them.
We spend time on subject lines.
We tighten the CTA.
We debate send time.
We A B test the sequence.
We add one more reminder because the conversion curve still looks like it might move.
Then the user learns a different lesson than the one we intended.
Not this is useful.
This thing keeps asking.
That is a product problem, not only a channel problem.
When a product keeps prompting after the user has lost the conditions for action, the message does not stay neutral.
It starts teaching disregard.
I think a lot about this in growth work because lifecycle systems are often judged by whether they produce motion at the margin.
Did the open rate hold up.
Did clickthrough tick upward.
Did reactivation nudge the cohort.
Those questions matter.
The missing question is usually simpler.
When should this prompt stop.
Good prompts have an expiry condition
BJ Fogg’s Behavior Model is still one of the cleanest ways to think about this. A prompt works when motivation, ability, and the prompt arrive together.
Growth teams usually obsess over the prompt.
Sometimes we think hard about motivation.
We are less disciplined about ability.
Can the user actually do the thing we are asking right now.
Do they have the missing data.
Has their teammate completed the handoff.
Is the setup truly ready.
Did the prior attempt fail quietly.
If the answer is no, the next reminder is not merely early.
It is badly timed by design.
That is why I think every meaningful lifecycle touch should carry an expiry condition.
Not only what should trigger the message.
What should make the message ineligible.
That sounds operational because it is.
But it is also a form of product judgment.
It asks whether the team respects the difference between a user who needs a nudge and a user who needs the system to stop leaning on them.
Other fields know that repeated alerts teach people what to ignore
Medicine has studied this more honestly than product teams usually do.
The AHRQ Patient Safety Network writeup on alert fatigue is about clinicians, not growth funnels, but the lesson travels well. When people are flooded with alerts that feel low value, poorly timed, or hard to act on, they adapt by tuning them out.
That is not a moral failure.
It is a system response.
Products create the same response all the time.
A reminder to finish onboarding arrives before the integration bug is resolved.
A win-back email asks the user to return to a workspace that still has no content worth returning to.
A trial conversion prompt keeps appearing even though procurement is blocked and the buyer already signaled that timing is the issue.
A collaboration app nags an invitee before the inviter ever configured the workspace well enough for the invite to feel intelligent.
Each of those messages can still produce a few clicks.
That is what makes them dangerous.
The dashboard may show enough local response to justify the sequence while the user is forming a broader habit of dismissal.
I think that is one reason some lifecycle systems look busy and feel weak.
They are optimizing for one more touch after the conditions for persuasion have expired.
Operating systems are stricter about interruption than many growth teams
Apple’s Human Interface Guidelines for notifications make a point that product teams should steal more often. Notifications should deliver timely, relevant information and should not be excessive.
That is obvious in a phone operating system because interruption is expensive.
It should feel just as obvious in growth product work.
Email, push, in app prompts, banners, and modal reminders all spend from the same trust account.
If the message arrives with weak relevance or no actionability, the product is spending trust for the comfort of the sender rather than the progress of the user.
I think teams miss that because notification cost is rarely visible in the experiment readout.
The send happened.
The impression happened.
Maybe a few users converted.
What stayed hidden was the quieter learning effect.
The user updated their mental model from this product helps me keep momentum to this product keeps interrupting after it should know better.
That is not just fatigue.
It is product character.
A lot of lifecycle messaging confuses unresolved state with untapped intent
This is the core mistake.
The system sees an unfinished step and treats it like evidence that more prompting is needed.
But an unfinished step can mean many things.
The user lacks context.
The user lacks authority.
The user lacks confidence.
The workspace lacks setup.
The promised outcome has not become believable yet.
The task has been deferred on purpose.
The user already tried and hit something the event stream does not capture.
Those are very different states.
Only one of them clearly says send another reminder.
The rest call for some combination of better instrumentation, better product support, better teammate handoff, or silence until reality changes.
I think public service teams often show more restraint here.
The GOV.UK pattern for confirmation pages is useful because it pushes teams to confirm what happened, explain what happens next, and give people a record. That is a much healthier default than sending a string of reminders to compensate for an unclear first response.
A lot of products could remove whole reminder sequences if the initial in product confirmation carried more truth.
What did the system receive.
What is blocked.
What is automatic.
What still requires user action.
When should the user expect movement.
Where can they return later.
That is often a better growth move than drafting a cleverer chase email.
Good stop rules are really a form of respect
I do not mean a giant compliance framework.
I mean a small operating rule that says we will not keep asking once these conditions are true.
That rule protects the user from noise.
It also protects the team from self deception.
Without a stop rule, almost every underperforming sequence can make an emotional argument for one more touch.
Maybe they missed the last one.
Maybe tomorrow is better.
Maybe a stronger incentive will unlock them.
Maybe a different channel will work.
Maybe the problem is frequency, not fit.
Sometimes that is true.
A lot of the time the prompt is now doing cleanup work for a product state that still is not ready to earn the next action.
The stop rule forces a cleaner question.
Has the world changed enough that this ask is newly fair.
If not, send less.
Fix more.
The artifact I like is a nudge stop rule
When a team has a noisy lifecycle system and a vague sense that users are getting harder to reach, I like writing a nudge stop rule for one important journey.
Usually an activation sequence, a paywall reminder, an invite acceptance path, or a win-back loop.
The point is not to formalize every email in the company.
The point is to make the eligibility logic visible before the system trains users to ignore it.
Nudge stop rule
- The user action the prompt is trying to unlock
- The evidence that the user still has the ability to take that action
- The evidence that the user still has a reason to care right now
- The states that should immediately suppress further prompts
- The maximum number of touches before the sequence must stand down
- The events that should hand the user to product education, support, sales, or silence instead
- The signals that the underlying blocker is structural rather than motivational
- The quality threshold the product experience should meet before another prompt is allowed
- The downstream harm if the sequence keeps firing after relevance has expired
- Owner
This gets clarifying fast.
You notice where the system has no idea whether the user can act.
You find sequences that assume motivation persists longer than it actually does.
You see places where growth is using messaging to paper over bad state communication.
You also get a better conversation with engineering, lifecycle, and support because the debate stops being should we send more and starts being what condition actually makes another ask fair.
This changes how I think about activation and retention
I still believe in well timed prompts.
Some products absolutely need them.
People are busy.
Value is delayed.
Good work deserves a second chance.
What I trust less is a system that measures prompt success without measuring when credibility runs out.
A healthy growth product does not only know how to call the user back.
It knows when to stop calling and make the return path worth taking.
That is the part I think more teams should treat as craft.
Not messaging harder.
Knowing when the next message would reveal that the product has learned the wrong lesson from silence.
