This module assembles the full experimentation operating system: ICE prioritisation, the eight-column backlog, pre-registered decision rules, vanity metric audits, capacity allocation under constraint, and the 90-day growth roadmap that integrates the whole engine.

Impact, Confidence, and Ease (ICE) Prioritisation

Prioritisation is the fundamental problem for growth teams when ideas outnumber execution bandwidth. Growth planning typically starts with tens or hundreds of ideas, but teams can realistically ship only 5 to 7 experiments per month, or a maximum of 20 per quarter. Under 10 percent of executed experiments actually yield a positive impact on core business metrics. Without a structured framework, teams risk selecting incorrect ideas based on opinions rather than evidence. The Impact, Confidence, and Ease (ICE) framework solves this problem by using a transparent, repeatable score on a 1 to 10 scale to discipline executive judgment.

ICE Framework Components

Definitions and key questions for the three dimensions of the ICE framework are structured as follows:

The overall ICE score is computed as the average of the three individual scores. Backlog items are sorted by their ICE scores in descending order to determine execution priority.

Impact Scoring Discipline

Impact scores must be anchored strictly to the primary growth constraint. A high score on a non-constraint metric does not count toward business growth, regardless of how much that metric improves.

If an experiment does not touch the primary growth constraint, it cannot receive a high impact score. For example, if the primary constraint is activation, an A/B test of a pricing page designed to lift conversion from free trial to paid by 20% is downstream from activation. If only 34% of users activate, the conversion lift is applied to a thin slice of users. Thus, the pricing experiment should be scored only a 5 or 6 on impact, preserving scores of 9 for experiments that directly target the core activation rate.

Confidence Scoring Discipline

Confidence is the most commonly abused score in growth frameworks, frequently inflated by founders or team leaders to justify preferred ideas. Scoring must be bound to objective evidence.

The core discipline check requires that if the team cannot state the evidence for a confidence score in a single sentence, the score is capped at a maximum of 5. Statements like "it just feels right" or "everyone is doing this" automatically cap the score at a maximum of 4 or 5.

Ease Scoring Discipline

Ease counts the full cycle of building, measuring, and analyzing, not just the technical build time.

The core trap of ease scoring is ignoring the time required to collect data. An experiment that takes 2 days to build but requires 6 weeks to yield a statistically credible signal cannot be scored a 9. It must be scored a 6 at best, as time-to-usable-result is what dictates prioritization.

ICE Prioritization backlogs (Clairo vs. Zoko)

The ICE framework adapts to different product funnels by anchoring to brand-specific constraints.

Clairo's third-ranked idea, prebuilt meeting templates by type of sales call, also targets activation and scores an ICE of 7.3, which is why the homepage hero copy test (ICE 6.7) ranks only fourth despite being the easiest idea on the list. The framework protects the team from confusing speed with importance: the easiest experiment to ship is not automatically the most important one to run.

Failure Modes in ICE Execution

Teams often degrade the ICE framework into an opinion list through four primary execution errors:

A spread diagnostic check determines team scoring honesty: a real backlog sheet contains a diversified range of ICE scores (some 8 to 9, some 4 to 6, some 2 to 3). If the entire backlog is clustered between 7 and 9, the framework has failed.

Growth Backlog Design

An experiment backlog is not just a list of ideas; a list is a repository where ideas accumulate and are eventually abandoned. A backlog is a system with defined rules, columns, and rituals that determines what runs, what stops, and what learnings are captured.

The typical list-to-graveyard trajectory follows a predictable timeline: in Month 1 the team opens a fresh "growth backlog" sheet and accumulates around 30 ideas within 2 weeks; by Month 3 the list holds 80 ideas but only 4 have been run and half the team has stopped opening the sheet; by Month 6 the sheet is abandoned entirely. If the backlog cannot answer "what runs, what stops, and what did we learn" within 30 seconds, it is a graveyard, not a system.

Lifecycle Stages of an Experiment

Every experiment in a functioning backlog must sit in one of five distinct stages:

Experiment movement is strictly unidirectional. An experiment cannot return to the idea stage; whether it fails or succeeds, it must move forward to the closed stage with captured learnings. If a row cannot be assigned to one of these five stages, it does not belong in the backlog.

Eight Columns of a Universal Backlog System

The universal backlog system relies on eight columns to turn a spreadsheet into an operating tool:

These 8 columns work for B2B and B2C without modification: the structure is universal, and only the brand-specific thinking inside the cells changes.

Clairo Working Backlog Sheet (Template Walkthrough)

