What is growth hacking?

What is growth hacking?

Growth hacking is an organised way to find growth through small experiments, measurement, and rapid learning. It does not mean bypassing rules or looking for one “viral” trick. It is about checking what genuinely helps the right users discover a product, begin using it, return, and recommend it.

The name can be misleading because it suggests a spectacular shortcut. In practice, good growth hacking resembles product work: you formulate a hypothesis, choose a measure, implement a limited change, and decide from the result whether it is worth developing further.

Start with the problem and the measure

You cannot “hack growth” without defining what is meant to grow. More visits are not automatically a success if users do not understand the offer or do not return. For one product the important thing may be the first correct use of a feature, for a store a return to the cart, and for a B2B service a conversation with a well-matched customer.

Write the hypothesis in a simple format: “If we change X for Y, then Z will improve because…”. For example: “If we explain in the form why we ask for a phone number, more people will complete the submission.” Such a hypothesis forces specificity and prevents changing five elements at once.

Five stages of growth

It is useful to observe a product as a sequence of stages, not merely a visit to a website:

1. Acquisition — the right person learns that the product exists.
2. Activation — they perform the first action through which they feel value.
3. Retention — they have a reason to return and use it again.
4. Referral — they can easily pass the product on when it has genuinely helped.
5. Revenue — the business model makes it possible to sustain product work.

This is not a rigid funnel. In a teamwork application, activation may require inviting a colleague; in an educational service, it may mean finding an answer to a specific question. The important thing is to define an event that demonstrates value for the user, not merely a click.

Experiment where uncertainty is greatest

The best experiment is not the most impressive one, but the one that removes an important unknown. If you do not know whether an audience understands the problem, improve the message or speak to customers first. If people start a process but do not finish it, check the number of fields, requested data, errors, and the point at which they give up.

Areas you might test include:

• the headline and value description on a landing page;
• the order of steps in registration or a form;
• the way price, timeframe, or scope is presented;
• the first experience after account creation;
• a reminder about an unfinished task.

Do not blindly copy solutions from large platforms. A mechanism that works in a mass-market product may be unsuitable in consultative sales, where the quality of a conversation matters more than the maximum number of forms.

How to choose the experiment to start with

The idea list grows faster than the ability to test it. Instead of selecting the loudest idea, assess every hypothesis in four dimensions:

Criterion	Question
Impact	Does the change affect an important constraint or a minor element?
Confidence	What data or observations support the hypothesis?
Cost	How much work, risk, and coordination does the test require?
Speed of learning	How quickly will the result enable a decision?

A score can help organise the conversation, but it is not an objective algorithm. A hypothesis with a high score can still rest on an assumption. Prioritise tests that touch a bottleneck and can be safely reversed.

Before implementation, also record stopping conditions: a technical error, a deterioration in an important guardrail metric, user complaints, or missing data needed for interpretation. An experiment should increase knowledge without shifting risk to customers.

Take care of dependency order. Do not test a sales message when the form does not save enquiries, or a referral programme when new users do not reach first value. Remove the earlier journey constraint first. Otherwise, the result at a later stage will merely be the effect of a problem the experiment does not cover.

Data should support a decision, not create an illusion of control

Growth hacking needs data, but an excess of dashboards does not replace the question “what will we do if the result differs from what we assumed?”. Define events, one comparison period, and the traffic source. Then combine numbers with observation: sales-call records, support questions, and short user tests often explain a result better than a line on a chart.

Key performance indicators are useful, but only when each one answers a concrete decision. If a metric does not change how the team acts, it is probably not a KPI yet.

Read a result in the context of the whole journey. When simplifying a form raises the number of submissions, also check whether conversations are better matched and whether the team can answer them. When a promotion raises purchases, compare order quality, returns, and later customer returns. This prevents an experiment from improving one part of the funnel at the expense of experience or profitability elsewhere.

The limits of growth hacking

Growth does not justify manipulating a user. Hidden costs, artificial obstacles to cancelling a service, or automatically added consents may temporarily raise numbers, but they destroy trust and obscure the true picture of a product. It is equally risky to optimise clicks alone when final value only arises after implementation or purchase.

It is also important to know when an experiment makes no sense. When a product has a serious error, lacks basic service, or the offer is unclear, repair the foundation first. Testing a button colour will not solve a problem the user cannot name.

Do not experiment with legal obligations, security, or accessibility as variables “to optimise” either. Consent, the ability to cancel, a clear price, and data protection are conditions of the solution. A test may compare two honest ways of explaining information, but should not check how many users can be pushed into acting by hiding it.

Not every conclusion has to lead to implementation. A result that overturns a convincing hypothesis and prevents further investment in the wrong direction is equally valuable. The condition is an honest record: what changed, for whom, for how long, and what the result still does not let you conclude. Such documentation means subsequent tests build the team’s knowledge rather than start from zero.

A simple work rhythm

1. Choose one narrow question about user behaviour.
2. Agree on the measure and the condition under which you will consider a change worth further work.
3. Introduce the smallest safe experiment.
4. Record the result, conclusion, and next decision.
5. Repeat the process on the current largest constraint.

At the beginning, a simple experiment register available to the whole team is enough. It prevents repeated tests, preserves limitations, and distinguishes an observation from a conclusion. Only once this rhythm works is it worth expanding analytics tools.

That is the useful version of growth hacking: systematic learning, not a collection of tricks. If you need to combine data, user experience, and product development into one process, analytics for companies can be a starting point. Read more about using existing traffic itself in the article on conversion-rate optimisation.