K-Factor and Viral Coefficient

Activate when: user says 'viral coefficient,' 'K-factor,' 'going viral,' 'our product is viral,' 'referral program,' 'invite mechanic,' 'built in sharing,' growth plateauing despite viral elements, or a growth forecast is being justified by virality without a K calculation. Do NOT activate when: product is B2B enterprise (sales-led growth); focus is engagement/retention not new-user acquisition; product has not yet achieved PMF.

Overview

K = i × c, where i = average invites per existing user, c = conversion rate into new activated users. K > 1 → exponential growth; K < 1 → finite ceiling; K = 1 → linear. Most "viral" products have K in the 0.1-0.6 range — social transmission, not a growth engine.

Codified by Steve Jurvetson (DFJ) via the Hotmail case (1996); formalized by Andrew Chen, David Skok, and early Facebook/LinkedIn growth teams.

Composes with aarrr-pirate-metrics (K sits in Referral), network-effects (value vs. user count — different things), mvp (smoke tests cannot establish K), feedback-loops (K > 1 is a specific reinforcing-loop condition).

When to Use

• A product is described as "viral" without an explicit K calculation
• Growth plateauing despite "viral elements" (share buttons, referral programs, invite flows)
• A growth team debating which lever to pull without the K = i × c decomposition
• An investor or founder using "viral" to justify a growth forecast
• Not when: B2B enterprise; focus is engagement/retention; pre-PMF product

Coaching Novices (Adaptive Front Door)

• Engine mode: user has a concrete case → run The Process directly.
• Coach mode: user unfamiliar or no concrete case → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. One-line: virality is K = i × c > 1 — below 1, the product doesn't grow by itself.
2. Check fit: B2B / enterprise / pre-PMF → not this lens yet.
3. Elicit the product and current invite mechanic.

[WAIT — do not advance until user responds]

4. One question at a time: what's i? what's c? what's K? is K stable across waves?

[WAIT — do not advance until user responds]

5. Close: name the specific i lever or c lever to attack.

[WAIT — do not advance until user responds]

The Process

Step 1 — Define units: New user = activated (not signed up). Identify invite event and conversion event. Set cohort window (typically 7-30 days).

Step 2 — Calculate: i = total invites / N users. c = conversions / total invites. K = i × c.

Step 3 — Growth math: K < 1 → ceiling = N₀/(1-K). K = 1 → linear. K > 1 → exponential. (1000 users: K=0.9 → ~10K ceiling; K=1.5 → ~3.3M after 20 cycles.)

Step 4 — Decompose separately: i levers (one-click invite, address-book import, prompt at high-intent moments) vs. c levers (personalize invite, reduce signup friction, make value obvious, activation in <60s). Separate design problems — separate owners.

Step 5 — Cycle time (t): time from activation → first invite sent + time from invite → recipient activates. Reducing t is often more impactful than improving K.

Step 6 — K stability: measure K across waves 1-5. If K < 1 by wave 3, growth has a finite ceiling regardless of early K.

Output: K-Factor Analysis

markdown

# K-Factor Analysis: <product>
- Activated new user definition: | Invite event: | Conversion event: | Cycle window t:
- i: | c: | K = i × c: | Interpretation: <K<1 ceiling / =1 linear / >1 exponential>
- Ceiling or multiplier: | Time to N users:
- i levers — barrier: | test:
- c levers — barrier: | test:
- K wave 1: | wave 3: | wave 5: | Stable above 1?

→ Method in Action: Hotmail, 1996-1998

Pack: K-Factor by Product Type

Product type	Typical K	Dominant lever
Email / messaging (Hotmail, Zoom)	1.5-3+	i (use IS an invite)
Referral-program-driven (PayPal, Dropbox)	0.8-1.8	i (financial incentive; decays)
Consumer SaaS (Notion, Figma)	0.3-0.8	c (collaboration-driven)
B2B SaaS	0.05-0.3	Virality rarely the engine

Applying It Well

• Measure K on activated users — K drops 50-70% vs. signups
• Treat i and c as separate sprints with separate owners
• Check K decay across waves before declaring viral success
• Consent-based mechanics only — aggressive address-book imports risk platform bans

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake move	Reality
[D] "We're viral, look at our share button"	A share button is not a viral mechanic. Calculate K.
[D] K calculated on signups	Recalculate on activated users — K usually drops 50-70%.
[D] "Our K is 1.2, we're set"	K decays across waves. K_wave1=1.2 + K_wave3=0.5 = finite ceiling.
[D] Optimizing i and c as one project	Separate design problems; one vague project moves neither.
[D] Long viral cycle times ignored	K=1.5 at t=60d is far slower than K=1.2 at t=7d. Reduce t.
[D] Treating word-of-mouth as virality	Word-of-mouth boosts c on paid acquisition; K>1 virality is different.
[D] Building viral mechanics pre-PMF	Viral invites bring people who churn if retention is broken.
→ Add [O] entries here after each real use — paste the actual failure pattern	What went wrong and why

Red Flags

• "Viral" used without a K calculation; K on signups not activated users
• K stability across waves not measured; cycle time t not measured
• i and c treated as one optimization; network effects and K-factor conflated
• High K via non-consensual mechanics (platform ban risk)

Verification

• New user = activated, not signed up
• i, c, K calculated separately with cohort + time window stated
• Cycle time t measured
• K stability checked across at least 3 waves
• i and c levers designed and tested separately
• K < 1 acknowledged; growth model reflects finite ceiling; invitation mechanics are consent-based

---

Part of deciqAI Knowledge Skills — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.