# Growth Experiment Pre-Launch Readiness Checklist > A pre-launch checklist for growth experiments covering hypothesis, metrics, sample size, instrumentation, and rollout — so you do not discover problems mid-test. - **Published:** 2025-08-11 - **Author:** Clixo - **Reading time:** 5 min read - **Tags:** experimentation, growth-engineering, checklist, a/b-testing - **Canonical URL:** https://clixo.sh/blog/growth-experiment-pre-launch-readiness-checklist Experiment failures are rarely discovered at the moment they happen. They are discovered two weeks later when the data looks strange, the assignment logs do not line up with the analytics events, or someone realizes the primary metric was never actually instrumented. By then you have wasted two weeks of user exposure and learned nothing reliable. A pre-launch review takes thirty minutes. It catches problems that would otherwise cost weeks. Run it for every experiment before you flip the flag. ```mermaid flowchart LR A["Hypothesis"] --> B["Sample Size"] B --> C["Audience Setup"] C --> D["Instrumentation"] D --> E["Rollout Plan"] E --> F["Stakeholder Comms"] F --> G["Launch"] ``` ## Growth Experiment Pre-Launch Checklist ### Hypothesis and design - [ ] A written hypothesis exists that specifies: who is affected, what changes, why it should work, what the expected effect is - [ ] The experiment is testing exactly one thing (not bundled changes) - [ ] The primary metric is defined and is a real, actionable business metric — not a vanity metric or pure feature-usage metric - [ ] The minimum detectable effect (MDE) is defined — you know the smallest lift that would be worth shipping - [ ] A stopping date is set in advance and shared with the team - [ ] There is a documented decision rule: what outcome means "ship," "discard," or "iterate" ### Statistics and sample size - [ ] Required sample size has been calculated using baseline conversion rate, MDE, desired power (at least 80%), and significance threshold (typically 95%) - [ ] Your expected traffic to the experiment surface can reach the required sample size by the stopping date - [ ] If power is borderline, you have explicitly decided to either extend the test window or accept a larger MDE — not to run an underpowered test and hope - [ ] Audience allocation is confirmed (typically 50/50 for two variants; rationale documented for any other split) ### Audience and assignment - [ ] Assignment logic is confirmed: the same user identifier is used for both assignment and outcome tracking - [ ] Assignment is sticky — the same user always receives the same variant across sessions - [ ] Any exclusion rules (bots, internal users, users in other active experiments) are implemented and tested - [ ] There are no other active experiments running on the same audience that could create interference - [ ] The experiment targets the right stage of the funnel — users who have not already passed the conversion point ### Instrumentation and logging - [ ] An assignment event fires when a user first enters the experiment, before any outcome interaction - [ ] The primary metric event is instrumented and confirmed firing in staging or in a test account in production - [ ] Secondary guardrail metrics are instrumented (error rates, load times, downstream funnel events) - [ ] Exposure logs are deduplicated — if the assignment condition fires multiple times per session, only the first fires - [ ] A sample ratio mismatch (SRM) check is scheduled for 24-48 hours after launch ### Rollout plan - [ ] The experiment is using a feature flag with percentage-based rollout configured - [ ] Initial rollout percentage is defined (for new surfaces or high-risk changes, consider starting at 5-10% before expanding) - [ ] There is a documented kill procedure: who can turn the flag off, and how quickly - [ ] Monitoring and alerting is in place for the primary metric and for error rates during the first 24 hours - [ ] The team knows who is responsible for reading results on the stopping date ### Communication - [ ] The experiment is logged in your team's shared experiment tracker with: hypothesis, primary metric, stopping date, owner - [ ] Relevant stakeholders (product, engineering, design, data) are aware the experiment is running - [ ] The team will not deploy other changes to the same surface during the experiment window without an explicit decision to pause and restart the test ## What to Do If a Box Stays Unchecked Most unchecked boxes are a signal that the experiment is not ready. Common situations: **"We do not know the baseline conversion rate"** — pull it from your analytics before launch. If you cannot find it, your analytics are not instrumented well enough to run a reliable experiment. **"We do not have enough traffic"** — either narrow the audience to a higher-traffic segment, increase the MDE (only care about larger effects), or wait until you have more traffic. Do not run an underpowered test. **"We are not sure if assignment is sticky"** — test it explicitly. Log in as a test user, clear your session, return, and confirm you see the same variant. **"There is another experiment running on this audience"** — either delay until the other experiment concludes or implement audience exclusion rules so the two populations do not overlap. A checklist is only useful if you actually block launch when boxes are unchecked. Treat it as a gate, not a formality. If you are building the internal systems and processes that make this kind of rigor routine across your engineering team, [Clixo builds growth infrastructure for product teams](https://clixo.sh/#contact). --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)