BootcampCapstone · Deliverable 5

Growth Funnel Analysis & Experiment Design

Builds on Topic 8.

What you'll produce

A growth analysis for Tempo that does the single most valuable thing a growth marketer does: maps the AARRR funnel with real conversion rates, names the worst leak with evidence (not a hunch), and turns that diagnosis into one prioritized A/B experiment you'd actually run next week. It ends in a clean if/then/because hypothesis, a control vs. one-change variant, the one metric the test should move, the honesty cautions that keep you from fooling yourself, and a note on how the result feeds the next round. This is the artifact that proves the Topic 7–8 skills — funnel-first thinking, finding the biggest leak instead of pouring more traffic into a leaky bucket, and disciplined, data-honest experimentation — and it's the piece interviewers probe hardest, because "sign-ups are flat, diagnose and fix it" is the most common growth case there is. Done well, it shows you can reason about a business under uncertainty, not just write copy.

Instructions

  1. Lay out Tempo's AARRR funnel as a table with numbers. Pick a sensible monthly cohort size and put a count and a conversion rate on every step: Acquisition (visitors → sign-ups), Activation (sign-ups → reached first value), Retention (activated → still active at week 4), Referral (active → invited a teammate), Revenue (trial → paid). Invent realistic numbers — a few hundred paying teams growing on word-of-mouth means modest top-of-funnel traffic and a free trial — but make them internally consistent so each count flows from the one above it: row N's count, times its conversion rate, equals row N+1's count. Always declare your denominator. A conversion rate is meaningless until you say "of what" — signup→activated divides by sign-ups, not by visitors. If a stage is genuinely measured off a base other than the immediately prior row (e.g., "% of activated teams that pay," which is the number most B2B teams actually track, because solo trials never convert), then label it that way and don't pretend it's a stage-to-stage step. The fastest way to fail this deliverable is a table where the percentages silently change denominators and the counts stop reconciling.
  2. Define each stage in Tempo's terms, not generic ones — and write activation down once. Say what "activation" actually is for Tempo (e.g., a team that connects a real project and gets ≥2 teammates logging against it in week 1), not "the aha moment." A vague funnel can't be diagnosed. Whatever wording and rate you choose for activation, you will reuse them verbatim in Deliverable 6's dashboard — D5 and D6 must name the same activation definition, the same rate, and star the same worst leak. Do not let activation mean one thing here and something else there; pick it now and carry it forward.
  3. Find the worst leak and prove it. Don't just pick the lowest number — pick the stage with the worst drop relative to what's healthy for that stage, and say why. Compare each step's conversion to a rough benchmark. Name the one leak you'd fix first and write 2–3 sentences of reasoning (what the number is, why it's the bottleneck, why fixing it beats fixing the others). Remember Topic 7: a leak early in the funnel wastes everything downstream, and retention is the foundation — a leak there means acquisition just fills a leaky bucket.
  4. Form a hypothesis about why that leak exists, grounded in the product and the ICP from Deliverable 1 (the agency owner / ops lead at a 10–50-person creative shop). The fix should target the cause, not the symptom.
  5. Design one A/B experiment to test it. Write the hypothesis as "If we [one change], then [one metric] will [improve], because [reason]." Define control (current experience) and variant (exactly one change). Name the primary metric it should move and a guardrail/counter-metric so a "win" doesn't hide harm elsewhere.
  6. Specify the honest setup. Who's eligible, how they're split (random), and roughly how long / how much volume before you'd trust the result — given Tempo's modest traffic, be honest that a clean test may take weeks, and resist "peeking" and stopping early. Note one thing the test won't tell you and how you'd follow up.
  7. Close the loop. In one or two lines, say what you'd do if it wins, if it loses, and what the next experiment in the sequence would be — growth is a loop, not a single shot.
  8. Stay coherent with the portfolio. The leak you choose and the fix you design should fit the positioning (Deliverable 2) and the AI-forecasting launch (Deliverable 3) — one continuous Tempo story.

Worked example

(Product: Tempo — B2B time-tracking & capacity-planning SaaS for 10–50-person creative agencies. 14-day free trial, then paid per seat. Numbers below are a single representative monthly cohort.)

Tempo's AARRR funnel — one monthly cohort

Every count below flows from the one above it (count × conversion = next count), and each conversion states its denominator so the rates never silently switch bases. Two stages — Retention and Revenue — are reported "of activated," because that's the cohort Tempo's GTM team actually steers on: a solo trial that never activated was never going to pay or stick, so measuring retention and paid-conversion off all sign-ups would just dilute both numbers with teams that never saw the product work. Where a row is based on activated rather than on the immediately prior row, the table says so and shows the stage-to-stage equivalent in parentheses so the chain still reconciles.

One activation definition, used everywhere. This worked example fixes activation as "connect a real project + invite ≥2 teammates in week 1," at 37.5% (signups → activated) — and that single definition and rate are reused, word-for-word and number-for-number, when this funnel reappears in Deliverable 6's dashboard. Pick your activation definition and rate once here; do not let them drift between the two deliverables. (See the callout under the table.)

StageDefinition (Tempo-specific)CountConversion (denominator stated)Rough benchmarkRead
AcquisitionUnique visitors to tempo.com who start a trial sign-up2,560 visitors → 320 sign-ups12.5% of visitors → signup10–15% for warm/word-of-mouth trafficHealthy
ActivationTrial team that connects a real project and invites ≥2 teammates in week 1 (the "aha": owner + 2 teammates logging against a live project, so they finally see the whole team's hours in one view)120 activated37.5% of sign-ups → activated40–60% for a well-onboarded B2B toolWeak — worst leak
RetentionStill actively logging time in week 4 of the trial/subscription78 retained65% of activated → retained60–75% of activated usersHealthy (of those who activate)
ReferralAccount that invites at least one additional teammate or external collaborator21 referred27% of retained → invited20–30% of retainedAcceptable
RevenueTrial converts to a paid plan50 paid~42% of activated → paid (equiv. ~64% of the 78 retained → paid, stage-to-stage)25–50% of activated trialsHealthy (of those who activate)

Reading the denominators. Acquisition, Activation, and Referral are each computed off the immediately prior row (320 × 37.5% = 120; 78 × 27% ≈ 21). Retention and Revenue are quoted of activated — the base Tempo's team manages to — but they still reconcile to the chain: of the 120 activated, 78 retain (65%) and 50 pay (≈42%). Stated stage-to-stage, paid is 50 of the 78 retained (≈64%); essentially every retained team converts, and the handful that pay without retaining to week 4 wash out. The point of labeling the base explicitly is that "42% conversion" is a different claim from "42% of activated convert" — name which one you mean, every time.

Lock this leak across D5 and D6. Activation — "connect a real project + invite ≥2 teammates in week 1," at 37.5% signup→activation — is the worst leak, and it is the one leak the rest of your capstone hangs on. Deliverable 6's dashboard must restate this exact definition and this exact rate and star this same stage — it does not get to re-define activation (e.g., "3+ teammates logging time") or quote a different number (e.g., 32%). If you invent your own cohort here (you should), then your D6 must mirror your own D5 line, not this worked example. Both rubrics demand it: D5 is graded on an internally reconciling funnel, and D6 is graded "consistent with Deliverable 5." A dashboard whose activation row contradicts the funnel that produced it fails both — so write the definition and rate down once, here, and copy them forward verbatim.

How to read it: Tempo's word-of-mouth traffic arrives warm and converts to sign-up well (12.5% of visitors), and the teams that activate retain and pay at strong rates (65% of activated retain, 42% of activated pay). The funnel doesn't have a traffic problem or a pricing problem. It has an activation problem: only 37.5% of teams that sign up ever connect a real project and get teammates logging against it — below the 40–60% a well-onboarded B2B tool should hit. Nearly two-thirds of every hard-won sign-up evaporates before they ever see what Tempo is for.

Worst leak: Activation (signup → activated), with reasoning

The lowest number in the funnel is referral (27%), but the lowest number isn't the worst leak — referral is roughly at benchmark and sits late in the funnel, so fixing it would help very few teams. Activation is the worst leak for three reasons. (1) It's the largest gap-to-benchmark: 37.5% vs. a 40–60% norm means we're leaving 2.5–22.5 points on the table at the widest part of the funnel — 320 teams pass through here, far more than reach referral. (2) It's upstream, so it multiplies: every activated team retains and pays at healthy rates, which means each additional activation is worth roughly the same downstream revenue as our existing best teams — fixing activation lifts retention, referral, and revenue counts all at once, while fixing referral lifts only referral. (3) It matches the product story: Tempo's whole value is seeing the team's capacity in one view, and that value literally cannot land until a real project is connected and multiple teammates are logging against it — a solo trial user is staring at an empty capacity board. Pouring more word-of-mouth traffic into the top right now would be the classic mistake from Topic 7: filling a bucket with a hole in it.

Why the leak exists (hypothesis about the cause): Tempo activates only when the owner connects a real project and gets ≥2 teammates logging against it, but the person who signs up is usually the agency owner or ops lead (our ICP) — and they are not the bottleneck. After they sign up, nothing in the product helps them stand up a project or pull the rest of the team in. Onboarding treats the sign-up as a single user, so the owner logs their own hours against no real project, sees a half-empty board, and concludes "this isn't doing much yet." The leak isn't motivation or price — it's that first-week onboarding never prompts the owner to connect a project or invite the team, so the two actions that together create value rarely happen in the trial window.

The experiment

  • Hypothesis (if / then / because): If we add a single guided "Set up your first project + invite your team" step to the post-sign-up onboarding (a starter project pre-scaffolded, teammates pre-filled from the owner's email domain, one click to send the invites), then the signup→activation rate will rise from ~37.5% toward ~48%, because activation requires connecting a real project and ≥2 teammates logging against it, and today nothing prompts the owner to do either during the trial window.
  • Control (A): Current onboarding — owner signs up, lands on an empty dashboard, no invite prompt.
  • Variant (B): Identical onboarding plus one change: a "Set up your first project + invite your team" screen immediately after sign-up — a starter project ready to name, with colleagues from the same email domain suggested for one-click invite. Only this onboarding step differs — same copy, pricing, dashboard, and trial length everywhere else, so any difference is attributable to it. (We treat "connect a project + invite ≥2 teammates" as one onboarding step so the test still isolates a single change, rather than confounding two separate variants.)
  • Primary metric: Signup → activation rate (% of new trial teams that connect a real project and invite ≥2 teammates in week 1).
  • Guardrail / counter-metric: Trial→paid conversion of activated teams must not drop, and invite spam complaints / opt-outs must not spike — we want more activated teams, not invites blasted at people who never wanted them. If activation rises but paid conversion of those teams falls, we activated the wrong way.
  • Setup & honesty: New trial sign-ups are randomly split 50/50 at account creation; assignment is sticky to the account. Given ~320 sign-ups/month split into two arms of ~160, a swing from 37.5% to ~48% is detectable but not in a few days — at this volume we'd plan to run 4–6 weeks to gather enough teams for a result we'd trust, because small samples lie and an early "win" off 20 teams is likely noise. We won't peek and stop early the moment it looks good; we set the duration up front and read it at the end.
  • What it won't tell us: The A/B test shows whether the invite step lifts activation, not why teams who still don't activate stay stuck. We'd follow up with 5 short interviews of variant teams that received the invite prompt but still didn't activate, to find the next leak.
  • Closing the loop: If it wins (activation up, guardrails clean), we ship it to 100% and the next experiment targets the new worst leak — likely "owner set up the project and invited the team, but the teammates never logged against it," which points at a teammate-onboarding nudge. If it's flat or negative, we've learned the bottleneck isn't the project-setup/invite prompt itself (maybe owners complete it but teammates ignore the invite), and we pivot the next test to the teammate's first-time experience. Either way the result sharpens the next round — growth is a loop, not a single shot.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

  • Quantified AARRR funnel — 1: stages listed without numbers, or counts that don't reconcile (a conversion rate whose denominator isn't stated, or percentages that silently change base so the counts stop chaining) · 2: all five stages with counts and conversion rates that reconcile — each count flows from the one above, and any rate measured off a base other than the prior row (e.g., "% of activated") is labeled as such rather than passed off as a stage-to-stage step · 3: reconciling, denominator-explicit numbers plus Tempo-specific stage definitions (e.g., what "activation" concretely is) that make the funnel diagnosable.
  • Worst-leak diagnosis with reasoning — 1: picks a stage with no real justification, or just the lowest number · 2: names one leak and gives a plausible reason · 3: justifies the leak against benchmarks and funnel logic (upstream impact, retention-as-foundation), and explicitly says why fixing it beats fixing the others.
  • Cause hypothesis grounded in product + ICP — 1: no theory of why the leak exists · 2: a plausible cause · 3: a cause tied to Tempo's product mechanics and the Deliverable-1 ICP, so the fix targets the cause not the symptom.
  • Clean if/then/because hypothesis + one-change A/B — 1: vague, no metric, or multiple changes confounded · 2: proper if/then/because with a clear control vs. one-change variant · 3: sharp hypothesis with an explicit mechanism and a variant that provably isolates a single change.
  • Primary metric + honest guardrail — 1: missing or only a vanity metric · 2: names the metric the test should move plus a guardrail · 3: well-chosen primary metric and a genuine counter-metric that would catch a "win" that hides harm.
  • Data-honest setup (random split, enough volume, no peeking) — 1: flawed or absent · 2: random split with a nod to sample size · 3: addresses randomization, realistic duration given Tempo's modest traffic, and explicitly refuses early stopping; notes one limit + follow-up.
  • Closes the loop & fits the portfolio — 1: one-shot test, disconnected from the rest, or an activation definition/rate that won't survive into D6 · 2: states win/lose next steps and names an activation definition + rate concrete enough to reuse · 3: defines the next experiment in the sequence and stays coherent with the positioning (D2) and AI-forecasting launch (D3) — one continuous Tempo story — with an activation definition and worst-leak rate stated precisely enough that Deliverable 6 can restate them verbatim and star the same leak.