AARRR and guardrails
Read a five-step funnel with its step conversions, find the step worth a week of work, and write the three guardrails a launch may not cross.
On this page
A funnel is a count at each step and the conversion between steps, and the step conversions are the whole point: they say where users are lost, which the totals never do. Guardrails are the opposite kind of number — not something to push, but a line the product may not cross while it is being pushed. A launch needs both written down, with numbers, before the first percent of traffic sees the feature.
The funnel, with numbers
AARRR names five steps: acquisition, activation, retention, revenue, referral. For the self-serve tier of the drafting assistant, one quarter looks like this: 10,000 teams sign up for the trial; 4,000 connect a help desk and send one draft (activated); 2,200 are still sending drafts in week 4 (retained); 600 start paying; 90 refer another team.
Step conversions: 40% activate, 55% of those retain, 27.3% of those pay, 15% of those refer. Overall, 6% of sign-ups pay. That last figure is what the board sees, and it is useless for deciding what to build, because it could be fixed at any of four places. The step view is what decides.
Each step has one definition and the definition is the hard part. "Activated" means connected a help desk and sent one draft, not "logged in twice", because a team that has not sent a draft has not met the product. "Retained at week 4" means sent a draft in days 22–28 after sign-up, measured on the cohort that signed up four weeks ago, which the cohorts lesson explains is the only honest way to measure it. A step whose definition moves is a step whose conversion cannot be compared week to week.
Which step to work on
The naive reading picks the lowest conversion: referral at 15%. Doubling it to 30% adds 90 referrals, which at the same 6% paying rate is about 5 paying teams. The arithmetic for every step is the same shape — what does one more point at this step produce at the end?
Activation, 40% to 45%: 500 more activated teams, of which 55% × 27.3% pay, so about 75 more paying teams, from a single onboarding fix. Retention, 55% to 60%: 200 more retained, 27.3% pay, about 55 more. Revenue, 27.3% to 30%: 60 more paying teams directly. Referral, 15% to 30%: about 5.
The step worth a week is the one with the most volume above it and the cheapest fix, and that is almost always activation. The cheapest check is the one the SQL lesson's funnel query answers: of the 6,000 teams that signed up and never sent a draft, how many connected a help desk? If 5,000 never connected one, the problem is the connection step and the fix is an integration, not a model.
A funnel of counts hides timing. Retention at week 4 for the cohort that signed up last week is unknown, not zero; a dashboard that averages this week's cohorts into the retention figure drags it down and makes a steady product look like it is decaying. Measure each step on the cohort that has had time to reach it.
The mistake: a launch with no lines
The common launch plan reads "roll out to 5%, watch latency and complaints, then expand". It names the right things and gives none of them a number, so at 5% when p95 latency goes from 6 s to 9 s the team argues about whether that is bad, and the argument is decided by whoever wants the launch most. By 25% the complaint rate has doubled and the roll-back is a judgement call made in a meeting rather than a rule written a month before.
The fix is a table. Three guardrails, each with the figure it must not cross, where it is measured and what happens when it crosses:
p95 latency to last token under 6 s, per tenant, per hour. The agent feels the tail, not the mean, which is the argument of the tail-latency lesson; a feature whose p50 is 2.1 s and whose p95 is 6 s is at its line already, so any regression crosses it. Crossing pauses the ramp.
Complaint rate under 2 per 1,000 replies sent, measured weekly on the ramp cohort. At 10,000 replies a day in the 5% stage that line is 20 complaints a day, which is few enough to read every one. Crossing rolls the ramp back one stage.
Cost per untouched resolution under $0.03. Assume the token bill is $54,000 a month, the figure the cost lesson derives for 200,000 drafts a day: $54,000 ÷ 6,000,000 drafts = $0.009 a draft. Only 0.40 acceptance × 0.90 no-reopen = 0.36 of drafts become untouched resolutions, so each one carries the cost of about three drafts: $0.009 ÷ 0.36 ≈ $0.025 per resolution today. A $0.03 line is a 20% buffer. It is measured daily from the bill, and crossing it caps drafts per ticket at one and pages the PM, because a cost guardrail breaking usually means a retry loop, not a pricing change.
Why guardrails are not inputs
None of the three multiply into the North Star. Lower latency does not produce more untouched resolutions; a lower complaint rate does not either. They are the terms of the deal under which the inputs may be pushed. The distinction decides how each is treated: an input gets a roadmap and a weekly target; a guardrail gets a threshold, an alert and a named person. Putting a guardrail on the roadmap ("reduce p95 latency this quarter") is fine when it is already crossed; otherwise it is work that moves no output.
The launch lesson runs the ramp from 5% to 25% to 100% behind exactly this table, and the readout at each stage is the three guardrails first, then the funnel. A launch that reads the funnel first and the guardrails second ships the thing that got 600 teams paying while it was breaking a contract clause.
In an interview
The execution question here is "sign-ups are up 20% and revenue is flat; what happened?" The answer is the funnel: a flat revenue count with 20% more at the top means a conversion fell somewhere, and the segmentation is by step first, then by cohort. Say the step definitions out loud, say which step you would query first and why, and give the arithmetic for what one point at that step is worth at the bottom.
The launch question is "how would you roll this out?" and the answer is a percentage ramp with three named guardrails, each with a number and an action.
The mistake that loses points is reading the overall conversion — "6% of sign-ups pay, we should improve conversion" — without a step, or naming guardrails without thresholds. "We'd watch latency" is not an answer; "p95 under 6 s per tenant, measured hourly, or the ramp pauses" is.
Check yourself
1. Activation falls from 40% to 32% in one week while sign-ups double. Is the product broken?
Probably not. Doubled sign-ups usually means a new acquisition channel, and a new channel brings teams that activate at a different rate; the blended figure fell because the mix changed. Split activation by channel before touching the product: if the old channel still activates at 40%, the product is fine and the question is whether the new channel is worth its 20%.
2. At the 25% stage, p95 latency is 5.8 s, complaints are 1.9 per 1,000 and cost per resolution is $0.032. Do you proceed to 100%?
No. One guardrail is crossed, and the rule says a crossed cost line caps drafts per ticket and pages the PM, not "proceed because the other two held". The $0.032 against $0.025 last month is a 28% rise with no price change, which smells like retries; find the loop, fix it, hold at 25% for a week of clean numbers. The evidence that would let the ramp continue is a daily figure back under $0.03 for seven consecutive days.
3. The referral step is 15% and marketing proposes a referral bonus to lift it to 30%. Worth a quarter?
90 more referrals at the funnel's 6% overall paying rate is about 5 paying teams; even if referred teams pay at twice the rate, it is 10. The same quarter on activation, 40% to 45%, is about 75. Decline unless the bonus costs nothing to build; the evidence that would change it is a referred-team conversion rate so much higher that 90 referrals produce 75 paying teams, which is 83%, and nothing converts at 83%.