The CRO Framework I've Used at Every Company Since 2010

I didn't start with A/B tests

I started with a sublet website in Tel Aviv.

In 2010, I built a site and ran social campaigns for TLV Sublet. No testing tools, no statistical significance, no multivariate anything. I'd make a change, wait a reasonable amount of time, look at what happened, and iterate. Before and after. That's it. Crude — but it forced a habit that turned out to be more important than any tool: watching what actually changes when you change something, and being honest about whether the change mattered.

The first time I ran real A/B tests was years later, as a Product Manager at William Hill Online. That was a different world — we A/B tested everything. Reward models. Game lobby layouts. Game selection logic. Creatives. Landing pages. The volume and rigor of experimentation there took my CRO skills to a level I didn't know existed.

But the most important thing I learned wasn't how to run tests. It was the order in which to do things. And that's become a framework I've carried into every role since.

It's a pyramid with three layers, and the sequence matters more than anything else in it.

The problem with how most teams do CRO

Walk into any company that "does CRO" and you'll find the same pattern. A backlog of test ideas. Most of them came from a brainstorm, a competitor's site, or a blog post titled something like "50 A/B Tests to Run Today." The team runs 2-3 tests a month. Some win, some lose, most are inconclusive. After six months, there's a spreadsheet of results but no compounding improvement. Revenue is flat.

The issue isn't effort. It's sequence.

Testing is the most visible part of CRO, so teams start there. But running experiments on a broken funnel is like A/B testing headlines on a page that doesn't load on mobile. You're not learning. You're generating noise.

The pyramid

I think of CRO as three layers, done in order. Each one builds the foundation for the next.

Layer 1: Fix what's broken

Before you test anything, walk your own funnel. On every device. On slow connections. With ad blockers on. Fill out every form. Complete every checkout. Click every CTA.

You will find things that are broken. You always do.

I've walked into companies where the mobile checkout had a CSS overlap hiding the submit button on certain screen sizes. Where the lead form threw a silent JavaScript error on Safari. Where a landing page took 9 seconds to load because someone embedded an uncompressed hero video. Where 404 pages were returning 200 status codes, so nobody in analytics even knew they were broken.

None of this is glamorous. Nobody writes case studies about fixing a broken form. But here's the thing: these issues are eating your conversion rate every single day, across 100% of your traffic. No A/B test will ever have that kind of reach.

Fixing what's broken isn't optimization. It's the prerequisite for optimization. And in my experience, this layer alone accounts for 5-15% improvement in conversion — sometimes more — because the problems have been compounding silently for months or years.

How I approach it:

• Technical audit — page speed, console errors, broken links, mobile rendering, cross-browser behavior. Not a checklist someone else made. The checklist you build by actually walking the funnel.
• Analytics hygiene — are events firing correctly? Is the data you're making decisions on actually accurate? I've seen teams optimize based on dashboards that undercounted conversions by 40%.
• Prioritization — severity multiplied by traffic multiplied by proximity to conversion. A bug on the checkout page matters more than a bug on the about page, even if the about page bug looks worse.

You know layer 1 is done when you can walk the entire funnel on any device without hitting something broken. Not perfect — done. There's a difference.

Layer 2: Remove friction

Now that the foundation works, you can trust your data enough to study behavior. This is where you map the actual paths people take — not the paths you designed — and find where they hesitate, struggle, or leave.

Friction isn't always obvious. A page with a 60% bounce rate might be fine — maybe it answered the visitor's question. A page with a 20% bounce rate might be terrible — if it's your pricing page and people are leaving confused. Context matters more than benchmarks.

What I actually look for:

• Session recordings — not all of them. Filter for sessions that reached a key page but didn't convert. Watch 30-50 of those. You're looking for patterns: rage clicks, hesitation, back-and-forth navigation, abandoned form fields. Ten minutes of this teaches you more than a month of dashboards.
• Funnel drop-off — where is the steepest decline between steps? Not just "which page" but which transition. The gap between "add to cart" and "begin checkout" tells a different story than the gap between "begin checkout" and "complete payment."
• Form analytics — which fields take longest to fill? Which ones get corrected most? Which ones cause abandonment? A single confusing field can tank a form's completion rate.
• Decision load — how many choices does a page present? Are you showing 4 pricing plans when 2 would do? Are users comparing 50 products with no filtering? Hick's Law is real: more options, slower decisions, more abandonment.

The fix for friction is usually subtraction, not addition. Remove a form field. Cut a step from the checkout. Reduce the number of choices. Clarify a confusing label. These aren't experiments — they're improvements. You don't need to A/B test removing a broken stair.

Some friction removal is big enough to test. If you're redesigning a checkout flow or changing pricing presentation, run the experiment. But don't let "we should test it" become an excuse to leave obvious friction in place.