The reference implementation is a Google Sheets workbook with 12 experiment rows, 8 columns, and 2 tabs (the backlog plus a decision scorecard tab listing the top 5 experiments by ICE score with their pre-registered thresholds):

• Live ICE formula: The ICE cell computes the average of the impact, confidence, and ease inputs. Changing one input (for example, confidence from 7 to 4) instantly updates the score and the rank order, so a disputed score is resolved by editing one cell rather than debating the total.
• Conditional formatting: The top rows are highlighted automatically when the ICE score exceeds 7.5; highlights move as the team rescores.
• Stage filter as the WIP view: Filtering the stage column to "active" shows only 4 rows (the WIP limit) while 18 scored experiments wait in line, so on Monday morning the team sees what is running, not the full idea pile.
• Example pre-registered rule: "Scale if the sign-up to record rate hits 45% or above, kill below 36%, iterate in between", agreed before the experiment went active.
• Example learning entry: "Reduced onboarding from 6 steps to 3. Activation rose from 34% to 41%. Effect held in week 2 and week 4 cohorts." Six months later, a proposed onboarding redesign builds on this row instead of re-running the test.

Built correctly, the decision-making becomes structural: the team does not have to remember to do the right thing, because the sheet's structure does the remembering.

WIP Limits and Rescoring Discipline

Work in Progress (WIP) limits prevent the backlog from becoming an unmanageable list. Successful growth teams establish a strict WIP limit of 3 to 5 active experiments at one time.

Exceeding 5 simultaneous active experiments introduces three operational complexities:

1. Signal Noise Compounds: Multiple simultaneous experiments run on the same cohort, making clean attribution of metric movement impossible.
2. Attention Spreads: Team focus degrades, leading to delayed implementation and missed details.
3. Learning Rates Fall: The team executes more tests but lacks the bandwidth to extract deep, actionable insights from each.

Rescoring must be completed regularly as confidence is a dynamic variable. However, active rows must never be rescored midway through execution; experiments must run to their pre-registered decision rules to avoid bias.

Growth Rituals Cadence

The backlog is driven by a weekly ritual consisting of two short meetings:

No new commitments or experiments are allowed to be added midway through the week.

Backlog Design Pitfalls

Growth backlogs generally fail within the first eight weeks due to four common pitfalls:

Decision Rules

A decision rule is a contract written before an experiment runs that determines what its outcome means after the data is collected. Pre-registering decision rules prevents post-hoc negotiation of outcomes. Without a pre-registered rule, different departments will interpret the same data to support their personal preferences, resulting in indecision.

Experiment Outcomes Comparison

Every experiment outcome must map to one of three possible decisions:

Excluding the iterate option forces premature closure of marginal experiments. Conversely, default iteration can become an excuse to avoid admitting failure. The rule must strictly define the iterate boundaries.

Four Components of a Decision Rule

Every pre-registered decision rule requires four locked components:

Worked derivations of the two thresholds:

• Scale threshold from the hypothesis: If the hypothesis projects activation rising from 34% to 45%, the scale threshold sits at or slightly below the projection (for example, 42% to 45%). If the threshold must be set much lower than the hypothesis projected, the hypothesis itself is wrong and should be rewritten before the experiment runs.
• Kill threshold from cost-benefit: If lifting activation only to 36% would generate roughly 2 lakhs of revenue benefit while the experiment costs roughly 2 lakhs in engineering and infrastructure, any result at or below that point is a net loss, so 36% becomes the kill threshold.

Case Studies Decision Rules (Clairo vs. Zoko)

Applying pre-registered contracts across B2B and B2C brands yields distinct decision paths:

Constraints of Bounded Iteration

To prevent iteration from becoming an excuse for infinite unscientific testing, three constraints must be applied:

1. Single Variable Change: Version 2 of the experiment must modify exactly one element of the first version. If multiple variables are changed, the team cannot attribute metric movement to a specific cause.
2. New Pre-Registered Thresholds: Version 2 does not inherit the rules of Version 1. It must have its own thresholds and bounds written and locked before launch, and these are often stricter than the first version.
3. Iteration Cap: A maximum of 2 iterations (up to Version 3) is permitted. If Version 3 still lands in the iterate band, the experiment must be killed because the underlying mechanism lacks sufficient strength.

Failed vs. Successful Kills

Killing an experiment is a positive outcome if it compounds team knowledge:

An example of a successful kill learning for Zoko is: "Photo prompt mechanism at this cadence does not move the 90-day repurchase rate; future retention experiments should test referral incentives or ritual habit cards before retesting prompt cadence variations".

Decision Rule Pitfalls

