Growth Hacking Starts With a Bottleneck
A team launches a new feature, sends more visitors to its website, and celebrates a rise in signups. A month later, the number of people using the product has barely moved. The campaign did its job, but the business is still struggling to grow. If you are looking up “growth hacking” after a result like that, the useful question is not which clever campaign to copy. It is where people stop getting value, and which change might help them continue.

Growth hacking is repeated experimentation to find ways to grow a business. It can address how people discover a product, begin using it, or keep using it; the term itself does not name a channel or a particular trick. GrowthHackers describes experimentation across the customer journey. The practical aim is to learn which changes produce more valuable customer behavior within a stated period, then decide whether those changes deserve more resources.
That definition sounds simple, but it changes the order of work. A team that starts by asking for more traffic may be buying more chances to lose people at the same point. A team that starts with the point of loss can choose a smaller experiment and see what it changes. Speed matters because learning takes time. Speed alone does not make an experiment useful.
Start with the action that makes the product valuable
Before changing a signup page or buying ads, name what a new customer must do to receive the product’s value. For a hypothetical shared planning tool, that action might be creating a plan with another person. A signup is necessary to reach that action, but a signup by itself does not show that the person received the intended benefit. If the tool is meant to support continuing collaboration, the team also needs to know whether people return to their plans after the first session.
This gives acquisition, activation, and retention different jobs. Acquisition concerns bringing eligible people into the product. Activation concerns their first meaningful use. Retention concerns whether they continue to use it after that first experience. All three can be targets for growth experiments, as the GrowthHackers account of growth hacking makes clear. They should not be rolled into one reassuring number, because each measure describes a different group of eligible people and a different question.
For the planning tool, the team could count how many relevant visitors sign up, how many new signups create a shared plan within seven days, and how many of those new signups return to a shared plan four weeks later. Those definitions are illustrative, not universal benchmarks. The product might need a shorter window if its value is immediate, or a longer one if teams plan only once a month. The point is to state the user action and the time allowed before interpreting a change in the number.
I would choose a measure close to customer value even if it makes progress look slower. Total signups are easy to raise through a wider campaign. Shared plans used again are harder to raise, but they answer a more consequential question for this particular product. That choice costs the team a longer wait for some results and may make an attractive launch look modest. It also prevents a short burst of curiosity from being mistaken for continuing demand.
Find the constraint before choosing a tactic
Suppose the planning tool has an illustrative cohort of 1,000 relevant visitors. Of those visitors, 200 sign up; 40 of the 200 new users create a shared plan; and 12 of the 40 creators use that plan four weeks later. The figures do not describe a real company. They make a decision visible: 20% of visitors sign up, 20% of signups reach the first shared plan, and 30% of first plan creators return at four weeks.
With these numbers, I would first look closely at the move from signup to first shared plan. Sending another 1,000 similar visitors might yield more signups, but it would also send most of those new users into the same weak first experience. The next question is what prevents the 160 signups who did not create a plan from doing so. Perhaps they do not understand the first step; perhaps they have no colleague to invite; perhaps they signed up for an entirely different reason. Those are possibilities to investigate, not conclusions that the figures establish.
The choice could reverse if the 40 people who create shared plans consistently find enough value and the business simply has too few relevant visitors. It could also reverse if the 12 people who return are too few to justify improving onboarding before changing the product itself. Growth strategy asks which customers to serve, what value to deliver, and where to allocate effort; an individual test cannot settle all three choices. Reforge’s growth strategy material connects the growth model to its constraints and investment decisions. I would make the next experiment answer the most consequential uncertainty, then reconsider where resources belong.
This is also why “try referrals,” “make a landing page,” or “add a discount” is an incomplete recommendation. Each could be useful under particular conditions. None identifies the population, the stalled behavior, or why that change should help. A tactic should follow a reasoned account of the problem, rather than supply one after the fact.
Make an experiment a prediction about people
A growth experiment begins with a proposed change and an expected user response. That framing is more demanding than announcing that the team will “improve onboarding.” In Intercom’s conversation about growth experimentation, the emphasis is on learning where growth is held back across the customer journey. For the planning tool, a usable prediction might be: showing new users a ready-made plan immediately after signup will lead more of them to invite a collaborator and create their first shared plan within seven days.
Now the team can specify who qualifies: new users who signed up to plan with someone else, rather than existing customers revisiting the product. It can define the proposed change: a ready-made plan appears on the first screen. It can name the response: creation of a shared plan within seven days. It can also check whether those people later return to the plan, because a faster first action may or may not lead to continuing use. The proposal is small enough to test, yet its result would inform the larger choice about activation.
If the team can show the current and proposed first screens to comparable groups of eligible new users, that comparison gives the change a clearer reading. If it cannot, it should be more careful about attributing a later rise in plan creation to the new screen; other circumstances may have changed at the same time. The purpose is not to create an elaborate research program. It is to avoid spending the next planning cycle on a story the numbers cannot distinguish from an alternative explanation.
Write the prediction before the change ships. Otherwise, it is tempting to select whichever number happens to rise afterward and call the experiment a success. A simple note containing the audience, the change, the expected action, the observation period, and the decision that will follow is enough to make the work concrete. The Lean Startup build, measure, learn approach offers the same useful rhythm: build something that tests an assumption, observe the response, and let what happened shape the next iteration. Repeating that cycle helps a team learn; it does not guarantee that customers want the product.
Read the result with its denominator and its clock
Consider an illustrative test of the ready-made plan. Two comparable groups each contain 200 eligible new signups. In the existing experience, 50 create a shared plan within seven days: 50 out of 200, or 25%. In the changed experience, 70 do: 70 out of 200, or 35%. The changed screen is associated with 20 more first shared plans among 200 eligible new users in this illustration. Calling that merely “20 more activations” hides the group size; calling it “35% growth” confuses the new rate with the change in rate.
The seven-day result answers a narrow question about first use. It does not answer whether those users stay. Suppose, still illustratively, that 20 people in the existing group and 22 in the changed group return to a shared plan four weeks after signup. The four-week rates are 10% and 11% of their respective 200 signups. The team has a stronger case that the screen helps people take a first step than that it produces more continuing use. With small counts, I would resist turning that one-point difference into a confident retention claim.
There is another denominator that matters. If the team reports four-week return only among people who created a first shared plan, the groups become 20 of 50 and 22 of 70. Those rates answer how many first plan creators returned, not how many original signups returned. Both views can be informative, but they must not be swapped mid-story. A change that pulls more people into a first action can alter the mix of people in the later group. Keeping the original signup cohort visible helps the team see what happened to all eligible newcomers.
The observation period matters as much as the denominator. A seven-day window can reveal early use but cannot show a four-week return. A four-week window may still be too short for a product whose valuable action happens quarterly. The Lean Startup account of measuring and learning supports iteration around an explicit assumption; the period chosen for observation determines which delayed outcomes the team can see. I would choose the shortest window that answers the decision at hand and keep a later check for the value that takes longer to appear.
Turn a useful test into a deliberate investment
Even a clean improvement in first use does not amount to a growth strategy. The screen might help one kind of user, depend on staff guidance that cannot be offered to everyone, or create plans that are never used again. A tactical test answers a narrower question than a long-term choice about customers and resources. Intercom’s discussion of Sean Ellis’s approach places experiments across the journey rather than treating a single marketing win as the whole growth plan.
For the planning tool, I would roll out the ready-made plan more widely if new users consistently create more shared plans and the later usage pattern is acceptable for the product’s goals. I would then ask whether the added engineering and support work is justified by the additional people who actually use shared plans. If plan creation rises while later use stays flat, I would keep the learning but change the next investment: investigate why the first shared plan fails to become an ongoing habit. The costs of the preferred path are time, a slower answer on retention, and possibly foregoing an easier signup lift while the team works on the product experience.
Resource choices can change as experiments reveal a different constraint. Reforge describes growth strategy as a model that evolves with the limits a team finds. That does not mean rebuilding priorities after every small fluctuation. It means being willing to move effort when the result changes the decision: away from more visitors if first use is weak, toward acquisition if valuable use is strong but too few eligible people arrive, or toward product value if people try the product once and do not return.
Test a growth loop at every step
Some growth ideas are attractive because one cycle can create the input for another. In the hypothetical planning tool, an active creator invites a collaborator; the collaborator joins; some collaborators create their own shared plans and invite others. That is a possible growth loop because the output of one cycle can become a new creator in a later cycle. Reforge explains a growth loop as reinvesting the output of one cycle into the next. A loop is a useful account of how growth might repeat, not a promise that it will.
Trace the steps before celebrating the invites. Imagine 100 active creators generate 60 invitations in one week. Thirty recipients visit, 12 become active creators, and seven of those 12 send an invitation in a later week. These are illustrative numbers with distinct populations. The 60 invitations are not 60 new customers. The 12 new creators are the relevant output if the business needs creators who use the product. The seven later inviters show that some of that output may feed another cycle, but the numbers alone do not establish an expanding loop.
Each transition can weaken the result. If more creators invite people but recipients rarely start a plan, polishing the invitation text may be less useful than improving the recipient’s first experience. If invited recipients use a plan but never create one, that may still be valuable collaboration, while the proposed invitation loop remains limited. Reforge’s growth-loop account ties the loop’s strength to what happens at its participating steps. I would measure those steps separately and invest in the weakest consequential transition, rather than treat an invitation count as growth.
The same judgment applies to any proposed loop: name the output that returns as an input, then check whether enough of it really does return. A campaign that produces a one-time influx may be worthwhile, but it should be budgeted as a one-time influx. Calling it a loop does not make its results repeat without another purchase or push.
Keep the next decision visible
Growth hacking is most useful when the team knows what it will do with an answer. A test that increases first shared plans may earn a wider rollout. A test that changes signups but leaves valuable use untouched may lead the team back to the first experience. A result that is too narrow or too early may justify a longer observation period before moving a larger budget. None of these outcomes is wasted if the decision was clear before the work began.
For a business searching for growth, I would begin with one customer action that represents real value, find the transition that most limits that action, and run a small change against a stated prediction. I would read the result for the eligible people and time period it actually covers, then decide whether to expand the change, revise it, or work on a different constraint. That is the durable use of growth hacking: repeated choices that make the source of growth clearer, while leaving room to change course when customers behave differently from the plan.