A growth loop is built in seven steps: identify a repeated user action, instrument its inputs and outputs, choose an archetype (viral, content, sales, or paid), design the reinvestment mechanism, ship the minimum viable version, measure the compound rate over 2 to 4 cycles, then kill or scale. Most teams skip steps 1 and 2 and design loops on a whiteboard instead of on top of behavior that already happens. This guide walks each step with a B2B docs SaaS worked example showing how a doc-share loop slid from a 1.2 k-factor to 0.8 and how to diagnose the drop.
What is a growth loop, and why does it beat a funnel?
A growth loop is a closed system where the output of one user's action becomes the input that acquires the next user. Funnels leak users out the bottom. Loops feed them back to the top.
The term was popularized by Casey Winters and Brian Balfour at Reforge, who argued that funnel thinking forces teams to keep buying inputs. Loops compound because every cycle creates more inputs than the last.
Three properties separate a real loop from a funnel:
- Closed -- the output reinvests as a new input, automatically.
- Compounding -- N users in cycle 1 produce more than N users worth of inputs in cycle 2.
- Owned by the product -- the mechanism lives in the product or content surface, not in a one-off campaign.
Dropbox's storage-for-referrals loop is the canonical example: it took the company from 100,000 to 4 million users in 15 months, per a widely cited case study. Loom's view-to-signup loop and Notion's public-template gallery are the same pattern in B2B.
If your acquisition graph is flat or sublinear with spend, you have a funnel. If output of cycle N becomes a measurable input for cycle N+1, you have a loop.
How do you build a growth loop from scratch in 7 steps?
Building a growth loop from scratch takes 7 steps: find a repeated user action, instrument it, pick an archetype, design the reinvestment, ship a minimum viable version, measure the compound rate, and decide kill or scale. Each step has a concrete output you can hand to the next person on the team. Skip none of them.
The sequence below uses a worked example throughout: DocFlow, a fictional but realistic B2B docs SaaS where users create technical docs and share them with teammates and external reviewers. The loopthey built was a doc-share loop that compounded for 6 months, then degraded from a 1.2 k-factor to 0.8. We'll use it to illustrate every step, including diagnosing the drop.
Step 1: Identify your existing repeated user action
Find a behavior users already do, frequently, without prompting. The growth loop must be parasitic on this action, not a new ask layered on top.
Look in your product analytics for actions with these properties:
- High frequency (weekly or more)
- Tied to core value (users do it because the product works)
- Naturally outward-facing (involves a second person, link, or artifact)
For DocFlow, the repeated action was publishing a doc and sending its link to a reviewer. 64% of activated users did this in week 1. That's the seed for a loop.
If no behavior shows these properties, do not invent one. Build the loop somewhere else, or fix activation first.
Step 2: Instrument the inputs and outputs
Track every event in the candidate cycle before you change anything. You cannot improve a loop you cannot see.
At minimum, instrument:
- Trigger event: action that starts the loop (DocFlow:
doc_shared) - Output event: thing the trigger produces (DocFlow:
share_link_visited) - Conversion event: when the output produces a new input (DocFlow:
recipient_signed_up) - Activation event: when the new user becomes capable of triggering the loop themselves
Use PostHog, Amplitude, or Mixpanel. Tag every event with loop_id and cohort_week so you can compute cycle time later. The Thoughtlytics guide to growth loops lays out a clean event taxonomy.
Step 3: Choose your loop archetype
Reforge classifies acquisition loops into four archetypes: viral, content, sales, and paid. Pick one before designing the mechanism.
- Viral: existing users invite or expose new users (Dropbox, Loom)
- Content: users or your team create artifacts that distribute via SEO or social (Notion templates, HubSpot blog)
- Sales: SDRs convert one customer's deployment into intros at the next account
- Paid: revenue from new users funds the next round of acquisition
For B2B docs SaaS, viral and content are the high-leverage archetypes. DocFlow chose viral: docs are inherently shared, recipients are pre-qualified, and exposure is free. The wrong archetype kills the loop before it ships.
Step 4: Design the reinvestment mechanism
Specify exactly how an output of cycle N becomes an input of cycle N+1. This is the design step most teams hand-wave.
Answer four questions in writing:
- What artifact carries the loop? (DocFlow: a public doc URL)
- What signal does the recipient see? (a footer: "Built with DocFlow")
- What's the call to action? ("Create a free doc" button)
- What does the new user do that closes the loop? (publish their own doc and share it)
DocFlow's reinvestment: every shared doc renders a discreet footer with a one-click signup link. The signup flow drops the new user into a doc editor pre-filled with their team's name. From signup to first share averaged 4 days in cycle 1.
Step 5: Ship the minimum viable loop
Ship the loop hardcoded, ugly, and instrumented. A minimum viable loop is a small testable version that lets you observe whether self-reinforcing behavior exists, not a polished feature.
Keep the MVL to less than 2 weeks of build time:
- Hardcode the share artifact (no admin UI)
- Use server-side rendering, skip A/B test infrastructure
- Fire events to your existing analytics tool
- No design polish until you see compounding
DocFlow shipped its v1 in 9 days: a footer banner, a single signup landing page, and event tracking. They measured for 28 days before changing anything. Resist the urge to optimize before the first measurement.
Step 6: Measure the compound rate
After at least 2 full cycles, compute the k-factor and cycle time. The viral coefficient formula, per Wall Street Prep, is:
K = (invites per user) × (conversion rate)
DocFlow cycle 1 numbers: 3.4 shares per user × 35% recipient signup rate = k-factor of 1.19. Cycle time (median time from share to recipient's first share) was 4.1 days.
Growth rate compounds as K^(time / cycle_time) - 1, which is why velocity matters as much as coefficient. A k of 0.6 with a 3-day cycle outperforms a k of 1.1 with a 30-day cycle over 90 days. Measure both.
Step 7: Kill or scale
After 3 to 4 cycles, decide. The framework from Phiture is scale, iterate, or kill:
- Scale if k > 0.5 and trending up: invest in polish, A/B testing, more entry points
- Iterate if k is between 0.2 and 0.5 and any sub-metric (invites, conversion, cycle time) has obvious upside
- Kill if k < 0.2 or has plateaued for 3+ cycles after iteration
DocFlow's k started at 1.19, peaked at 1.24, then degraded to 0.8 over 6 months. They almost killed it. Diagnostics in the next section show why they iterated instead, and got back to 1.1.
What does a working growth loop look like (B2B docs SaaS example)?
DocFlow's doc-share loop is a viral B2B loop with measurable inputs, outputs, and a degradation story worth studying. Here's the full anatomy and the diagnostic that saved it.
The loop:
- User publishes a doc, shares URL with reviewer
- Reviewer lands on the doc, sees "Built with DocFlow" footer
- Some % click through to a signup page
- New user creates first doc within 4 days
- New user shares with their reviewers (cycle restarts)
Cycle 1 metrics (month 1):
| Metric | Value |
|---|---|
| Avg shares per user | 3.4 |
| Recipient signup conversion | 35% |
| K-factor | 1.19 |
| Median cycle time | 4.1 days |
After 6 months, k-factor had drifted to 0.8. The team ran a three-metric diagnostic:
| Sub-metric | Cycle 1 | Month 6 | Diagnosis |
|---|---|---|---|
| Avg shares per user | 3.4 | 2.6 | Share button moved into a sub-menu in a UI redesign |
| Recipient signup conversion | 35% | 22% | New 4-step onboarding added friction for invited users |
| Cycle time (days) | 4.1 | 11.0 | An "approve sharing" admin step was added for compliance |
The fix wasn't sexy: restored the share button to the toolbar, built a 1-step onboarding for invited recipients, and made admin approval async (notify, don't block). After 8 weeks, k-factor recovered to 1.1. The lesson: loops degrade silently when other product priorities collide with loop instrumentation. Re-measure quarterly or assume decay.
How long does it take to build a growth loop?
Plan 6 to 12 weeks from idea to a defensible kill-or-scale decision. Less is rushed, more is over-engineered.
A realistic split:
- Weeks 1 to 2: identify the user action, instrument events, validate frequency
- Weeks 3 to 4: choose archetype, design reinvestment, write the loop spec
- Weeks 5 to 6: build the MVL (hardcoded, ugly, tracked)
- Weeks 7 to 10: run the loop for at least 2 full cycles untouched
- Weeks 11 to 12: compute compound rate, decide kill or scale
For consumer products with cycle times under 24 hours, you can compress this to 4 to 6 weeks. For enterprise B2B with cycle times of 2 to 4 weeks, expect 4 to 6 months before you have enough cycles to make a defensible call.
What you cannot compress: the number of full cycles you observe before deciding. Two cycles is the floor. Four is more honest. Most teams kill loops too early because they confuse cycle 1 noise with signal.
What inputs and outputs should a growth loop have?
Every growth loop has four mandatory components: an input (new users entering), a trigger (action they take), an output (artifact or signal that exposes new prospects), and a conversion (those prospects becoming the next input). If any one is missing, you have a feature, not a loop.
The minimum instrumentation, per the Reforge loop template library:
- Input: signups, activations, or qualified users entering the cycle
- Trigger: count and rate of the loop-starting action per user per week
- Amplification: reach of each output (views, impressions, attributed visits)
- Conversion: % of exposed prospects that become the next input
- Activation: time until the new input completes its first trigger (this is your cycle time)
For DocFlow: input = signups, trigger = doc_shared, amplification = share_link_visited, conversion = recipient_signed_up, activation = recipient_first_share. Five events. That's the entire instrumentation. Anything more is premature.
How do you measure if a growth loop is working?
A growth loop is working if its k-factor is stable or rising over 3+ cycles, and its cycle time is flat or shrinking. Either metric in isolation lies. Both together tell the truth.
The two numbers that matter:
- K-factor (viral coefficient): invites per user × conversion rate. Per Saxifrage's k-factor benchmarks and Visible.vc, B2B SaaS targets are 0.2 (decent), 0.5 (strong), 1.0+ (rare and exceptional).
- Cycle time: median days from new-user signup to their first loop-triggering action.
Compound growth formula: Users(t) = Users(0) × K^(t / cycle_time)
A few tactical rules:
- Cohort the data by signup week. Aggregated metrics hide degradation.
- Re-measure quarterly. Loops decay silently when other product changes ship.
- Compare against your acquisition CAC. A loop with k=0.4 and a 3-day cycle can outperform a paid channel even though it's "sub-viral".
Typeform reportedly multiplied its k-factor 4x in two years by attacking activation, exposure, and conversion as separate sub-metrics. That's the playbook: measure the components, not just the headline.
What is the minimum viable growth loop?
A minimum viable growth loop (MVL) is the smallest hardcoded version of a loop that can produce measurable cycles within 2 weeks of build time. The point is to observe self-reinforcing behavior, not to launch a feature.
A proper MVL has four traits:
- Hardcoded: no admin UI, no flexibility, one path through the product
- Instrumented: every event in the cycle fires to analytics
- Ugly: zero design polish until you see signal
- Time-boxed: ships in 2 weeks or you're over-investing
What an MVL is not: a polished referral program, a tested invite UI, an A/B test of three CTAs. Those come after the MVL proves the loop compounds at all.
DocFlow's MVL was 9 days of work: a footer banner on shared docs, a single static signup landing page, and 5 PostHog events. They measured for 28 days before touching anything. The MVL is the cheapest way to find out if the loop has any signal worth chasing.
When should you kill or scale a growth loop?
Kill the loop if k-factor stays below 0.2 after 3 cycles of iteration, or if any sub-metric (invites, conversion, cycle time) plateaus despite focused fixes. Scale if k > 0.5 and trending up over 3+ cycles.
Kill criteria:
- K-factor < 0.2 across 3+ measured cycles
- No sub-metric responds to focused experiments
- Cycle time is structurally long (>30 days) and cannot be shortened by product change
- The triggering user action is itself declining
Scale criteria:
- K-factor > 0.5 and stable or rising
- Sub-metrics still have obvious experiment surface area
- Cycle time under 14 days for B2B, under 7 for consumer
- Loop survives a 28-day untouched observation window
Most growth experiments should be killed. Phiture's framework explicitly notes that in a healthy growth team, the majority of experiments are killed, some are scaled, and a choice few deserve another iteration. Killing is the default. Scaling earns its keep.
| Step | Output | Time | Done when... |
|---|---|---|---|
| 1. Identify repeated user action | Named action with frequency data | 2-4 days | You have a behavior >50% of activated users do weekly |
| 2. Instrument inputs/outputs | Event taxonomy in analytics tool | 3-5 days | All 5 loop events fire reliably |
| 3. Choose archetype | Written archetype decision | 1 day | Viral, content, sales, or paid is selected with rationale |
| 4. Design reinvestment | Loop spec doc | 2-3 days | Artifact, signal, CTA, and closing action are specified |
| 5. Ship minimum viable loop | Hardcoded loop in production | <2 weeks | Loop fires events end-to-end for real users |
| 6. Measure compound rate | K-factor + cycle time over 2+ cycles | 4-8 weeks | You have stable cohort metrics, not noise |
| 7. Kill or scale | Kill/scale decision document | 1 week | Decision criteria are met or violated |