growth-experiment-backlog

Growth Experiment Backlog Skill

Growth is a rate of learning, not a list of ideas. This skill turns a pile of "we should try…" into a

prioritised backlog of falsifiable experiments — each tied to a metric, scored for impact and effort,

and shaped as the smallest test that could prove it — so the team ships learning every week, not opinions.

Required Inputs

Ask for these only if they aren't already provided:

• The metric to move — the one growth metric this cycle (activation, conversion, retention, referral).
• The funnel stage / leak — where the opportunity is (pair with [marketing-funnel-plan](../marketing-funnel-plan/SKILL.md)).
• Raw ideas — any experiment ideas already on the table.
• Constraints — eng/design bandwidth and traffic volume (which caps how many tests can reach significance).

Output Format

Growth Backlog: [metric this cycle]

1. Focus — the one metric and the funnel stage, with the current baseline. A backlog without a focus metric is just a wish list.

2. Backlog table — every idea as a hypothesis, scored and sortable:

| # | Hypothesis ("If we ___, then [metric] will ___ because ___") | Stage | Impact | Confidence | Ease | ICE | Status |

|---|---|---|---|---|---|---|---|

(Use ICE (1–10 each) or PXL for less gameable scoring. Sort by score; the top few are this cycle's tests.)

3. Test designs (top 3) — for each top experiment: the exact change, the primary metric + guardrail metrics, the variant(s), the sample size/duration to detect the expected effect, and the definition of done (ship / iterate / kill).

4. Cadence — the weekly rhythm: pick → build → run → read → decide → document the learning back into the backlog (winners and losers both teach).

Quality Checks

• [ ] Every item is a falsifiable hypothesis with the metric it moves and a "because" — not a vague idea
• [ ] Scoring (ICE/PXL) is applied consistently so the backlog is sortable, not cherry-picked
• [ ] Top experiments specify sample size/duration to actually detect the expected effect
• [ ] Each test has guardrail metrics so a "win" can't quietly harm something else
• [ ] There's a cadence that captures the learning from losers, not just winners

Anti-Patterns

• [ ] Do not run experiments without a hypothesis and a target metric — that's just shipping changes and hoping
• [ ] Do not call a test before it reaches the planned sample size — peeking and stopping early manufactures fake wins
• [ ] Do not chase many tiny tests when traffic is low — you'll never reach significance; pick fewer, bigger bets
• [ ] Do not ignore guardrail metrics — a conversion win that tanks refunds or retention is a loss
• [ ] Do not discard losing experiments silently — the learning is the asset; record why it failed

Based On

Growth-process practice — ICE/PXL prioritisation, hypothesis-driven experiments, and the build–measure–learn cadence.