Activation before growth
Acquisition is rented. Activation is owned.
Thesis
Some arithmetic, with round invented numbers chosen to show a structure rather than to describe anything real.
A thousand visitors arrive. Two hundred sign up. Fifty reach the point where the product has actually done something for them. Twenty are still there a month later.
Now spend to double the traffic. Two thousand visitors, forty retained users, and the spend recurs every month forever.
Or leave traffic alone and take activation from fifty to a hundred. Also forty retained users, and this time the gain is permanent and it multiplies every visitor you ever acquire afterwards, including the ones you have not paid for yet.
Acquisition is a rented gain. Activation is an owned one. Everyone knows this in the abstract and the ordering of work rarely reflects it, because acquisition produces a visible number in week one and activation work produces an argument about definitions.
Which is the actual difficulty. Activation is not an onboarding design problem. It is a definition problem, and most teams cannot state their activation event in a sentence. The ones that can have already done the hard part.
Context
The standard funnel language, acquisition then activation then retention then referral then revenue, is thirty years old in various forms and it is not wrong. What it does badly is imply that the stages are equally tractable and should be worked in order.
They are not equally tractable. Acquisition has a large vendor ecosystem, dozens of channels, and immediate feedback, so it absorbs effort easily. Activation has almost no vendor ecosystem, is specific to your product, and requires you to know what your product is for with a precision most teams have not reached.
So effort flows to acquisition, and it flows there hardest in exactly the situation where it is most wasted: early, before anyone knows whether the product works. Spending on traffic before activation is understood converts a marketing budget into a measurement of your own leak, at retail prices.
Research
Reichheld and Sasser, 1990, "Zero Defections". The origin of retention economics as a management idea, and the source of the widely quoted claim that a five percent improvement in customer retention produces a large increase in profit. The specific range in that paper has been criticised for over-generalisation, and it should not be quoted as a law. What survives the criticism is the structural point: retained customers have a longer revenue stream against a fixed acquisition cost, so retention improvements act on the whole base rather than the margin.
Nunes and Drèze, 2006, on endowed progress. A field experiment with car wash loyalty cards. One group needed eight stamps to earn a free wash. Another needed ten but was given two for free. Same requirement, different framing, and the endowed group completed at a substantially higher rate. People persist toward goals they have already started, and the perception of having started can be granted.
This is the strongest empirical result available on onboarding progress design, and it says something more specific than "show a progress bar". It says begin the bar part-filled.
Norton, Mochon and Ariely, 2012, "The IKEA Effect". Across several experiments, people valued objects they had partially assembled themselves more highly than identical pre-assembled ones, and the effect depended on completing the task. Incomplete assembly killed it.
This complicates the standard advice to remove all friction. Effort a user invests and completes creates attachment. Effort they abandon creates nothing and costs you the user. So the design question is not how little work to require. It is what work is worth requiring, and whether you have made completion likely.
Kohavi and colleagues on online controlled experiments. The reported finding from large-scale experimentation programmes is that only a minority of ideas produce the intended improvement, with roughly a third positive in Microsoft's reported experience and similar rates elsewhere. Applied here: your beliefs about what is blocking activation are probably wrong, at a base rate you should assume applies to you.
The industry folklore, handled honestly. Facebook's seven friends in ten days, Twitter's thirty follows, Slack's two thousand messages exchanged. These circulate constantly and are almost always second-hand, without the underlying analysis, and they share two problems. They are correlational, so the behaviour may be a symptom of engagement rather than a cause. And they are specific to those products at those moments, which means importing the number is cargo-culting.
The method behind them transfers. The numbers do not.
Product-market fit, as Rachleff and Andreessen framed it, and the practitioner heuristic from Sean Ellis in which you ask users how disappointed they would be if the product disappeared and look for a substantial share saying very disappointed. That heuristic is practice rather than research and should be labelled as such. Its usefulness is that it is answerable early, on small numbers, which is more than can be said for most fit measures.
Argument
Define the activation event as a specific observable moment, or you are not working on activation.
The test for a good definition: it is a single event, it is instrumented, and users who reach it retain at a visibly different rate from users who do not.
Signup is not activation. Completing onboarding is not activation. Both measure your flow rather than the user's outcome. Activation is the moment the product has delivered the thing it promised, at least once. For a scheduling tool it is a meeting booked by someone else. For an analytics product it is a question answered that the user actually had. For a payments product it is money moving.
If you cannot name yours, that is the finding. It usually means the value proposition is not yet specific enough to be observed, and no amount of onboarding design fixes an unclear promise.
Find your own threshold in your own data, and be honest about causation.
The method is straightforward. Take users from a period long enough ago to know whether they stayed. Split by retained and churned. Look for behaviours in the first session or first week that separate them. Test whether pushing new users toward the behaviour changes retention, rather than assuming it will.
That last step is the one everybody skips, and skipping it is how a correlation becomes a roadmap. Users who invited three teammates may retain better because inviting teammates creates value, or because people who were already going to stay are the kind of people who invite teammates. Those two worlds look identical in a correlation and imply opposite roadmaps.
Optimise time to first value, not number of steps.
Step count is the metric teams reach for because it is easy to count. It is a poor proxy. A five-step flow that ends in something useful beats a one-step flow that ends in an empty screen.
The right measurement is elapsed time from arrival to the first moment the user has something they would miss. Measured in minutes, from real sessions. Every decision in the flow gets evaluated against that number, and questions that do not shorten it get cut regardless of how useful the answer would be to you.
The empty state is where activation actually fails.
Almost all onboarding effort goes into the sequence before the product opens, and almost all failure happens immediately after. The user arrives at a screen with no data, no content and no obvious first action, and the product silently transfers the entire burden of getting started onto them.
An empty state has to do three things: show what this will look like when it is working, give one unmistakable next action, and offer a way to reach a useful state without real work. Sample data that can be deleted is the single most underused activation mechanism in software, and the objection to it is always that it is not real, which misses that the user's problem at that moment is not authenticity but orientation.
Some friction is load-bearing, and removing it removes the attachment.
This is the part where the standard advice needs qualifying. The IKEA effect says completed effort creates value in the user's mind, and the endowed progress result says people persist toward goals they have started. Together they suggest a shape: ask for a small amount of real work early, make it feel already underway, and make sure it completes.
What to cut is effort that produces nothing the user can see: questions you ask for your own segmentation, account details you do not need yet, verification before any value has been delivered. What to keep is work that constitutes the product, like naming a workspace, importing a file, or configuring the one thing that makes output relevant to them. That work is not friction. It is the user building something, and abandoning it is a much larger loss than an extra step.
Activation is the earliest honest signal of product-market fit, which means this work is not a detour.
The usual framing sets fit and growth as sequential and treats activation as a growth activity, to be done later. That has it backwards. An activation rate is a measurement of whether the product delivers its promise to the people who wanted it enough to try, on a sample size you can reach in weeks. It is the cheapest fit signal available.
A product with strong activation and weak acquisition has a distribution problem, which is solvable with money and time. A product with strong acquisition and weak activation has a product problem, and spending on acquisition makes the measurement worse by adding less qualified traffic. Knowing which one you have is worth more than most of what a first growth hire will do.
Examples
A payments product for small merchants. Signup is not activation. Dashboard access is not activation. The activation event is the merchant's first real customer payment, because everything before that is setup and nothing before that has delivered the promise. Which means the flow should be optimised for reaching one transaction, and the analytics that seem like the product should come after, since they are worthless with one row of data.
A B2B analytics tool. Activation is the first question answered that the user brought with them. The failure mode is a dashboard of default charts nobody asked for, which looks like value delivered and is not. A better first experience asks what they want to know and answers that one thing.
A consumer habit product. Activation is the second session, not the first, since the promise is a habit and one use has not delivered it. This changes the design entirely: the first session's job is to make the second one happen, which is a different objective from making the first one impressive.
A creative tool. Activation is the first output the user would show someone else. Not a file saved, not a project created. Something they would send. That definition is harsh and it is the one that predicts retention, because a creative tool retains on the strength of what people make with it.
Counterargument
"You cannot find your activation event without volume, so acquisition genuinely comes first."
This is correct and it is the strongest objection here. Threshold analysis requires enough users to see a difference between cohorts, and with forty signups you have no statistical power to distinguish a real behavioural predictor from noise. Telling an early team to identify their activation metric before acquiring users asks them to run an analysis on a sample that cannot support it.
There is a second version, structural rather than statistical. Some businesses really are acquisition-constrained. Marketplaces need liquidity on both sides before anyone can activate at all. Low-frequency, high-consideration purchases have too few events to optimise. In those cases activation work is premature not because it is unimportant but because the mechanism it depends on is not yet running.
And a third version, which is the one that lands hardest: activation optimisation is a comfortable place to hide. It is legible, it feels rigorous, and it can absorb a year of work on a product that nobody wanted. Rewriting onboarding for the fourth time is a way of not asking whether the promise is worth keeping.
Where this is right. The statistical objection is simply true, and the honest early-stage version of this work is qualitative rather than quantitative. Watch ten people use it. You will not get a threshold, and you will get the blockers, which is what you actually need at that stage. Save the cohort analysis for when you have cohorts.
The hiding objection is also right, and it has a tell worth watching for: if activation work is not accompanied by conversations with users about whether the outcome mattered, it has become interior decoration.
Where I think it is wrong. Defining the activation event does not require volume. It requires clarity about what the product promises, and that is available on day one with zero users. What requires volume is finding the threshold, which is a later and separate question. Conflating the two is what makes the objection sound stronger than it is.
On the marketplace case: activation is still definable, it is just per side and it is about the first useful interaction rather than about signup. And the acquisition-first strategy in a marketplace usually fails precisely because nobody defined what a supplier or buyer needed to experience to come back.
Practical implications
Write your activation event as one sentence with a verb and an object. If you need two sentences, you have not found it.
Instrument that event before you spend anything on acquisition. Not the full funnel. That one event.
Measure time to first value in minutes, from real session recordings, and treat step count as a diagnostic rather than a target.
Redesign the empty state first. It is where the loss happens and it is usually the least designed screen in the product.
Ship deletable sample data. Cheap, and it moves a user from staring at nothing to seeing what the product does.
Cut every question that serves you and not the user's first outcome. Segmentation questions can be inferred later or asked after value.
Keep the friction that constitutes the product, and make it complete. Abandoned effort creates nothing. Completed effort creates attachment.
Watch ten people before analysing ten thousand. Qualitative first at low volume, thresholds later.
Do not import someone else's magic number. Take their method and run it on your own data.
Assume most of your fixes will not work. Ship them as tests where you can, and expect a minority to move anything.
My perspective
Opinion, and it is a confession rather than a demonstration.
TapQR is live. It has a register route, a login route and a dashboard, and it prices a smart NFC sticker at ₹199 with an intelligence tier at ₹99 a month. All of that is checkable. What I cannot tell you is the activation rate, because nothing was instrumented, and this article's central instruction is the one I did not follow on my own product.
Worse, I built in an order that suggests I had not thought about it. The merchant dashboard came before conversations with merchants, which means the first screens of the product were designed around what I imagined a merchant would want to see rather than around getting one payment to happen. The activation event for that product is obvious in hindsight and I can state it in a sentence now: a merchant's first real customer payment through their own sticker. Everything before that is setup, and the dashboard is worthless until it has a row in it.
There is an activation improvement figure attached to my earlier work in various places on my own site. I have excluded it from this archive because no analytics export exists behind it, and I would rather write an article about activation with no numbers of my own than reuse one I cannot show you.
The thing I would tell a founder with more confidence than anything else here: if you cannot state your activation event, do not hire for growth. You will pay someone to bring traffic to a leak whose shape nobody has measured, and the traffic will make the diagnosis harder rather than easier.
Conclusion
Acquisition improvements are rented and recur as a cost. Activation improvements are owned and multiply every future visitor, including the free ones.
The work is not primarily onboarding design. It is naming the moment your product first delivers what it promised, instrumenting that moment, and reducing the time to reach it. Find your own threshold in your own data, test it rather than assuming it, and keep the friction that constitutes the product while cutting the friction that serves you.
And if the activation event cannot be named, that is not a gap in the analytics. It is a statement about the promise, and it is the most useful thing you will learn that month.
Sources
- F. F. Reichheld and W. E. Sasser Jr., "Zero Defections: Quality Comes to Services", Harvard Business Review, September 1990. The specific profit range in this paper has been criticised for over-generalisation and is cited here for its structural argument only.
- J. C. Nunes and X. Drèze, "The Endowed Progress Effect: How Artificial Advancement Increases Effort", Journal of Consumer Research 32(4), 2006, 504–512.
- M. I. Norton, D. Mochon and D. Ariely, "The IKEA Effect: When Labor Leads to Love", Journal of Consumer Psychology 22(3), 2012, 453–460.
- R. Kohavi, D. Tang and Y. Xu, Trustworthy Online Controlled Experiments, Cambridge University Press, 2020.
- R. Kohavi, R. Longbotham, D. Sommerfield and R. M. Henne, "Controlled experiments on the web: survey and practical guide", Data Mining and Knowledge Discovery 18, 2009.
- M. Andreessen, "The Only Thing That Matters", 2007, on product-market fit, following A. Rachleff's formulation.
- S. Ellis, the forty percent "very disappointed" survey heuristic. Practitioner method, not research.
- tapqr.live, live product with
/register,/loginand/dashboardroutes and published pricing of ₹199 and ₹99/month. Recorded as A22, A23 and A24 inSOURCE_INVENTORY.md. https://tapqr.live
Related reading in this archive
- TapQR: the product referred to above, and the ordering mistake
- Cognitive load is the real SaaS design problem
- Latency, trust and the two variables everyone conflates
- Why I build many small products instead of one large one