Growth Framework

The Feature
Review

The deep viral-design pass — for features that already passed the Quick Test and deserve real scrutiny before you build.

The Quick Test is a 60-second gut-check you run in a meeting or a ticket. It is cheap on purpose, and cheap things miss things. The Feature Review is what you run after the gut-check passes and before a single engineer is committed — the last moment the loop costs nothing to redesign.

A feature review is not bureaucracy. It is the difference between a loop you designed and one you hoped for.

This is Part 03b of the Native Viral Loop Framework. Everything here serves one principle from the hub: a viral loop is an architecture decision, not a growth hack. The review is where that decision gets made deliberately, on paper, while it is still free to change your mind.

Read it as the Multiplier, lever by lever

The number you are designing for is the Multiplier — reach × conversion × speed. The Feature Review takes that target apart into the five levers you can actually act on, and asks the hard questions inside each one:

  1. Trigger — the moment inside the feature that fires the loop. No trigger, no loop.
  2. Reach — how many people outside the product get exposed each time it fires.
  3. Value-on-arrival — what the recipient gets before you ask them to sign up.
  4. Conversion — how little stands between an exposed stranger and an active user.
  5. Speed — how fast the cycle completes and seeds the next one.

The Multiplier is a product, not a sum. A zero in any bucket multiplies the whole loop to near zero — so an empty bucket is a finding, not a footnote. Work the five accordions below as your spec. The math behind them lives in the Multiplier; you turn the answers into numbers with the K-Factor Calculator.

The review — five buckets, seventeen questions

Open each lever. Answer in writing, with specifics — a screen, a number, a path — not adjectives. A question you cannot answer concretely is the gap to fix before you build.

1
Trigger
What fires the loop
Map the full journey around this feature — from the moment the user first hears about it to the moment they're done. Where in that flow does something naturally go outside the product?
"Naturally" means the user wants to do it for their own reasons, not because you nagged them. That moment is your trigger.
Who outside the product encounters the platform when this feature is used — and at what point are they pulled into the loop?
Name the person and the context. Before, during, and after — not just the first touchpoint.
Does the feature's value grow as more people use it — and does that pull the user back to fire the trigger again?
A network effect turns a one-shot trigger into a repeating one. If value is flat with numbers, the loop may need redesigning.

Reading the gap: if you can't name a moment that goes outside the product on its own, you don't have a weak loop — you have no loop. Don't optimise the other four buckets; go back and design a trigger, or accept this feature simply doesn't carry one.

2
Reach
How many get exposed
Each time the trigger fires, how many people outside the product are exposed — one, a handful, a whole channel?
A 1:1 share and a post to a 200-person group are wildly different reach. This is the first half of your k-factor.
In what context do they encounter it — a DM, a shared link, a public artefact, an embedded preview?
Context sets both reach and trust. A link from a friend converts differently than a link from a stranger.
How does the product link render on Slack, WhatsApp, and email?
OG tags and thumbnail. An ugly or blank preview silently caps reach by killing the click before value is ever seen.

Reading the gap: weak reach is usually fixable without touching the trigger — widen the share surface, make the artefact public, fix the link preview. If reach is structurally 1:1, your ceiling is low; decide if that's acceptable before you build.

3
Value-on-arrival
Value before signup
What exactly does a new person see when they land through this feature for the first time?
Name the specific screen, email, or preview. Is the value immediately visible, or do they hit a wall?
How much value does that person get before you ask them to register?
The more they receive for free, the higher the conversion. A signup wall before any value is the most common loop killer.
What will that person think in the first second — and why would they want to stay?
If the honest answer is "nothing" or "they wouldn't," the loop leaks here no matter how good reach and trigger are.

Reading the gap: this is the bucket most features fail, and the most expensive to discover after launch. A blank here is not a polish item — it is the thing quietly multiplying your loop toward zero. Fix it before anything else.

4
Conversion
How easily they join
How is the product branded at the touchpoint — and what is the exact path from "stranger" to "new user"?
Branding, CTA, registration. Walk it step by step. Each step is a place people drop.
How many steps separate a new person from becoming an active user?
Count them honestly, including the ones you've stopped seeing. Fewer steps, higher conversion — the second half of your k-factor.
What does the full journey look like on mobile, end to end?
Most shared links open on a phone. A flow that works on desktop and breaks on mobile is converting almost nobody.

Reading the gap: conversion gaps look small and compound brutally — three steps at 70% each leaves you 34%. Cut steps, defer the signup, and test the path on the device people actually use before you ship.

5
Speed & Measurement
Cycle time & proof
How long is one full cycle — from a user firing the trigger to a new user firing it themselves?
Speed is the lever everyone forgets. A k of 0.5 every day beats a k of 1.2 every quarter. Same loop, different velocity.
What will you track — shares per user, click-through, signup rate, first-action rate — and is the instrumentation built before launch?
If you can't measure each bucket, you can't improve the one that's broken. Wire it in now, not after.
After 2–4 weeks: how many new users came organically, and how do you know it was this loop?
Attribution you can defend. "It feels viral" is not a finding.
What is the measured viral coefficient for this feature — and if you could improve one bucket, which and why?
k = new users one existing user brings. Feed your numbers into the calculator and let the math name the weakest lever.

Reading the gap: a slow loop isn't a failed loop — it's an untuned one. Shorten the cycle (fewer waits, instant artefacts, real-time delivery) before you touch reach or conversion, because speed compounds harder than either. Then quantify it with the K-Factor Calculator.

What the review is really for

In eighteen years of shipping products I have watched the same thing happen over and over: a team gut-checks a feature, agrees "yeah, that could go viral," and ships. Three weeks later the loop is flat and nobody can say which bucket failed — because nobody wrote them down.

The Feature Review fixes that for the cost of an hour. It forces the loop out of your head and onto paper, lever by lever, while changing it is still free. Most features die quietly in Value-on-arrival — a signup wall in front of the value — and that's a one-line fix on paper and a rebuild after launch. That gap between "we hoped" and "we designed" is the entire return on this hour.

Not every feature survives the review, and that is the point. A feature with no trigger isn't a failure of the review — it's information you got for free. New to the vocabulary? The plain-English guide to what a viral loop is sets the terms; the Multiplier sets the target.

Feature Review FAQ

When should I run the Feature Review?
After a feature passes the 60-second Quick Test and before you commit engineering. The Quick Test tells you a loop is plausible; the review tells you whether it's actually designed — while it still costs nothing to change.
How is it organised?
Into the five levers of the Multiplier: Trigger, Reach, Value-on-arrival, Conversion, and Speed. Every one of the seventeen questions lives under the lever it tests.
What does a gap in one bucket mean?
The Multiplier is a product, not a sum. A zero in any bucket multiplies the whole loop to near zero — so a blank under, say, Value-on-arrival is the most likely thing quietly killing your loop, not a minor item.
Is this just a growth checklist?
No. A checklist confirms tasks are done; the review interrogates a design decision before it's built. It's the difference between a loop you designed and one you hoped for.
Quantify it — the Calculator → Run it with your team — the Kit →
← Back to Framework
← Previous
Quick Test
Next →
K-Factor Calculator