The CRO process

CRO at scale is a process, not a series of tests. The loop:

1. Research. Find where to test by mixing quantitative analytics (where users drop off) with qualitative research (why they drop off). The output is a list of friction points and opportunities ranked by traffic and impact.
2. Hypothesis. Translate a research finding into a specific, testable claim - this change will move this metric by this much because of this mechanism. See hypothesis formulation. The hypothesis joins a backlog that’s prioritised with ICE, PIE, or RICE before anything queues for testing.
3. Test. Run the A/B test properly - pre-registered, sample-sized, single primary metric, guardrails set.
4. Learn. Document the result whether it won or lost. Add the learning back to the research base so the next round of hypotheses is informed by what you’ve already seen.

Then repeat. The loop accelerates over time because the research gets sharper (you know which patterns work), the hypotheses get better (you’ve eliminated dud directions), and the infrastructure gets faster (templates compound).

Why each step matters

Skip any one and the loop breaks:

• Skip research, hypothesise blind. You end up testing whatever feels interesting. Hit rate drops to noise.
• Skip hypothesis, just test. You’ll ship “winners” without understanding what caused them, which means you can’t generalise the lesson to the next test.
• Skip the test, just ship. No causal evidence. You’re back to opinion-driven design.
• Skip the learning, just move on. Each test is a one-off cost. The compounding never happens because the team doesn’t accumulate knowledge.

The learning step is the most underrated. Most programmes have a backlog of run tests, all interpreted at the time, none of them written up where the next hypothesis-generator can find them. The same test effectively gets rerun two years later because the original learning evaporated.

Where the loop sits in the org

Different teams own different parts:

• Research is usually shared between CRO, analytics, and design / UX research.
• Hypothesis quality lives with whoever proposes the test. The CRO lead’s job is to sharpen the hypotheses, not generate all of them.
• Test execution is CRO’s bread and butter.
• Learning capture is often nobody’s job, which is why it’s underdone. The fix is to make it part of the test write-up template, not a separate task.

Where it goes wrong

• The research step gets dropped. Teams jump straight to “what shall we test this week?” without surfacing the friction points first. Hypotheses become guesses.
• The hypothesis is just a description of the change. “Change the CTA copy” isn’t a hypothesis. “Change the CTA copy to be benefit-led, because users currently bounce when value isn’t clear above the fold” is.
• The test is rushed, sample size guessed. Skip ahead, fake result, fake learning.
• The learning step is “what we shipped” not “what we learned”. Wins and losses both have learnings. Only documenting the wins biases the next round.