Experiment Prioritization, the Complete Guide

Deciding what to test first, the discipline that turns a pile of ideas into a sequence that compounds. From the ICE, PIE, and RICE frameworks to a healthy cadence, the most thorough prioritization guide we know how to write.

By David Schaefer · Last updated June 2026

What experiment prioritization is

Every growth team faces the same happy problem, far more ideas than capacity to test them. Prioritization is how you decide which of the dozens of possible experiments to run first, second, and not at all, given limited traffic, engineering time, and attention. It sounds mundane, but it is one of the highest-leverage decisions a testing program makes, because running the wrong tests first squanders the scarcest resource you have, time, on low-value bets while high-value ones wait.

Scoring frameworks exist to make this decision rational and transparent rather than political. By scoring each idea on a few consistent dimensions, impact, confidence, effort, reach, they turn a chaotic debate into a comparable ranking, so the backlog is ordered by expected value instead of by who has the most authority or the loudest voice in the room. The frameworks are not magic, the scores are estimates, but they impose a consistent, honest conversation that dramatically improves which experiments actually get run.

This guide takes you from the basics to an operator-level command of experiment prioritization. It pairs closely with hypothesis development, A/B testing, and marketing analytics.

Why sequencing matters

The case for prioritization is simply that resources are finite and ideas are not. A team can run only so many experiments per quarter given its traffic, engineering bandwidth, and focus, so every slot spent on a low-value test is a slot not spent on a high-value one. Because the returns on experiments are wildly unequal, a few big winners typically drive most of the gains, getting the sequence right, running the likely big winners first, has an outsized effect on how much a program achieves in a year.

Sequencing also affects learning, not just wins. Some experiments unlock others, a foundational test about a core assumption can reshape the whole backlog, so running it early changes everything downstream. And momentum matters, early wins build the credibility and support a testing program needs to survive, so a smart sequence balances likely impact with the learning and momentum a test generates. Prioritization, done well, is therefore not just triage but strategy, it shapes the trajectory of everything the program learns and earns.

Prioritization also protects focus, which is scarcer than ideas. A team that says yes to every plausible test spreads its traffic and attention so thin that nothing reaches significance and nothing ships, whereas a team that ruthlessly sequences runs fewer tests properly and learns more. Saying no, or not yet, to a decent idea so a better one can run first is the essence of the discipline, and it is harder than it sounds precisely because the rejected ideas are usually good too, just not the best use of the next slot.

The ICE framework

ICE is the simplest and most popular prioritization framework, scoring each idea on three dimensions, Impact (how much it would move the metric if it works), Confidence (how sure you are it will work), and Ease (how little effort it takes to run), typically each on a one-to-ten scale. You combine the three, often by averaging or multiplying, into a single ICE score and rank the backlog by it. Its speed and simplicity made it the default for high-tempo growth teams.

ICE's strength is also its weakness, it is fast and intuitive, but the scores are subjective, and two people can score the same idea very differently. That is acceptable, even useful, because the point is the conversation the scoring forces, why do you rate the impact a nine when I rate it a four, surfaces the assumptions worth debating. ICE works best for teams that test frequently and want a lightweight way to keep the backlog ordered without heavy process, and it pairs naturally with high-tempo experimentation.

The PIE framework

PIE, popularized in conversion optimization, scores ideas on Potential (how much improvement is possible on this page or flow), Importance (how valuable the traffic or audience it affects is), and Ease (how difficult the change is to implement). It is especially suited to prioritizing which pages or funnel steps to test, because Importance captures that a small lift on a high-traffic, high-value checkout page beats a large lift on an obscure one.

In practice PIE and ICE are close cousins, both three-factor, both balancing upside against effort, with PIE leaning toward page and funnel prioritization and ICE toward general idea prioritization. The choice between them is often just which vocabulary fits your team and your work, a conversion-optimization team auditing pages may find PIE's Potential-and-Importance framing more natural, while a broad growth team may prefer ICE's Confidence dimension. Either way, the underlying logic, rank by expected value relative to effort, is the same.

The RICE framework

RICE, popularized by the team at Intercom, adds a dimension and a formula. It scores Reach (how many people the change affects in a period), Impact (how much it affects each, often on a fixed scale), Confidence (a percentage reflecting how sure you are), and Effort (the work required, usually in person-months), then computes reach times impact times confidence, divided by effort. The explicit reach term and the division by effort make RICE more rigorous than ICE, rewarding high-reach, low-effort ideas systematically.

