Part 01 of the framework. The mindset behind the method: why distribution belongs in the product, the two ideas you have to hold at once, and the one question that changes how a team builds.
Founders, product managers, designers, and developers — anyone who builds digital products and wants them to grow through how people use them, not only through how much you spend to acquire them.
If you have ever shipped a feature and then handed it to a growth team to "find the loop," this part is for you. The premise here is that the loop was supposed to be a question you asked before the feature existed — not a property you go hunting for afterward.
The standard playbook says: build the product, reach product-market fit, then stand up a growth team to bolt virality on as a series of experiments. Referral codes. Invite flows. Share buttons. A/B tests on the onboarding email.
That order is backwards. A viral loop is an architecture decision, not a growth hack. You cannot test your way to a loop the product was never built to support — no amount of optimization adds a sharing surface that the core feature does not naturally produce. By the time the growth team arrives, the most important decision has already been made by default: the product was designed without distribution in it.
The Native Viral Loop Framework makes one demand instead. Treat distribution as a product feature, not a marketing line item — and decide it at the same moment you decide everything else about how the product works. The hub lays out all four parts of the method; this is the mindset the rest of it stands on.
The method rests on two concepts that share a name and do very different jobs. One is a thing you build. The other is a way you think.
A specific mechanism built into the product. Users expose it to others not because we asked them to, but because they can't accomplish their own goal without it. Something concrete you can design, measure, and optimize. New to this? Start with the plain-English guide to what a viral loop is.
A product team's default way of thinking. With every new feature, the team asks: where is the loop opportunity here? Not every feature will have one — but every feature must go through the question. The mechanism is the output; this mindset is what reliably produces it.
The whole philosophy collapses into one question you ask of every feature, in every spec, in every meeting:
"When someone uses this feature, who outside the product encounters it — and why would they step in?"
If a feature has a clean answer, you have found a loop worth designing. If it does not, that is not a failure — it is information. Not every feature carries the loop, but every feature must pass through the question. That habit, applied relentlessly, is the entire difference between a product that markets itself and one that has to be marketed.
The products that grew this way did not add a share button and hope. The act of using the core feature is the act of distributing it. The loop is in the architecture, not the marketing:
Notice what none of these are: a referral coupon, a "tell a friend" prompt, a viral campaign. The user is selfishly pursuing their own goal — book the meeting, get the file, gather feedback — and distribution falls out of that as a side effect. That is what a loop designed into the architecture looks like.
And here is the part most teams miss: a deliberately designed k-factor of 0.4 beats an accidental 0.9 — because you can only improve what you built on purpose. The Native Viral Loop isn't an extra task at the end of a sprint. It's a filter every new feature passes through, from the very first one.
Philosophy sets the mindset. The rest of the framework turns it into a number you can design toward and defend. Next, The Multiplier names what you are actually optimizing — reach × conversion × speed — and explains why a k-factor without cycle time is just vanity.