%20scilla.studio.svg)
You can raise your K-factor without ever launching a referral program. The fastest gains usually come from loops you already have but aren't measuring: shared documents, public outputs, integrations that carry your branding, and invitations baked into the core workflow. Improve any of those three things (outputs per user, conversion per output, or how fast the loop cycles) and K goes up. A referral program is just one loop, and often not your best one.
If you haven't read the companion piece, start with Understanding K-Factor in Digital Product Growth. It lays out the generalized formula this article builds on. Here we take the same thesis, that virality is more than a referral form, and turn it into things you can actually ship.
K-factor is your viral growth multiplier: how many additional users each new user generates through the product itself, before their influence runs out, expressed as K = (Outputs per user) × (Signups per output). K = 1.0 means each user brings exactly one more; below 1.0 means virality amplifies your other channels but doesn't sustain growth on its own.
The formula most people quote (invitations × conversion rate) only describes a referral program. The one that actually generalizes is:
K = (Outputs per user) × (Signups per output)
An "output" is any artifact that exposes a non-user to your product: a shared doc, a Loom video, a "Powered by X" badge, a workspace invite, a published template. That generalization is the whole point, because it means most of your viral surface area has nothing to do with a referral program. A referral form is one output type with usually-mediocre conversion. So the real question is "which of our loops is cheapest to move, and by how much?" rather than "should we build referrals?"
Here's the interesting part: because you sum K across loops, you don't need one heroic viral mechanism. Three nothing-loops at 0.08 each sum to 0.24, squarely mid-band for B2B (0.1 to 0.3), and they beat one referral program you bolted on and nobody uses.
Before you try to improve K, know what "good" even looks like, because it's wildly different by model, and chasing a consumer number inside a B2B tool will just make you feel bad.
| Model | K-factor (avg) | What it means |
|---|---|---|
| B2B SaaS / B2B tech | 0.1 to 0.3 | B2B virality is usually weak. Anything above 0.3 is unusually strong unless the product has built-in collaboration loops. |
| Consumer apps | 0.3 to 0.7 (rarely >1) | K > 1 is true viral growth and extremely rare. Even 0.5 is considered very strong. |
Sources: Reforge, Andrew Chen.
So if you run a B2B tool sitting at K = 0.15, you're already at the middle of the band, and the realistic target is nudging toward 0.3, not engineering some consumer-grade viral explosion. (And yes, that means a "disappointing" 0.2 might actually be fine, and the energy is better spent shortening cycle time, which we cover below.) These are context, not targets: a collaboration-native product can reasonably beat the B2B band because sharing is the workflow, not an add-on.
Before building anything, audit. Most products are already viral in ways nobody measures because there's no referral dashboard pointing at it. Walk the four loop types from the pillar article and ask, for each: does using our product already expose a non-user?
What's a loop you're not counting? Any of these you can't currently put a number on. That gap is your roadmap: you can't improve what you haven't instrumented. Measure each loop's outputs-per-user and signups-per-output separately, then sum. The honest version of this is messy: signups-per-output is hard to attribute and you'll be estimating. That's fine. The goal is enough signal to know which loop is worth a quarter of work, not a perfect number.
Every loop's K is just outputs × conversion. So there are exactly two levers per loop, and they have very different costs.
Raise outputs per user. Get more artifacts created, and get them created sooner. Concretely: - Make the shareable output the natural end of the core workflow, not a buried "Share" button. If finishing the job is producing a public artifact, output volume tracks usage for free. - Default to shareable. A doc that's private-by-default produces zero distribution loop; a doc with a one-click public link produces many. - This is where retention does double duty (see Lever 4).
Raise signups per output. This is usually the cheaper win because volume is already there: - Fix the recipient's landing experience. Someone clicks a shared doc and hits a wall of signup friction, so most bounce. Let them see the value first, sign up second. - Make the branded touchpoint legible. "Made with X" converts terribly if nobody knows what X does; a one-line "X helps teams do Y, try it free" on the landing converts better. - Reduce the signup itself to the minimum needed to deliver value.
Here's what I actually think: most teams reach for "more outputs" (build a template gallery! add a UGC feature!) when the recipient-side conversion on their existing outputs is the thing quietly leaking out the bottom. Audit conversion-per-output before you build new output types. It's the difference between a roadmap quarter and an afternoon of landing-page work.
Here's the lever I keep watching teams skip: K is only half the equation. Cycle time (how long the loop takes to complete, from a new user joining to that user generating the next signup) matters just as much. The combined growth rate is:
Monthly growth rate = K / (cycle time in months)
So which grows faster: a product at K = 0.8 with a 60-day cycle, or one at K = 0.6 with a 10-day cycle?
Product B grows ~4.5× faster with the lower K. The shape of the curve is set by the ratio, not by K alone. Adobe Sign (formerly EchoSign) is the cautionary tale: it took roughly 8 months for one paid customer to produce the next, often after multiple exposures, a respectable-looking K throttled by a brutally slow cycle.
The key insight: shortening your cycle from 30 days to 15 days has the same effect as doubling your K-factor, and it requires zero new viral mechanism. You're just making an existing loop turn faster. Cycle time breaks into three parts you can each attack:
No referral program touches any of these, which is exactly why they sit untouched: there's no dashboard nagging you about cycle time, so it quietly costs you compounding growth while you're busy building features.
You don't need a referral dashboard to put a number on K. Measure each loop separately: outputs per user (artifacts created per month) × signups per output (new users each artifact drives), then sum across loops. Attribution is approximate; aim for enough signal to prioritize, not a perfect number.
This is the part most growth guides skip. Andrew Chen's argument is that the most reliable way to drive viral growth is to increase retention and engagement, and the cycle-time math is why. A retained, frequently-active user spins your loops over and over; a churned user spins them once and disappears. In my honest opinion, if your retention is weak, every sharing feature you build is leaking out the bottom.
Put it together: improving Day-7 or Day-30 retention raises output frequency (more loop turns per user) and extends the window over which each user keeps generating outputs. You get a K improvement and a cycle-time improvement from one workstream. For reference, healthy B2B retention sits around 50 to 70% Day-1, 40 to 60% Day-7, and 25 to 35% at 90 days. (Sources: Pendo, Amplitude, Userpilot.)
If your retention is weak, fixing it is often a better "viral" investment than any sharing feature, because there's no point shortening cycle time for users who aren't around for the next cycle.
None of this means referral programs are bad. For some consumer products they're the dominant loop. But they're frequently the wrong first move for B2B and for any product whose users already produce shareable outputs: you're adding a brand-new loop with uncertain conversion and an incentive cost, while a higher-volume, zero-incentive loop sits un-optimized next to it. Build the referral program when your existing loops are instrumented, optimized, and you've confirmed there's a real "who would I invite, and why" motivation, not as a reflex because K looks low.
The fastest way to know which lever is yours is to see your numbers against the bands. The free benchmark tool charts your K-factor, retention, and unit economics against B2B and consumer ranges in a couple of minutes. Its growth simulation then lets you drag a K-factor-versus-cycle-time slider to see how each compounds over 12 months, so you can sanity-check whether chasing K or shortening the cycle moves your curve more. Benchmarks are context, not targets; the tool is built to give you that context fast.
Can you increase K-factor without a referral program? Yes. A referral program is one viral loop. Most products already have content/distribution loops (shared docs, videos, exports), casual-contact loops (branded touchpoints), and integration loops generating signups. Instrumenting and optimizing those usually moves K more than adding a referral form, with no incentive cost.
What's a good K-factor for B2B SaaS? B2B K-factor averages 0.1 to 0.3. Above 0.3 is unusually strong unless the product has built-in collaboration loops. Consumer apps run higher, 0.3 to 0.7, and K above 1 is extremely rare. (Sources: Reforge, Andrew Chen.)
Is cycle time more important than K-factor? They multiply, so neither dominates: growth rate = K / cycle time in months. But cycle time is usually more neglected and cheaper to improve: halving it (30 to 15 days) has the same effect as doubling K, with no new viral mechanism required.
How does retention affect K-factor? Retained, frequently-active users spin your viral loops more times and over a longer window, raising both outputs-per-user and effective loop velocity. Improving retention often does more for viral growth than building a new sharing feature.
How do I measure K when there's no referral form to track? Measure each loop separately: outputs per user (artifacts created per month) × signups per output (new users each artifact drives), then sum across loops. Attribution is approximate; aim for enough signal to prioritize, not perfect numbers.