That rigor costs time, RICE requires estimating reach and effort in real units, which is more work than a quick one-to-ten gut score, so it suits teams that want more defensible prioritization and have the data to estimate reach. The trade-off between ICE and RICE is essentially speed versus rigor, ICE for fast, frequent, lightweight prioritization, RICE when the stakes justify more careful estimation. Many teams start with ICE and graduate to RICE as their program matures and their estimates get better.

Other frameworks

The three famous frameworks are not the only options. A simple value-versus-effort matrix, plotting ideas on two axes and favoring the high-value, low-effort quadrant, is often enough and requires no scoring at all. Weighted scoring lets a team define its own factors and weights, useful when standard frameworks miss something important to the business. And methods borrowed from product and agile practice, like WSJF (weighted shortest job first) and MoSCoW (must, should, could, won't), can be adapted for experiment backlogs.

The proliferation of frameworks can itself become a distraction, teams sometimes spend more energy debating which framework to use than running tests. The honest truth is that the specific framework matters far less than having one and applying it consistently, because the value comes from the disciplined, comparable conversation, not from the particular formula. The best framework is the simplest one your team will actually use every cycle, and a lightweight method used consistently beats a sophisticated one applied erratically or abandoned.

Scores are a tool, not a verdict

The most important thing to understand about prioritization frameworks is that their scores are structured opinions dressed as numbers. Impact and confidence are guesses, reach and effort are estimates, and multiplying guesses together does not make them facts, it just produces a precise-looking number built on imprecise inputs. Treating the resulting score as an objective verdict, running whatever tops the list without thought, is a misuse that can be worse than no framework at all, because it launders subjective judgment as false rigor.

The right use is as a forcing function for a consistent, honest conversation. The score's real value is making people articulate and compare their assumptions, why is your confidence high, what is the impact actually based on, and ranking ideas on the same dimensions so the comparison is fair. After the framework has surfaced the assumptions and produced a ranking, human judgment still makes the call, accounting for things the score misses, strategic fit, learning value, dependencies, momentum. The framework informs the decision, it does not replace the decider.

This is also why the scoring conversation should include diverse perspectives rather than one person filling in a spreadsheet alone. An engineer sees effort the marketer underestimates, an analyst sees impact the designer overstates, and surfacing those disagreements during scoring is where the real value lies, the ranking improves because the assumptions behind it were stress-tested. A score produced in isolation carries the blind spots of one person, while a score debated briefly by a small cross-functional group is far more trustworthy, and the debate itself spreads understanding of why the chosen tests matter.

The backlog and a healthy cadence

Prioritization is not a one-time sort but part of an operating rhythm. The best programs maintain a steady backlog of well-formed hypotheses, hold a regular prioritization pass (often weekly or biweekly) to re-rank as new ideas and results arrive, run a fixed number of live tests matched to their traffic and capacity, and keep a ritual for capturing learning from each result. This cadence turns prioritization from a debate into a habit, and the backlog into a living queue rather than a stale list.

The metric that matters for this rhythm is the velocity of validated learning, how many meaningful, well-run tests the team completes and learns from per period, not the raw count of tests or the win rate. A program optimizing for test count will run trivial tests to pad the number, and one optimizing for win rate will avoid bold bets, whereas one optimizing for validated learning runs the highest-expected-value experiments and learns from every outcome. Prioritization, embedded in a healthy cadence, is what keeps that learning velocity high.

A light operating model ties it together, a single shared backlog everyone can add to, a short recurring meeting to re-score and pick the next tests, clear ownership of each running experiment, and a simple log of hypotheses, results, and lessons. None of this needs heavy tooling, a spreadsheet and a standing thirty-minute meeting suffice for most teams, and the goal is to make prioritization a fast, regular habit rather than an occasional, agonized exercise. The teams that sustain this rhythm out-learn far better-resourced teams that test sporadically and prioritize by whoever shouts loudest.

Choosing a framework

Choosing among the frameworks is mostly about fit and stage. A young, fast-moving team testing frequently usually wants ICE or a simple value-effort matrix, the lightweight options that keep the program moving without heavy estimation. A conversion-optimization team auditing pages may prefer PIE's framing, and a mature program with good data and higher stakes may graduate to RICE for its rigor and explicit reach. There is no universally correct choice, only the one that fits how your team works.

Whatever you choose, the meta-rule is consistency. The comparability that makes prioritization valuable only exists if you score every idea the same way every cycle, so switching frameworks constantly or applying one erratically destroys the benefit. Pick the simplest framework your team will actually sustain, apply it consistently, and revisit the choice rarely. The discipline of consistent application, far more than the sophistication of the formula, is what turns prioritization from a ritual into an advantage.

Where it goes wrong

The central mistake is false precision, treating a score built from guesses as an objective verdict and running the top of the list mechanically, which both over-trusts the number and invites gaming, since anyone can inflate an impact or confidence score to push a pet idea up the ranking. Closely related is bikeshedding the framework itself, spending more energy debating ICE versus RICE than running experiments, when the framework choice matters far less than consistent use.

The other failures are about the wrong objective and a stale process. Optimizing for raw test count produces a flood of trivial tests, optimizing for win rate produces timid ones, and only optimizing for validated learning produces the high-expected-value experiments that compound. And a backlog that is never re-prioritized as results and ideas arrive quickly goes stale. Prioritization rewards the team that scores consistently, treats the number as a structured opinion, keeps a living backlog on a steady cadence, and applies judgment on top, and it punishes the team that mistakes a tidy spreadsheet for good decisions.

Frameworks and methodologies

• ICE, Impact, Confidence, Ease, the simplest and fastest, popular in high-tempo growth testing.
• PIE, Potential, Importance, Ease, common in conversion-optimization page prioritization.
• RICE, Reach times Impact times Confidence divided by Effort, more rigorous, popularized at Intercom.
• Value-versus-effort matrix, a lightweight two-axis sort favoring high-value, low-effort ideas.
• Weighted scoring, WSJF, and MoSCoW, custom and agile-derived methods for special cases.
• The hypothesis backlog and high-tempo testing cadence, the operating rhythm prioritization lives in. See hypothesis development and A/B testing.

This catalog is a living reference, linked where a fuller guide exists. The frameworks differ in detail but share one purpose, a consistent, honest way to decide what to test first.

A classic, high-tempo testing and ICE

The high-tempo testing methodology that Sean Ellis and the growth community popularized is built around exactly this discipline, a steady backlog of hypotheses, scored quickly with ICE, run at a high cadence, with every result captured as learning. ICE was chosen deliberately for its speed, because in high-tempo testing the cost of an elaborate scoring process would slow the very velocity the method depends on, and a fast, consistent, good-enough ranking beats a slow, precise one. The approach turned prioritization from an occasional debate into a weekly habit.

The transferable lesson is that prioritization should serve velocity, not become a bottleneck. The growth teams that compound do not agonize over perfect scores, they apply a simple framework consistently, sequence the best bets, and keep the testing engine running, accepting that a fast, honest ranking and quick learning beat slow perfectionism. You do not need their tooling to copy it, keep a hypothesis backlog, score it consistently with ICE or a simple matrix, run what rises to the top, and capture what you learn.

See how prioritization pairs with hypotheses →

Explore all related growth and performance marketing case studies →

Tools in our toolkit

• Experiment planner, to capture, score, and sequence the backlog.
• A/B test sample size and test duration estimator, inputs to the effort and reach you score.
• Conversion lift calculator, to read the impact a prioritized test delivered.

Browse all RGM tools →

Learn experimentation with us

Related Prioritization and Experimentation Books to Check Out

• Hacking Growth, Sean Ellis and Morgan Brown, high-tempo testing and ICE in practice.
• Inspired, Marty Cagan, prioritization in product teams.
• Measure What Matters, John Doerr, focusing on what matters most.
• The Lean Startup, Eric Ries, validated learning and what to test.
• Essentialism, Greg McKeown, the discipline of doing fewer things better.

Voices worth following

• Sean Ellis, who created ICE and popularized high-tempo testing. LinkedIn · X.
• Brian Balfour, founder of Reforge, on growth process and prioritization. LinkedIn · X.
• Elena Verna, growth advisor on experimentation cadence. LinkedIn · X.
• Lenny Rachitsky, writer of Lenny's Newsletter on product and growth prioritization. LinkedIn · X.

Frequently asked questions