The hidden benefit of layer 2: it gives you clean data for layer 3. When the funnel works and friction is reduced, your traffic flows more predictably. Conversion events happen in higher volumes. This means your future experiments reach statistical significance faster and produce more reliable results. Layer 2 literally makes layer 3 better.

Layer 3: Amplify what works

Now — and only now — you test.

But these aren't random tests. If you did layers 1 and 2 honestly, you've built something valuable: a detailed understanding of how people actually behave in your funnel. Your test hypotheses come from that understanding, not from a brainstorm or a competitor teardown.

A good hypothesis looks like: "In session recordings, we saw users scrolling past the testimonials section to find the pricing — if we move social proof closer to the pricing comparison, we expect consideration-stage visitors to convert at a higher rate."

A bad hypothesis looks like: "Let's try a different hero image."

The difference is specificity. Good hypotheses name the behavior, the segment, the change, and the expected outcome. They're falsifiable. They teach you something whether they win or lose.

One thing I learned early: don't fall in love with beautiful designs.

This sounds obvious. It isn't. I've watched teams pour weeks into a visually stunning redesign — polished, on-brand, impressive in the review meeting — and watched it lose to the ugly version. Repeatedly. Simple and effective beats visually impressive almost every time. The design that converts is the one that gets out of the user's way, not the one that wins awards.

This realization shaped my entire approach to testing. I operate in two modes, with nothing in between:

• Fail fast, iterate frequently. Small, quick changes. Ship, measure, learn, repeat. Sometimes I'll go back and retest old hypotheses with fresh traffic or a new segment — what lost six months ago might win today if the audience shifted.
• Leaps of faith. Complete redesigns. Throw out the current version and test something radically different. These are scary because you might take a short-term L. But if the data from layers 1 and 2 is telling you the current approach is fundamentally wrong, incremental tweaks won't fix it. Sometimes you need to blow it up and see what happens.

No middle ground. Cautious, incremental redesigns — the "let's change it but not too much" approach — are the worst of both worlds. Not different enough to learn anything, not safe enough to protect the baseline.

How I prioritize tests:

I use RICE — Reach, Impact, Confidence, Effort. But I've added a soft factor that doesn't show up in most scoring frameworks: buy-in. Even when a test's "Reach" score is small, I'll sometimes bump its priority if running it gets other people in the company invested in the CRO process. Every stakeholder who sees a test they care about produce a real result becomes an evangelist. And evangelists are what keep a CRO program alive past quarter one.

When to call a test:

Run until you hit your pre-determined sample size and duration — not until you see a winner. Peeking at results and stopping early when something looks good is the fastest way to fill your case study with false positives. Set the parameters before launch. Wait. Trust the math.

And when a test loses, that's not failure. A well-designed test that loses tells you something real about your users. The only wasted test is one that was too vague to learn from.

The compounding effect

Here's why sequence matters, mathematically.

Say layer 1 fixes improve your baseline conversion rate by 8%. Layer 2 friction removal adds another 12%. Layer 3 testing gains add 6%.

Most people think that's 8 + 12 + 6 = 26% total improvement. It's not. It's multiplicative.

1.08 x 1.12 x 1.06 = 1.282

That's a 28.2% improvement — and that's one pass through the pyramid. Do this quarterly and the gains compound on themselves. Teams I've worked with have gone from random testing to systematic 15-20% quarterly revenue improvements — not because they test more, but because each layer amplifies the next.

The teams that skip to layer 3 don't get this. Their tests run on broken foundations. Their sample sizes are depressed by fixable technical issues. Their results are muddied by friction they could have removed. They're working harder for worse outcomes.

Why teams skip to layer 3 anyway

Incentives.

Running A/B tests feels like progress. You have a backlog, a velocity, a win rate. You can present results in a meeting. "We tested X, it lifted Y by Z%." That story is clean and presentable.

"I spent two weeks fixing broken forms and cleaning up analytics tracking" doesn't have the same energy in a stakeholder review. But it's where 60-70% of the total gains live. The unsexy work is the high-leverage work. It always is.

If you're leading CRO at your company, the single most impactful thing you can do is resist the pressure to skip to testing. Do the audit. Fix the broken stuff. Remove the friction. Then test — with purpose.

Go deeper

This post is the framework. If you want the playbook for each layer — the specific audits, tools, thought processes, and examples — I wrote those too:

• Fix What's Broken First — the technical CRO audit that nobody wants to do, and why it's where most of the money is
• Remove Friction — how to map the path nobody walks themselves and find where users actually struggle
• Amplify What Works — earning the right to test, and how to design experiments that compound
• Why Sequence Beats Volume — the math, expanded, and how to present this to leadership

The seeds of this framework go back to 2010 and a sublet website in Tel Aviv. The structure sharpened at William Hill. The discipline has been tested at every company since. The tools have changed. The scale has changed. But the principle — do things in the right order, and each layer makes the next one better — hasn't.