Growth experiments

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Test: one-step signup vs. current flow

  P15pt

• Test: activation checklist in the empty state

  P23pt

• Test: pricing-page social proof block

  P23pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Experiment moves to 'Running'

  Then

  Set a check-back date and notify the experiment owner

• When

  Experiment moves to 'Learned'

  Then

  Append the result to the learnings list and share it

The terminal column is Learned, not Shipped, and that is the argument. A growth programme's compounding asset is the accumulated set of things you now know to be false about your users, and most teams destroy it by celebrating wins and quietly deleting losses. The soft cap of four on Running is the practical counterpart: concurrent tests on the same funnel interact, and a team running eleven experiments at once is not learning faster, it is producing results it cannot attribute.

1. 1.Score the backlog, then argue with the score

   Impact, confidence and effort ratings are a sorting aid, not a decision procedure — they are three guesses multiplied together, and the confidence term is doing most of the work. Use the score to surface the top handful, then pick from those by judgement. Teams that treat the number as authoritative end up running whatever is easiest to estimate optimistically.

2. 2.Write the hypothesis and the success metric before you build

   In Designing, state what you believe, what change you expect, and the single metric that will decide it — before the variant exists. A metric chosen after seeing the data is not a test, it is a search. Also write down what result would make you stop pursuing this direction entirely, which is the part almost nobody writes.

3. 3.Check whether the test can possibly reach significance

   Estimate the traffic through the surface and the effect size you would need, and do that arithmetic before Running rather than after. A large fraction of experiments at small and mid-sized companies cannot detect anything smaller than an enormous effect, and running them anyway produces confident conclusions from noise. If the numbers do not support a test, ship the better guess instead.

4. 4.Hold Running at four and mind the interactions

   The cap is about attribution as much as focus. Two experiments touching the same signup flow will contaminate each other, and if both are running you can no longer say which change moved the number. Keep concurrent tests on separate surfaces where you can, and write down when you cannot.

5. 5.Write the learning even when the result is null

   Especially then. A null result is expensive information you have already paid for, and it is exactly what stops the same idea being re-proposed every six months by someone new. Record what you tested, what happened, and what you now believe — one paragraph, in Learned, searchable.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You do not have the traffic. This is the most common and least acknowledged disqualifier. Below roughly a few thousand conversions per variant per test, most experiments cannot resolve realistic effect sizes, and a programme built on underpowered tests produces a stream of confident, wrong conclusions. Run qualitative research and ship considered changes instead.
• You have an experimentation platform. Statsig, Optimizely, GrowthBook and their peers own assignment, exposure logging, sequential testing and the statistics. Tracking experiment state on a board beside them is fine; duplicating the results is how two systems come to disagree about whether something won.
• The change is obviously correct. Testing whether a broken link should be fixed, or whether an error message should be legible, is a way of delaying an improvement in order to generate a chart. Reserve experiments for decisions where you genuinely do not know the answer.
• The test has fairness or trust implications. Differential pricing, tests on vulnerable user groups, and anything touching consent are not purely empirical questions. They need a judgement call and often a legal one before the experiment is designed, not a review of the result afterwards.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Statsig, Optimizely and GrowthBook

  These are the actual experimentation layer: randomised assignment, exposure tracking, guardrail metrics, and statistics that account for peeking and multiple comparisons. They answer the question this board only records the answer to, and the difference matters because the statistics are where most homegrown programmes go wrong.

  Where Statsig, Optimizely and GrowthBook is better: Assignment and analysis are better there without qualification, and the sequential-testing and guardrail features prevent errors a board cannot even detect. This template is the planning layer beside such a platform, not an alternative to one.

• Notion

  The common setup is a Notion database of experiments with a page each for hypothesis, design and readout, which is a good fit because an experiment write-up is a document. What it lacks is the state discipline — nothing enforces that Running has a check-back date or that Analyzing eventually resolves.

  Where Notion is better: For the readout as a readable, linkable artifact with embedded charts and context, a page beats a card. Many teams reasonably run the pipeline on a board and keep the write-ups in a wiki.

• A spreadsheet

  Most experiment logs are a sheet, one row per test, and it works surprisingly well for a small programme: sortable by score, easy to filter, trivially shareable. The reason to move is that the sheet has no relationship to the work, so the experiment's implementation issues live somewhere else entirely.

  Where A spreadsheet is better: A sheet is faster, sorts better, and computes scores without ceremony. For a growth team of two running one test at a time, it is a genuinely reasonable choice over any board.