Growth Hacking: What It Actually Is (And Isn't)

The Term Is Misleading. The Concept Is Valid.

"Growth hacking" became a buzzword so fast that it lost most of its meaning. Today it evokes black-hat tactics, spray-and-pray email campaigns, and LinkedIn posts about going viral.

The original idea — from Sean Ellis in 2010 — was simpler and more useful: apply the scientific method to growth. Hypothesize, test, measure, iterate. Ruthlessly prioritize growth over everything else until you find what works.

That's not a hack. It's a discipline.

What Growth Hacking Is

Growth hacking is a structured process for finding, testing, and scaling growth levers faster than traditional marketing allows. The key elements:

It's cross-functional. Real growth work spans product, engineering, data, and marketing. A "growth team" that only runs ads isn't doing growth hacking.

It's hypothesis-driven. Every experiment starts with a specific, falsifiable hypothesis: "If we add social proof to the signup page, we expect conversion to increase by 15% because users need trust signals before committing."

It's metric-obsessed. You measure everything. No experiment runs without a defined primary metric and a minimum detectable effect.

It deprioritizes brand. Growth hackers optimize for measurable outcomes — signups, activations, conversions — not awareness or brand equity. This makes it powerful in the short term and potentially myopic in the long term.

What Growth Hacking Is Not

• Running viral contests that attract the wrong users
• Importing leads and cold-emailing everyone in an industry
• Gaming app store reviews or social proof metrics
• Changing five things at once and calling the result "an experiment"
• Copying a tactic that worked for Dropbox or Hotmail without understanding why it worked

Most "growth hacks" that founders copy from case studies fail in new contexts because the underlying conditions — product maturity, audience, market timing — were completely different.

Running Growth Experiments

A minimal experiment framework:

1. Build a Backlog of Ideas

Generate ideas from multiple sources:

• User interviews (what almost stopped them from signing up?)
• Funnel analysis (where are users dropping off?)
• Competitor teardowns (what are they doing that you're not?)
• Team brainstorms

Don't filter ideas at this stage. Volume matters.

2. Prioritize Using ICE

Score each idea on three dimensions (1–10 each):

• Impact — how much will this move the key metric if it works?
• Confidence — how confident are you it will work, based on evidence?
• Ease — how fast and cheap is this to test?

ICE Score = (I + C + E) / 3

Run the highest-scoring experiments first. The framework isn't perfect but it's fast and prevents you from only running easy experiments.

3. Define Before You Build

Before implementing any experiment:

• What metric is the primary outcome?
• What's the minimum effect size that would make this worth scaling?
• How long does the test need to run for statistical significance?
• What's the rollback plan if it hurts the metric?

4. Measure Honestly

Confirmation bias kills growth programs. Read results coldly. Most experiments fail — that's expected. A failed experiment that rules out a bad hypothesis is valuable.

Product Virality

Virality is often misunderstood as luck. It's usually designed. There are two types:

Inherent virality — the product becomes more valuable or visible when used. Slack notifications ("X invited you to join..."), Calendly scheduling links, Notion shared docs, Loom video shares. The product markets itself through normal usage.

Incentivized virality — users are given a reason to invite others (referral bonuses, unlocked features, shared rewards). Effective, but synthetic — it stops when the incentive stops.

To design for inherent virality, ask: at what point in the user journey does a natural sharing event occur? How can the shared artifact be a marketing touchpoint? Can invited users experience value before signing up?

Referral Programs That Actually Work

Dropbox's referral program (extra storage for inviter and invitee) is legendary because it worked. Most referral programs don't, because they skip the prerequisites:

Prerequisites for referral program success:

• Users are genuinely happy with the product (NPS 50+)
• There's a clear audience of people the user knows who would benefit
• The reward is meaningful and product-adjacent, not cash (cash attracts gaming)
• The sharing mechanism is frictionless — one-click, pre-written message

Structure options:

• Double-sided reward (both referrer and referee get something) — best for consumer and PLG
• One-sided (referrer only) — simpler but lower volume
• Milestone rewards (invite 3 friends, unlock feature X) — drives higher effort per user

Metrics to track:

• K-factor = invitations sent per user × conversion rate of invitations. K-factor above 1 means viral growth; below 1, referral is a boost, not a loop.

What Most Founders Get Wrong

Running experiments without enough traffic. A test with 200 users per variant will give you noisy results. You need enough volume to reach significance in a reasonable time frame. If you can't, run fewer, larger experiments.

Optimizing the wrong part of the funnel. Acquisition is the default focus because it's visible. But fixing a 40% activation rate problem has more compounding impact than improving a 2% acquisition conversion rate.

Confusing correlation with causation. Users who invite friends tend to be happier users — but making them invite friends doesn't make them happier. Make sure your experiments are actually testing a causal lever.

No documentation. The value of a growth program compounds over time as you build institutional knowledge about what works and why. Without documentation, you repeat experiments and lose context when people leave.