Part 02 of the framework. The number you deliberately design toward — and why most teams measure the wrong half of it.
Most teams treat the viral coefficient as a scoreboard — a number you read off the dashboard after launch and hope is high. The framework treats it as a design target: the value you point a feature at before you build it, the same way you'd set a latency budget or a conversion goal.
And the target is bigger than k-factor. The full Multiplier has three factors, not two:
reach × conversion × speed
Reach is how many non-users each user exposes the product to. Conversion is the share of those who step in. Together they are the textbook k-factor. Speed — viral cycle time — is the underrated third factor that turns a coefficient into actual growth. Design for all three, or you are designing for a number that doesn't move.
Here is the opinion this page exists to defend: a viral coefficient reported without its cycle time is a vanity metric. It tells you how much a loop spreads and says nothing about when. And "when" is where the compounding lives.
Think of it as a multiplier you apply on a clock. A loop that completes every two days fires fifteen times a month. A loop with a stronger coefficient but a thirty-day cycle fires once. The slower loop can have nearly double the k and still lose — badly — because the fast loop compounds while the slow one is still on its first pass.
Halving your cycle time is usually worth more than raising your k-factor — and it's almost always cheaper to design in.
One illustrative pass, to make the point concrete — not a math lesson:
| Same 30 days, 1,000 seed users | k-factor | Cycle time | Cycles fired | Where it lands |
|---|---|---|---|---|
| The fast loopdesigned for speed | 0.5 | 2 days | ~15 | ~1,990 |
| The strong loopdesigned for reach only | 0.9 | 30 days | 1 | ~1,900 |
Same window. The weaker coefficient wins on speed alone — and converges to its ceiling almost immediately, while the slow loop is still warming up. Want the formula behind this and the benchmarks for each value? That's the viral coefficient guide — the 101 this page builds on.
The other reason to treat the Multiplier as a target and not a readout: you can only improve what you built on purpose.
An accidental high k-factor — the kind that shows up because of one quirk of your early-adopter network — has no handles. You don't know which factor is carrying it, so you can't defend it in a planning meeting, can't reproduce it in the next feature, and can't stop it from quietly decaying as your network saturates. It is luck wearing a metric's clothes.
A deliberately designed 0.4 has three handles you can grab: reach, conversion, and speed. Each is a known mechanism in the product. You can instrument it, tune it, and explain it. That is what makes a modest designed loop more valuable than a strong accidental one — it is the start of a curve you control, not a number you got away with.
Designing toward the Multiplier means choosing which of three levers to lean on for this feature. They are not equal, and they don't cost the same.
Get the product in front of more non-users per user. The cleanest way is structural: make exposure a byproduct of the workflow, the way every Calendly link or shared Figma file is its own demo. The trap is chasing reach with begging — more invite prompts, more "share to unlock" — which lifts the count and tanks the quality.
Make more of the people who encounter the product step in. This is the warmth of the invitation and the friction of the front door: show value before the signup wall, carry the inviter's context onto the landing, strip the form to nothing. Conversion is the lever most teams under-invest in because it lives at the seam between two teams — the one that ships the loop and the one that owns onboarding.
Compress the time from "user joins" to "their activity produces the next user." The highest-leverage move here is to pull the viral trigger earlier — if sharing naturally happens on day seven, find the version of the feature where it happens in the first session. Speed is the lever you design in at architecture time and can almost never bolt on later, which is exactly why it gets skipped.
The trade-off rule: reach and conversion fight each other — pushing volume usually lowers quality, and vice versa — while speed multiplies whatever the other two produce. When in doubt, spend your design budget on the clock.
For the per-lever tactics in depth — the invite-friction checklist, the conversion playbook, the cycle-time techniques — the viral coefficient guide goes deep. This page is about which lever to pull and why; that page is about how.
A target only matters if it survives contact with a real feature. The Multiplier connects straight back to the framework's central question — "when someone uses this feature, who outside the product encounters it, and why would they step in?" Reach is the who, conversion is the why would they step in, and speed is the when the question is silently asking.
Next you'll turn this target into a decision you can make in sixty seconds, and then a number you can defend.