I think growth teams are often too quick to call a repeated behavior durable while the product is still paying for every repetition.
The reminder keeps arriving.
The credit keeps renewing.
The streak stays protected.
The banner keeps pointing at the next task.
The user keeps moving, so the chart starts to look like a habit.
Maybe it is.
Maybe we have only built a behavior that depends on the machinery we placed around it.
Those are not the same product outcome.
If we want to know whether the product has earned a place in the user’s life, at some point we have to remove the push and see what remains.
Repetition can borrow its strength
Imagine a hypothetical meal-planning product that gives new members a small grocery credit when they publish a plan each Sunday.
For six weeks, planning rises. More people return on Sunday. More lists get created. The team sees higher repeat usage and starts talking about a weekly routine.
Then the credit ends.
Some people keep planning because they discovered that the product makes the week easier. Some stop because the credit was the value. Others still want the outcome but forget without the Sunday reminder.
The same visible behavior was carrying different causes.
That distinction matters because each cause asks for a different product decision.
People who discovered durable value may need very little help. People who depended on a cue may benefit from a user-controlled reminder. People who only wanted the credit may be perfectly rational customers for a subsidized offer and poor evidence for an unsubsidized routine.
The mistake is not using incentives or prompts. The mistake is treating behavior under support as proof of behavior after support.
Other fields test what survives the intervention
Behavioral research is more careful about this boundary than many product dashboards are.
Erin Frey and Todd Rogers describe several ways that effects can persist after an intervention stops. An intervention might help someone build a routine, change how they think, lower a future cost, or create reinforcement that continues elsewhere.
I like that framing because persistence is not one mechanism wearing different clothes.
A product prompt can help a person notice value they would have missed. A discount can make exploration affordable. A checklist can lower the work of getting started. A social feature can create a commitment that outlives the original nudge.
Those are all plausible paths to durable behavior.
They still have to be observed.
Research on incentives for healthy eating makes the measurement move concrete. The study followed behavior during the incentive and after the incentive ended. The point for a growth team is not that school lunch choices map neatly onto software. They do not. The useful move is separating supported behavior from unsupported behavior instead of averaging the two into one success story.
There is another caution here.
Rewards do not all work the same way for every task. A review of experiments on extrinsic rewards and intrinsic motivation found that the type of reward, the expectation of it, and the way it was experienced all mattered. That should make a product team slower to repeat the slogan that rewards either always create habits or always destroy motivation.
The product question is narrower and more useful.
What work was the support doing, and does the user still need that work done when the support disappears.
The dashboard usually stops one chapter too early
Most growth readouts are built around exposure.
People who received the reminder completed more tasks.
People who received the credit returned more often.
People with streak protection logged more active days.
That can be a valid answer to a local question. If the business intends to keep the support forever and its economics work, the local answer may be enough.
It is not enough when the team claims it created durable preference, routine, or value.
To make that claim, the observation window needs a quiet period after the intervention. The team needs to watch what happens when the extra reason to act is gone.
I think of this as a withdrawal test.
The phrase sounds harsher than the product move needs to be. It does not mean surprising users by taking away a promised benefit. It does not mean removing accessibility support, safety features, or something the customer paid for. It means designing a bounded support honestly, stating its duration, and preserving enough observation after it ends to learn what the support actually changed.
I like a small artifact called a support removal brief
Before launching a prompt, reward, concierge layer, or temporary credit that is supposed to create lasting behavior, I would write one page.
Support removal brief
- The user behavior we hope will become easier or more valuable
- The support we are adding
- The job that support is meant to do
- The date or condition when the support ends
- What the user has been promised about that ending
- The behavior we expect to persist without support
- The alternative reasons that behavior might disappear
- The quiet window in which we will observe unsupported choice
- The segments excluded because removal would be unsafe or unfair
- The decision we will make if the lift disappears
- Owner
The artifact forces a team to say whether the support is a bridge, a permanent part of the product, or simply a test stimulus.
That alone clears up a surprising amount of confused strategy.
If the credit is a permanent part of the value exchange, model it as a cost of serving the product.
If the reminder is a permanent preference the user controls, evaluate whether it stays useful without becoming noise.
If the prompt is meant to reveal value and then get out of the way, test whether it can actually leave.
Write the hypothesis around what remains
The crisp hypothesis I would use looks like this.
If a temporary Sunday planning credit helps new members discover recurring value in a weekly plan, then members who receive the credit for four eligible weeks will publish more plans during the following four weeks without the credit than comparable members who never received it, without a rise in unwanted reminders or account closures.
That statement is doing a few useful things.
It names the proposed mechanism as value discovery rather than vague engagement. It separates the supported period from the unsupported period. It gives the team a comparison. It also admits that a persistent behavior is not automatically a healthy one if the user felt pushed into it.
The follow-up needs enough real opportunities for the user to choose the behavior again. A weekly planning product can observe several choices quickly. A travel product may make a withdrawal test impractical because the next meaningful choice is too far away.
The learning plan needs a quiet middle
I would begin with a small eligible cohort and make the temporary nature of the support clear.
One group gets the bounded support. A comparable group gets the ordinary product. During the supported period, measure whether the support moves the intended behavior and whether it changes the route people take to value.
Then let the support end as promised.
Do not immediately replace it with a new campaign. Do not send a rescue sequence the day the first metric softens. Do not protect the result from the very condition it was supposed to survive.
During the quiet window, measure voluntary recurrence, the useful outcome behind the action, reminder preferences, and signs of resentment or confusion. Talk with a small set of people from both groups. Ask what changed in the work, not whether they formed a habit.
If behavior persists, look for the mechanism.
Did people learn a faster way to do the job. Did they create useful data that lowered future effort. Did the output become part of another routine. Did the product become more valuable with use.
If behavior collapses, that is not a failed experiment.
It is a clearer product diagnosis.
The support may have been the value rather than a bridge to it. The underlying job may occur less often than the team assumed. The prompt may have created compliance without making the outcome more useful. The permanent product may need to carry a cost that the temporary test was hiding.
That is good information to get before a subsidized metric becomes a roadmap promise.
This test is not always the right move
A withdrawal test is useful when the team is claiming that temporary support creates lasting behavior and when removal is honest, safe, and reversible.
It is useful for onboarding credits, limited concierge help, launch incentives, repeated prompts, and other temporary support the team expects to retire.
It is not useful when the support is the product.
A calendar alert does not need to prove that people remember meetings after alerts disappear. Fraud protection does not need to be removed to prove that customers value safety. A paid coaching service does not become weak because behavior changes when coaching stops.
It is also the wrong move when removal breaks a promise, creates material risk, or falls unevenly on people who depend on the support. Product curiosity does not outrank user welfare.
Sometimes the honest conclusion is that the behavior needs continued support. That can be a good product. The team should call it what it is and design the economics, controls, and user choice around that truth.
Durable growth should survive an honest silence
I am not against nudges, rewards, reminders, or temporary help.
They can open a door that the user would not have found alone.
I am against letting the hand on the door become evidence that the user will keep walking after we let go.
The mature question is not only whether the support moved the metric.
It is what became easier, more valuable, or more self-sustaining because the support was there.
If we believe the product earned something durable, we should be willing to create a quiet window and find out.
