Skip to content
Learn · Measure & improve

How to build an experimentation roadmap

An experimentation roadmap is a prioritized backlog of tests to run next, scored so a small team spends its few experiment slots on the highest-expected-value ideas. It turns a pile of loose hunches into a ranked queue, sets a review cadence, and forces the hardest decision: what to kill.

Updated 8 Jul 20266 min readBy fromHello
Key takeaways
  • Prioritization matters most when you can run only a few tests — each slot spent on a weak idea is a stronger one skipped.
  • Score ideas with ICE (Impact x Confidence x Ease) to rank a backlog fast; reach for RICE when reach varies widely. Both are estimates, not truth.
  • Build the backlog from where your funnel leaks and from your activation aha moment, not from a wish list.
  • Review on a fixed cadence and kill losers on schedule — expect most tests to come back flat.

Why prioritization is the whole game

A small team runs maybe two or three experiments a week; only high-velocity teams reach ten to twenty — and even that is a stretch when traffic is thin. With so few slots, the real cost of a mediocre test is not the test itself; it is the stronger idea you skipped to run it. A roadmap exists so each slot goes to the highest-expected-value idea, not the loudest voice in standup. Owning that ranked queue is a large part of what a growth PM does.

Build the backlog from your funnel and aha moment

Do not start from a wish list. Start from where the funnel leaks. Walk each step — visit, signup, activation, retention, revenue — and write down the biggest drop-offs; each one is a testable hypothesis. Weight the steps nearest your activation aha moment heavily, since a user who never activates rarely retains. Treat any aha you name as a correlate to validate, not a proven cause: an activation signal predicts retention, it does not prove you caused it. Each leak becomes a backlog row — the hypothesis, the metric it should move, and a rough guess at how much.

Score ideas with ICE

ICE, popularized by Sean Ellis, scores each idea on three axes from 1 to 10: Impact, how much it could move the metric; Confidence, how sure you are it will work; and Ease, how little effort it takes. Multiply the three, sort descending, and work top-down. It is fast because it is three honest guesses. That speed is also the catch: the score is an estimate, not a fact. Read a 512 and a 480 as roughly equal, not as a ruling. The number orders the list; it does not decide for you.

Plot each idea by impact and effort. Quick wins — high impact, low effort — get your scarce slots first; time sinks rarely earn a seat.

When reach varies, use RICE

ICE breaks down when two ideas differ wildly in how many users they touch. RICE, from Intercom, fixes that by adding Reach and dividing by Effort: (Reach x Impact x Confidence) / Effort. A tooltip seen by every visitor and a tweak buried in a settings page get scored on the same footing. The trade is speed for a reach estimate you have to source. The same warning applies — multiplying four made-up numbers can produce false precision, so keep the inputs coarse and revisit them as you learn.

FactorICERICE
FormulaImpact x Confidence x Ease(Reach x Impact x Confidence) / Effort
SpeedFast — three 1-10 guessesSlower — needs a reach number
Best forTriaging a large backlog quicklyIdeas whose reach differs a lot
Main trapEase hides true effortFalse precision from soft inputs

Review on a cadence, and kill losers

Set a fixed rhythm — a weekly or biweekly review where you read results, promote winners, and retire the rest. Killing on schedule is the discipline that keeps the queue moving; a test left running is a slot left occupied. Be honest that most tests come back flat, and at low traffic many are underpowered before they start — often the right call is not to A/B test at all but to ship and monitor, as testing with low traffic covers. When you do measure, a clean read usually needs a holdout group, which a platform like customer.io or a self-hosted engagement stack can hold aside for you.

FAQ

Common questions

  • How many experiments should a small team plan for?

    Fewer than you think. Two or three well-run tests a week is a realistic ceiling for most small teams, and even strong growth teams rarely top ten to twenty. Plan the roadmap around your real slot count, not an aspirational one.

  • Is ICE or RICE better?

    Neither is 'better' — they answer different questions. Use ICE to triage a large backlog fast when ideas touch similar numbers of users. Switch to RICE when reach varies widely enough to change the ranking. Both are estimates; treat the score as a sort order, not a verdict.

  • How often should I re-prioritize the backlog?

    On the same cadence you review results — weekly or biweekly for most teams. Re-score when a test finishes, a metric shifts, or a new leak surfaces. Scores drift as you learn, so a roadmap that is never re-ranked is already stale.

  • What if a test does not reach significance?

    That is the common case at low traffic. Do not keep it running forever hoping the line moves — decide up front how long you will wait, then ship the version you would ship anyway and monitor guardrail metrics. Reserve formal A/B tests for changes big enough, or pages busy enough, to actually resolve.

See the platform the team runs.

Related guides
Early access

Put your growth teamon autopilot.

Early access opens gradually, so the team tunes to real use cases. Small teams with big ambitions go first.

500+ already on the list

Not ready to share an email? It's open source. Run it yourself today. View on GitHub

No spam. One email when your spot opens. Unsubscribe at any time.