Four common execution errors break the integrity of pre-registered decision rules:

All four pitfalls are detectable with one question: did the rule exist in writing before the experiment went active? If yes, the rule wins and the decision follows it. If no, the team is negotiating outcomes after the fact, which is not experimentation.

Avoiding Vanity Metrics

A decision rule is only as effective as the metric it points to. If the metric is wrong, the rule fires backwards, optimizing numbers that fail to change business outcomes or profitability.

Vanity vs. Real Metrics Comparison

To identify metrics that represent actual business health, teams must distinguish between vanity and real indicators:

Five Tests for Metric Integrity

Every candidate metric must pass five tests before it is allowed into a decision rule:

A candidate metric must pass all five tests; passing only 4 out of 5 is insufficient.

Metric Audits (Clairo and Zoko)

Auditing reporting scoreboards reveals common vanity metrics and their real metric replacements:

The AOV trap illustrated with numbers: if Zoko's AOV rises from Rs. 1,180 to Rs. 1,400 while the margin drops from 40% to 30%, the AOV dashboard shows improvement even though profitability has fallen. Vanity metrics are not false numbers; they are true numbers that provide incomplete information and point the team in the wrong direction.

The Two-Hop Rule

The two-hop rule mandates that any metric in a decision rule must trace to revenue, retention, or margin in at most two steps.

Strong Metric Chain (Clairo):
[Activation Rate] ---> (Hop 1) [Day 7 Retention] ---> (Hop 2) [LTV & Revenue]
(Validated in cohort data: users who activate also retain, and users who retain pay).

Vanity Metric Chain (Zoko):
[Instagram Followers] ---> (Hop 1) [Reach] ---> (Hop 2) [Website Visits] ---> (Hop 3) [Purchases]
(Unvalidated: requires three hops based on assumptions rather than direct data correlation).

If a team cannot draw the correlation chain on a whiteboard in under 30 seconds, the metric does not belong in a decision rule.

The Leading Indicator Trap

A leading indicator is a metric that moves before the lagging business outcome does. For example, activation rate is a leading indicator for retention.

Leading indicators fall into two categories:

1. Earned Leading Indicators: Validated internally using the company's own cohort data, proving a statistically significant correlation to a lagging metric.
2. Claimed Leading Indicators: Imported from competitor blog posts or external content without internal validation. These act as vanity metrics in disguise.

Hypotheses belong in the experiment column; only validated, earned metrics belong in the decision rules.

Four Patterns of Vanity Metrics

Immature growth teams frequently fall into four common metric patterns:

Resource Allocation Under Constraint

Prioritized backlogs often have more high-scoring ideas than a team has the capacity to execute. Capacity acts as the second filter after the ICE framework. If teams attempt to run all high-scoring ideas in parallel without resource limits, signals collapse, team bandwidth is overstretched, and experiments fail to reach a clean conclusion.

Three Currencies of Capacity

Capacity is a combination of three distinct operational currencies:

The binding currency is whichever of these three runs out first, and teams must plan execution against it.

The 70/20/10 Allocation Rule

Binding capacity must be split across three distinct experiment categories:

Memory hook: Capacity split 70/20/10: 70% known winners (confidence 7 or higher), 20% new bets (confidence 5 to 7), 10% exploration (confidence under 5). On top of that, keep a 20% to 35% slack budget of the binding currency uncommitted.

Capacity Constraint Audits (Clairo vs. Zoko)

Different brand structures hit different binding currencies, forcing distinct capacity layouts:

Slack Budget

A slack budget represents keeping 20% to 35% of the binding currency uncommitted. Slack is not waste; it is the operating buffer that allows plans to survive overruns, customer crises, or strategic reallocations when stronger mid-quarter evidence emerges.

Serial vs. Parallel Execution

Growth roadmaps must lay out experiments based on user interference:

A blocking experiment occurs when Experiment 2 depends on the outcome of Experiment 1. For example, upgrade prompt tests are blocked by pricing tests because the price determines the definition of an upgrade. Running them in parallel is logically incoherent. Blocker experiments must be scheduled to run first. The practical check for each active experiment: "Does the outcome of any other experiment in the backlog change what this experiment is testing?" If there is even a hint of yes, the other experiment is a blocker and runs first.

Killing Active Work: Reactive Kill vs. Strategic Reallocation

The hardest discipline in capacity management is stopping an experiment that is currently running. Two scenarios carry very different difficulty levels:

The sunk-cost logic for strategic reallocation: the weeks already spent are gone whether the experiment finishes or stops; the only real question is whether the next 3 weeks go to the diminishing experiment or the better one just discovered. The practical mechanic that makes this possible is a decision review every 2 weeks, not at the end of the quarter.

