growth-experiment git:20260303.8412b01A

Immutable. This exact content never changes and is served at /api/v1/blob/2e9ff1df12753286.

---
name: growth-experiment
description: >
  Design and document a marketing growth experiment. Use when the user says "run a growth
  experiment", "test this channel", "growth test", "I want to experiment with [channel]",
  "traction experiment", "acquisition experiment", "let's test if [channel] works for us",
  "bullseye framework", "which channels should we try", "run a traction test", or wants
  to systematically test a marketing or acquisition channel before committing budget.
---

## Overview

Based on **"Traction"** by Gabriel Weinberg and Justin Mares. The Bullseye Framework: most founders and marketers focus on 1-2 channels they are comfortable with and ignore the 17 others that might work better. Traction's framework forces you to test across the outer ring (all channels), identify the promising middle ring (likely channels), and then go all-in on the one channel in the bullseye. This skill structures a single growth experiment for one channel within that framework.

## Workflow

### Step 1: State the traction channel under test

Weinberg and Mares identify 19 traction channels. Name the one this experiment targets:

```
Channel: [e.g., Content Marketing / SEO, Paid Social, Cold Outreach, Partnerships, PR,
          Viral Marketing, Engineering as Marketing, Community Building, Events, etc.]
Hypothesis: [If we do X on this channel, we expect Y result within Z timeframe]
```

Be specific about the channel variant. "Paid Social" is too broad. "LinkedIn single-image ads targeting [role] at [company type]" is testable.

### Step 2: Define the experiment parameters

Before running anything, commit to these numbers in writing:

```
Budget: $[amount] or [hours] of time
Duration: [number] days/weeks
Target audience: [exactly who will see or receive this]
Volume: [minimum sample size - e.g., 500 ad impressions, 100 cold emails]
```

Traction's rule: a channel test that is too small produces no signal. Underfunded experiments produce false negatives.

### Step 3: Define the success metric and threshold

One metric. Set the threshold before you run the experiment - not after.

```
Primary metric: [e.g., cost per lead, click-through rate, reply rate, trial signups]
Baseline (if known): [current value or industry benchmark]
Success threshold: [the minimum result that would justify investing more in this channel]
Failure threshold: [the result below which you kill this channel for now]
```

If you cannot define success before running, the experiment is not an experiment - it is activity.

### Step 4: Write the experiment brief

```
What we are testing: [specific creative, copy, targeting, or offer being tested]
What we are not testing: [variables held constant so results are attributable]
Tracking setup: [UTM params / pixel / tracking link / CRM tag]
Who is responsible: [name]
Decision date: [date you will review results and decide next action]
```

The "what we are not testing" line is as important as what you are testing. Changing headline and image and audience simultaneously means you will not know what drove results.

### Step 5: Document the expected learning

State in advance: what will you learn from this experiment regardless of whether it succeeds or fails?

- If it succeeds: "We learn that [channel] can deliver [metric] at [cost] for [audience] - and we should scale budget."
- If it fails: "We learn that [channel] does not work at this price point / for this audience / with this offer."

Writing the learning in advance prevents post-hoc rationalization after the results come in.

### Step 6: Log the results and decision

After the experiment completes:

```
Results:
- Primary metric: [actual value] vs. [target]
- Secondary observations: [anything unexpected]

Decision: Scale | Iterate | Kill
Rationale: [1-2 sentences]
Next action: [specific next step with owner and date]
```

Store experiment logs in a shared doc. Companies that win on distribution run more experiments than competitors, not better gut-feel decisions.

## Anti-Patterns

**1. Testing too many variables at once**
Bad: New ad copy, new audience, new landing page, new offer all in the same test.
Good: One variable changes. Everything else held constant.

**2. Calling the experiment too early**
Bad: "We ran 50 impressions and got 0 clicks, so this channel does not work."
Good: Commit to minimum sample size before starting. Do not review until you hit it.

**3. Skipping the pre-experiment success threshold**
Bad: Reviewing results and then deciding what "good" looks like.
Good: "We define success as cost per trial signup under $40 before we start."

**4. No experiment log**
Bad: Running tests in people's heads with no written record.
Good: Every experiment documented with hypothesis, parameters, results, and decision.

## Quality Checklist

- [ ] Specific traction channel named - not a broad category
- [ ] Hypothesis written in "if X then Y within Z" format
- [ ] Budget and duration committed in writing before starting
- [ ] Minimum sample size defined before starting
- [ ] Primary metric is single and measurable
- [ ] Success and failure thresholds set before the experiment runs
- [ ] Variables held constant are explicitly listed
- [ ] Tracking setup documented (UTM, pixel, or equivalent)
- [ ] Expected learning written for both success and failure scenarios
- [ ] Decision date set in advance