You bolted a referral program onto your product and... nothing. People don't share because you asked — they share when the loop is designed into the moment t...
编程
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,' g...
它能做什么
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. More: deciqai.com/c/k-factor-viral
技能文档
K-Factor and Viral Coefficient
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.
- One-line: virality is K = i × c > 1 — below 1, the product doesn't grow by itself.
- Check fit: B2B / enterprise / pre-PMF → not this lens yet.
- Elicit the product and current invite mechanic.
[WAIT — do not advance until user responds]
- 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]
- 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
# K-Factor Analysis:
- Activated new user definition: | Invite event: | Conversion event: | Cycle window t:
- i: | c: | K = i × c: | Interpretation: 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 — 227 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/c/k-factor-viral · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.
Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/k-factor-viral.json
相关技能
Activate when: user says 'our growth is stalling and we don't know why,' 'product and marketing are arguing about whose fault it is,' 'where is our funnel br...
Activate when: user asks 'how close are we to critical mass', 'why did growth suddenly explode (or collapse)', 'will this trend keep spreading', 'is there a...
When the user wants to create, optimize, or analyze a referral program, affiliate program, or word-of-mouth strategy. Also use when the user mentions 'referral,' 'affiliate,' 'ambassador,' 'word of mouth,' 'viral loop,' 'refer a friend,' 'partner program,' 'referral incentive,' 'how to get referrals,' 'customers referring customers,' or 'affiliate payout.' Use this whenever someone wants existing users or partners to bring in new customers. For launch-specific virality, see launch.
Activate when: a founder wants customers to bring customers; 'how do we get referrals / word of mouth', designing a referral program, improving virality; loo...
Use to reverse-engineer why a piece of content went viral (or overperformed) — yours or someone else's — and extract the repeatable mechanism to apply to you...