Capacity Failure Modes

Teams often waste up to 60% of their capacity due to four allocation failures:

The discipline check to kill active work during strategic reallocation asks: "Would the team start this experiment today knowing what is currently known?". If the answer is no, the active test must be killed to redirect remaining resources to higher-leverage ideas.

90 Day Growth Roadmap

A backlog and a roadmap are distinct artifacts serving different operational purposes:

Backlog vs. Roadmap

The operational differences between the backlog and the roadmap are structured as follows:

The backlog feeds the roadmap, and the roadmap drives the execution.

Quarterly Three-Month Logic

A standard execution quarter consists of 12 weeks, with each month having a distinct role:

Treating all 12 weeks of a quarter identically results in execution without learning.

Five Columns of a Growth Roadmap

Every quarterly roadmap contains 12 rows (one per week) and five columns to structure execution:

Five columns across 12 rows produce roughly 60 cells that turn the experimentation system into a structured calendar. The roadmap is read in two directions: top to bottom it is a calendar (week by week, what is happening across the team), and left to right it is a lifecycle (where each experiment sits in its arc). Both views matter, because a problem with the plan usually shows up in only one of the two views, so both are checked every Monday.

Clairo Quarter 4 Roadmap Case

A case study of a 12-week roadmap built under an engineering capacity constraint is structured below:

• Week 1 to 3 (E1 Building): Experiment 1 (onboarding redesign) is in building phase, consuming 1 engineer week per row. Parallel founder-led pricing test launches in Week 1, consuming 0 engineering hours.
• Week 4 (E1 Active / E3 Building): Experiment 1 goes active on a new user cohort. The engineer is freed to start building Experiment 3 (email timing test). Parallel runs are fine because they do not share a cohort.
• Week 5 (E1 Deciding / E3 Active): Experiment 1 hits its sample bound. The pre-committed decision date ("E1 Decision Friday") fires.
• Week 6 to 7 (E3 Active): Experiment 3 is active, and its pre-committed decision date lands at the end of Week 7.
• Dependencies (E2 Blocked): Experiment 2 (team invite mechanic) is blocked by Experiment 1. The dependencies column for Weeks 1 to 5 reads "E2 waiting on E1". E2 building begins in Week 7 after E1 has closed, going active in Week 10.
• Capacity Sizing: 8 weeks show engineering committed, leaving 4 weeks empty as a visible slack budget.
• Review Cadence: Alternate Monday biweekly reviews are highlighted as standing meetings.

Pre-Committed vs. Reactive Reviews

The timing of experiment reviews determines whether a team maintains velocity:

Roadmap Failure Modes

Growth roadmaps can collapse mid-quarter due to four common failure modes:

Integrating the Full Growth Engine

An integrated growth engine connects individual experimentation disciplines across the full AARRR funnel, compounding knowledge across quarters.

AARRR Funnel: Checklist vs. System

Viewing the funnel as a system rather than a siloed checklist dictates company-level impact:

The classic Dropbox referral program is an example of a system loop: referral drove acquisition, referred users brought friends, friends were activated by sharing folders, and the sharing loop drove retention. Referral, retention, and acquisition were not separate programs but one single mechanism.

The Six-Discipline Stack Hierarchy

The growth operating system is a vertical stack of six disciplines integrated in a single workbook:

Removing any layer collapses the entire stack.

The six-discipline stack and the AARRR loop are the same workbook read in two different ways: AARRR tells the team what to work on (which funnel stage holds the binding constraint), and the stack tells the team how and when to work on it. Every discipline applies to every AARRR stage; if next quarter's constraint shifts from retention to revenue expansion, the stack does not change, only the ideas being scored, ruled, and scheduled do.

A Monday Morning Running the System

A concrete 30-minute walkthrough of a growth lead operating the full system at Clairo, at the start of Week 5:

Annual rhythm of Growth System Compounding

Running the integrated stack continuously over four quarters creates a compounding growth flywheel:

Teams that restart the system every quarter without a structured backlog fail to compound learnings.

Integration Failure Modes

Four integration failures can occur even when individual disciplines appear mature:

Four Phased Rollout Steps for Scratch Setup

To avoid building six broken disciplines at once, teams must roll out the growth engine in phases:

Ultra-Quick Revision (Exam Essentials)

Key Concepts & Distinctions

The core growth architecture concepts and their distinctions are contrasted below:

Must-Know Terms

Definitions for core growth terms are structured below: