Viral Loop Designer
Structured design of a viral or referral loop for a post-PMF product. Classifies the
mechanism type, maps the closest canonical pattern (Dropbox, Hotmail, Airbnb, LinkedIn)
to the user's product, models K-factor and cycle time, and produces a loop diagram with
a test plan — all grounded in pattern extraction, not tactic copying.
When to Use
Use this skill when:
- You want to design or redesign a referral or viral growth mechanism
- Your team is asking "how do we grow like Dropbox?" or "should we build a referral program?"
- A referral program exists but isn't producing measurable results
- You want to evaluate whether your product has viral potential before investing in a loop
- You need to choose between word-of-mouth amplification, instrumented virality, and
explicit bilateral incentives
Prerequisites:
- Product/market fit confirmed (must-have score ≥ 40% "very disappointed" or stable
retention curve). Virality on a product that doesn't deliver the aha moment accelerates
churn, not growth — users arrive, experience nothing, leave, and tell no one to join.
See
product-market-fit-readiness-gate to confirm before proceeding.
- A defined North Star Metric. The viral loop must compound the metric that reflects real
value delivered — not invites sent or accounts created. See
north-star-metric-selector.
Context and Input Gathering
Read the following before beginning:
- product-brief.md (required) — Product description, ideal customer profile,
core value proposition, current growth stage, and any referral history.
- current-referral-data.md (optional) — Existing referral mechanism description,
referral send rate, activation rate from referrals, and opt-out or spam complaint rate.
If not provided, note its absence and proceed with product-brief analysis only.
If either document is missing critical information (no ICP, no value proposition, no
growth stage), ask one targeted question before proceeding. Do not design a loop for
an underspecified product — mechanism choice depends on product structure, not generic
best practices.
Process
Step 1 — Read the Product Brief
Read product-brief.md and optional referral data. Extract:
- What the product does and for whom
- What triggers the aha moment (the first experience of core value)
- Whether the product has any existing sharing or invite behavior
- Current acquisition channels and growth stage
Why: Viral loop design is downstream of product understanding. The mechanism type
you choose (Step 3) depends entirely on whether the product naturally creates sharing
occasions, whether it benefits from more users joining, and whether its core value can
be embedded in an invite.
Step 2 — Assess Viral Capability
Evaluate whether the product has structural conditions for viral growth. Answer these
three questions explicitly:
- Network effect? Does the product become more valuable as more users join?
(Social networks, marketplaces, and messaging apps: yes. Grocery store apps,
single-player tools: typically no.)
- Natural sharing occasions? Does using the product create moments where users
would naturally tell others or share an output? (File sharing, event tickets, payments,
content — yes. Personal productivity tools — often no.)
- Incentive alignment? Can a referral incentive be tied directly to the product's
core value rather than bolted on as unrelated cash?
Verdict: If all three are weak, flag this explicitly. Virality is possible through
word-of-mouth amplification, but embedded referral or instrumented virality will
require heavy investment for modest returns. Recommend focusing on organic and paid
channels (see acquisition-channel-selection-scorer) and returning to viral design
after retention has stabilized further.
Why: Not every product goes viral. The mechanism must match the product's structure.
Designing an embedded referral loop for a product with no network effect and no natural
sharing occasion wastes engineering cycles and can damage user trust if the incentive
feels misaligned.
Step 3 — Classify the Mechanism Type
Based on the viral capability assessment, classify the best-fit mechanism:
Word-of-Mouth Amplification
- Organic sharing driven by genuine product delight — not engineered
- Can be accelerated through Net Promoter Score programs, testimonials, community
building, and public-facing content seeding (e.g., Upworthy's catchy headline system)
- Best for: products with exceptional product/market fit but low natural sharing occasion
- K-factor impact: low to moderate, but high lifetime value per referred user
- Cycle time: long (unpredictable)
Instrumented Virality
- Product features engineered to mechanically expose new users to the product as a
side-effect of core usage
- The invite is embedded in the product's output — users need do nothing extra
- Best for: products whose output is inherently shareable or distributable
(email, documents, event listings, payments, design files)
- K-factor impact: can be very high due to high frequency; payload is often low
- Cycle time: short (continuous, passive)
- Examples: Hotmail email signature, Airbnb Craigslist cross-posting
Embedded Referral
- Explicit "invite friends" program with a designed incentive — bilateral (both parties
rewarded) or unilateral (only the referrer rewarded)
- Requires active user participation — users must consciously invite
- Best for: products with network effects or storage/capacity mechanics where users
genuinely benefit from more people joining
- K-factor impact: moderate, controlled by incentive quality and program visibility
- Cycle time: moderate (days to weeks from invite to activation)
- Example: Dropbox free storage for both referrer and referee
Why: Mechanism classification determines the build complexity, the experiment
sequence, and the failure modes to watch for. Choosing instrumented virality for a
product without shareable output produces expensive engineering work with zero result.
Choosing embedded referral for a product without incentive alignment produces low
conversion and user annoyance.
Step 4 — Map the Closest Case-Study Pattern
Match the product to the canonical pattern that is structurally closest. Extract the
pattern — the structural logic — not the tactic.
Dropbox Pattern (Bilateral Embedded Referral)
- Structural logic: collaborative product + network effect + product-native incentive
(more storage = more value to the user) + near-zero marginal cost of the incentive.
- Apply when: users collaborate with non-users using your product; giving more product
resource as reward costs you little; incentive is hard to compare to cash effort.
- Key insight: the incentive must be product-native. Storage feels more generous than
its cost because users can't easily price it. Cash is easy to benchmark against effort.
Hotmail Pattern (Passive Instrumented Virality)
- Structural logic: every use generates output that reaches non-users; embed the
conversion invitation in that output; make signup require one click and thirty seconds.
- Apply when: the product's output (email, document, invoice, form, booking) is
inherently visible to non-users.
- Key insight: friction at the invitation collapses the funnel. The Hotmail link resolved
to immediate value — free email — in under a minute. Zero user action required to share.
Airbnb Pattern (Cross-Platform Distribution)
- Structural logic: your content lives on your platform; insert it into a higher-traffic
adjacent platform where the target audience already searches; no user action required.
- Apply when: your product has user-generated listings or content; an adjacent platform
hosts your target audience's searches; cross-posting carries manageable platform risk.
- Key insight: instrumented virality through platform arbitrage. Build it, measure it,
but treat it as a channel — not a permanent acquisition architecture.
LinkedIn Pattern (SEO-Driven Profile Virality)
- Structural logic: users create data inside your product; making it publicly indexable
converts your user base into a permanent SEO acquisition surface.
- Apply when: your product has user-generated data others search for by name, expertise,
or topic; making it public does not violate privacy expectations or compliance.
- Key insight: this is a distribution architecture decision, not a referral program.
Loop: user creates data → indexed → non-user finds via search → converts. Cycle time
is long (months) but compounding is durable and zero marginal cost.
Why: Copying tactics without understanding structural logic produces failure.
Dropbox worked not because bilateral incentives are magic, but because file storage
benefits from more users joining, the incentive was product-native, and marginal cost
was near zero. Map the structural logic — then validate fit — before committing to build.
Step 5 — Draft the Loop Diagram with K-Factor Model
Produce a written loop diagram (steps with arrows) and a K-factor model.
Loop diagram format:
[Trigger] → [Share Action] → [Recipient Exposure]
→ [Recipient Conversion] → [New User Activates] → [Loop Repeats]
Label each step with: who acts, what they do, where friction exists, and the drop-off
risk at each transition.
K-factor model (fill in estimates before any engineering is committed):
K = (avg invites per active user) × (invitation-to-signup conversion rate)
Virality = Payload × Conversion Rate × Frequency
K > 1.0 — compounding (rare); K 0.5–1.0 — strong supplement; K < 0.1 — redesign first
Cycle time: How many days from signup to first invite sent? Shorter cycles compound
faster than a higher K with long cycles.
Why: Teams that skip modeling discover after building that K = 0.048 and wonder why
growth did not change. Model first — the estimates reveal whether the mechanism is worth
building or whether the incentive needs redesigning before engineering begins.
Step 6 — Design the First Experiment
Choose the lowest-cost test that validates the most important assumption in the loop.
Hierarchy of testability (cheapest first):
- Incentive/message test — Does the incentive resonate before building? Test with
a landing page or email offer. Compare product-resource reward vs. cash discount.
- Invite mechanic stub — Can you test the sharing flow manually before engineering
it? Have users email friends manually; track conversion.
- Minimum loop build — One sharing path, one incentive, one recipient landing page.
No gamification, no optimization. Just measure K.
Specify: hypothesis ("If we offer [incentive] to both parties, [X]% of active users will
send at least one invite within 14 days"), success K threshold, and three metrics to
track: referral send rate, referral-to-activation rate, time-to-first-invite.
Why: Dropbox discovered the collaboration framing outperformed the storage framing
only through testing — not predictable in advance. LinkedIn found four invites optimal
vs. two or six through experiment. Building the full system before testing the incentive
produces an expensive loop with an unvalidated conversion assumption at its core.
Step 7 — Flag the Viral Spam Trap
Explicitly assess whether the proposed loop design risks crossing from helpful to
annoying. Check all three signals:
Spam trap indicators:
- The mechanism increases payload by requiring or tricking users into sending invites
to their full contact list rather than selected people
- The recipient experience hits a hard authentication wall before delivering value
- Referral activation rate is below 5% (most invites generate no engagement)
- App store reviews or social media mention "spam" in connection with the product
Rules:
- Never increase payload by adding friction-removing dark patterns (pre-checked contact
lists, repeated prompts, misleading invite copy). Short-term volume gains produce
long-term brand damage that is expensive to recover from.
- Measure the recipient experience explicitly before scaling invite volume. An invite
that annoys the recipient destroys two relationships: the recipient's potential
conversion and the referrer's trust in the brand.
- If opt-outs or spam complaints rise while referral volume rises, cut invite frequency
immediately. Growth at the cost of brand is negative-value growth.
Why: BranchOut bypassed Facebook's invite limit and grew from 4M to 25M users in
three months through engineered viral spam. Then lost 4%+ of monthly active users per
day as users experienced a hollow product and their spammed contacts never engaged.
Despite $50M in funding, BranchOut never recovered. The viral spam trap compounds:
every spammed contact is a burned conversion opportunity and a brand impression that
signals low quality.
Step 8 — Emit Deliverables
Write two files:
viral-loop-design.md — Contains:
- Mechanism type (word-of-mouth amplification / instrumented virality / embedded referral)
- Matched case-study pattern and structural logic
- Loop diagram (steps with friction labels)
- K-factor model with estimates for payload, conversion rate, frequency
- Cycle time estimate
- Viral capability assessment verdict (GREEN / YELLOW / RED)
referral-test-plan.md — Contains:
- First experiment hypothesis and success/failure threshold
- Testability hierarchy decision (why this experiment before the full build)
- Measurement plan (metrics, sample size, timeline)
- Spam trap checklist (pre-flight check before scaling any invite volume)
Why: Separating the design document from the test plan allows the design to be
reviewed and revised independently of the experiment setup — and allows the experiment
to be handed to an engineer or growth PM who doesn't need to re-read the full design
reasoning to set up the test.
Key Principles
Virality requires product-level fit — not every product goes viral.
Network-effect and sharing-native products have structural virality advantage. Products
without these characteristics can still grow through word-of-mouth, but embedded
referral loops will underperform unless the product is genuinely must-have and the
incentive is deeply product-native.
Bilateral incentives consistently outperform unilateral.
If only the referrer benefits, the referral is a transaction the recipient did not agree
to. If both parties benefit, the referrer is doing their contact a favor. The social
dynamic changes from extraction to generosity, and conversion improves accordingly.
Dropbox's bilateral storage offer worked because both sides received something they
genuinely wanted — not a promotional discount on something they hadn't asked for.
Cycle time compounds — shorter cycles beat bigger incentives.
A K of 0.6 with a 3-day cycle time produces more compounding over 90 days than a K of
0.8 with a 25-day cycle time. Invest in reducing the time from new-user-signup to
first-invite-sent. Friction in the share flow (too many steps, unclear incentive,
buried UI) extends cycle time. Visibility and integration (Uber's referral prompt on
the active ride screen, LinkedIn's connect prompt at sign-up) compresses it.
K > 1 means compounding growth; K < 1 is an acquisition supplement, not an engine.
K > 1.0 is rare and typically short-lived. A K of 0.5 consistently is excellent — it
means 50% of your growth comes from the loop. Communicate this clearly with leadership.
"Referral" does not mean "free growth that replaces paid acquisition" — it means one
cost-efficient acquisition channel that should be part of a diversified mix.
The viral spam trap destroys brand faster than it acquires users.
Every spammed contact is a burned conversion and a negative brand impression. Dark
patterns (pre-checked contact lists, deceptive invite copy, forced bulk sharing) produce
short-term volume spikes and long-term brand damage. BranchOut is the named cautionary
case. Measure recipient activation rate before scaling invite volume; if it is below 5%,
improve the incentive quality, not the send frequency.
Extract the pattern, not the tactic — then validate the fit.
Dropbox's bilateral storage incentive worked because of four specific structural
conditions: collaborative product, network effect, product-native incentive, near-zero
marginal cost. Copying the bilateral incentive structure without those conditions
produces an expensive referral program with low conversion. Map the structural logic to
your product before committing to any mechanism.
Examples
Example A: Embedded Referral for a B2B SaaS Project Management Tool
Product: A post-PMF project management SaaS. Teams use it together — inviting
teammates is a natural part of onboarding. Network effect is strong: more team members
using it makes it more valuable for the person who invited them.
Viral capability assessment: GREEN. Strong network effect (collaborative by design).
Natural sharing occasion (teammate invitation is required for core use). Incentive
alignment possible (free seats / extra storage / premium features as reward).
Mechanism type: Embedded Referral (bilateral incentive).
Pattern match: Dropbox. The product is collaborative; getting others on the platform
improves the referrer's experience; giving away additional seats has near-zero marginal
cost at volume.
Loop diagram:
[User A joins and activates] → [Prompted to invite teammates during onboarding]
→ [Teammate receives email with credit offer for both A and teammate]
→ [Teammate signs up, activates, experiences aha moment]
→ [Teammate is prompted to invite their own team members]
→ [Loop repeats]
K-factor model:
- Payload: 3.2 (average teammates invited per active inviter)
- Conversion rate: 22% (teammates who accept and activate)
- K = 3.2 × 0.22 = 0.70
- Frequency: once per new user at onboarding (low frequency, but high conversion)
- Virality = 3.2 × 0.22 × 1.0 = 0.70
Cycle time: ~7 days (invite sent day 1, teammate activates by day 7 on average).
First experiment: Test the incentive without building the full system. Email the
top 20% most active users. Offer one extra seat free (bilateral: both users get the
seat) if they invite a teammate this week. Track invite send rate and acceptance rate.
Success threshold: ≥ 30% invite rate from active users contacted, ≥ 15% teammate
acceptance. If below threshold, test a premium feature unlock instead.
Spam trap check: PASS. Invite is addressed to specific teammates by name. Recipient
receives a clear benefit. No dark patterns. Activation rate from teammates is expected
to be high because they are already working with the referrer.
Example B: Instrumented Virality for a Content Publishing Platform
Product: A platform where professionals publish articles and case studies. Each
article is a public page. Non-users can read articles without signing up. The platform
has no social graph or network effect — reading an article is not improved by more
users joining.
Viral capability assessment: YELLOW. No network effect. Strong natural sharing
occasion (articles are meant to be shared). Incentive alignment is weak (bilateral
storage/credits feel disconnected from publishing). Instrumented virality is a better
fit than embedded referral.
Mechanism type: Instrumented Virality (LinkedIn pattern + Hotmail pattern hybrid).
Pattern match: LinkedIn public profiles. Every published article is already a public
page. The growth action is to make those pages fully searchable and to embed a conversion
call-to-action for non-authenticated readers.
Loop diagram:
[User A publishes article] → [Article is indexed by search engines (SEO surface)]
→ [Non-user B finds article via Google search]
→ [Non-user B reads article → sees "Write your own case study" CTA with free account]
→ [Non-user B signs up and publishes their first article]
→ [Article is indexed → new loop pass begins]
K-factor model (adapted — this is SEO-driven, not invite-driven):
- Payload: 0 (no explicit invite; distribution is passive)
- Conversion rate: 2.8% (non-authenticated readers who create an account)
- Frequency: articles are published ~2 times/month per active user; each article
receives on average 340 unique readers per month
- Estimated new signups per active user per month: 340 × 0.028 = ~9.5 new signups/month
- K (monthly, per active user): ~9.5 (a very different K calculation for SEO loops —
the payload is replaced by organic traffic volume)
Cycle time: Long (3–6 months for new articles to rank meaningfully). Invest in
on-page SEO optimization of article templates to compress this.
First experiment: Enable public indexing for the top 100 most-viewed articles.
Check Google Search Console in 30 days for impressions and clicks. Success threshold:
≥ 500 new organic sessions to those articles within 30 days. If yes, make all articles
public by default and instrument the "sign up to publish" CTA prominently on article pages.
Spam trap check: NOT APPLICABLE. This loop has no invite mechanism and generates
no unsolicited contact. Monitor for content quality degradation as sign-ups increase —
a different quality trap, not a spam trap.
References
references/viral-loop-mechanics.md — Detailed K-factor formula derivations, Sean
Parker's virality equation (Payload × Conversion Rate × Frequency), and cycle time
compounding models.references/case-study-patterns.md — Full structural analysis of the Dropbox,
Hotmail, Airbnb, and LinkedIn patterns with applicability criteria.references/viral-spam-trap.md — Detailed BranchOut case study, dark pattern
taxonomy, and detection checklist with metric thresholds.
License
This skill is licensed under CC BY-SA 4.0.
Source book content is referenced under fair use for educational purposes. Attribution:
Ellis, Sean and Brown, Morgan. Hacking Growth. Crown Business, 2017.
Related BookForge Skills
clawhub install bookforge-acquisition-channel-selection-scorer — viral loops are
one acquisition channel category; score them against organic and paid alternatives
before committing engineering resources.clawhub install bookforge-north-star-metric-selector — viral loops must compound
the North Star Metric, not a vanity metric like invites sent or accounts created.clawhub install bookforge-product-market-fit-readiness-gate — virality on a
product that people don't find must-have accelerates churn, not growth. Confirm PMF
before designing any viral loop.clawhub install bookforge-growth-experiment-prioritization-scorer — use the
experiment scorer to rank the viral loop experiment against other growth bets in
the team's backlog before committing build resources.
