This is the first article in Edgar Allan's six-part series on how we build CRO programs for clients, combining customer research, experimentation, and Webflow implementation under one team. 

How do you know if the thing you’re about to test in CRO comes from a useful customer insight or from a hunch that’s been repeated enough times to sound true?

The short answer for us, anyway, is that we don't test anything until we have a specific, evidence-backed belief about the customer behind it. At Edgar Allan, we start every CRO (Conversion Rate Optimization) program with a customer observation, sharpen it into a real insight using research and behavior data, and only then do we write a testable hypothesis.

CRO often gets associated with tools like Heatmaps, A/B testing platforms, personalization software, and form optimization. And yeah, you can reduce the number of fields in a form or add an intercept and probably find some improvement. 

Those approaches will give you a quick CRO sugar rush, but I’m more interested in what happens before we choose the tool. 

As a Webflow design, development, and performance agency, Edgar Allan treats tool choice as the last decision when we run CRO programs for enterprise B2B SaaS companies. Figuring out what we believe about the customer and how we know it’s true comes first. 

We start by asking questions like “what do we believe about the customer?”,  “where did that belief come from?”, and “how specific is the belief?”

What makes a customer insight useful?

For CRO, I think of a customer insight as a specific understanding of a person, their behavior, or the situation they're in. 

Edgar Allan defines a customer insight as a specific, evidence-backed belief about why someone behaves the way they do, sharp enough to point toward one clear hypothesis instead of a dozen possible page changes.

One example from my latest episode of Building The Next Web with Zach Pousman, founder of the research firm Helpfully, was a classic:

Moms are busy. 

Ok, but what are they busy doing? When do things truly get stressful? Which of the hundred important things they need to do gets pushed until later? And what workarounds have they already created just by living mom-life every day? 

Those details, more than a baseline persona, start to give you something you can work with. 

AI has made the broadest version of that insight much easier to find. You can ask an LLM to summarize a market, review analytics, or suggest why someone might leave a page and get a reasonable answer. Zach described many of those answers as somewhere around C+ to B+. They're useful to get things started, but the job is to keep going and go deeper. 

Say you begin with: 

Enterprise buyers ask about integrations.

Ok fair enough. But, you review sales calls and learn those questions tend to show up early in the evaluation process. Then you have: Enterprise buyers ask about integrations early in the evaluation process.

Customer interviews give you another detail. Add that layer, and you might find that the concern is less about whether an integration exists and more about how much internal work adopting it will create. With that in mind, the insight changes again to something much sharper:

Enterprise buyers look for integration information early because they need to understand how much work adoption will create for their internal team.

Now there’s something a CRO team can work with.

How does a customer insight become something a CRO team can act on?

Before we change a page, I want to write down the customer belief behind the change to give the work a starting point. 

Using the example above: 

Customer insight: Enterprise buyers look for integration information early because they need to understand the internal work required to adopt the product.

From there, you can form a CRO hypothesis: 

CRO hypothesis: Bringing integration information earlier into the process will increase the qualified demo requests from enterprise visitors. 

The insight describes what you believe about the customer, while the hypothesis connects that belief to an observable change. 

That relationship matters because CRO can get very page-focused very quickly and lead toward thinking like “the headline feels weak”, or “the form seems long”, “the CTA could move”, and “the page could use more proof”.

Any of those may turn into useful work, but before changing them, I want to know what we’re trying to understand about the person using the site. 

Before testing anything, Edgar Allan’s CRO programs move through five steps:

1. Start with an observation.
2. Sharpen the observation into a customer insight using research and behavior data.
3. Turn that insight into a testable CRO hypothesis. 
4. Gather evidence using whichever method fits the question. 
5. Update the insight based on what the evidence shows.

The last step is especially important because the insight can shift, and the sentence you started with should be allowed to move as the evidence changes. You may learn that integration information matters more to larger enterprise companies, or you may find that the question comes up later than you expected. The test may point you back toward customer interviews.

Choose how to learn after you know the question

One more pitfall: A CRO hypothesis doesn’t automatically mean you need an A/B test; sometimes analytics can answer part of the question. 

A few sales calls might show that the issue happens at a different point in the buying process, or session recordings could illuminate whether people are even looking for the information you think they need. Similarly, customer interviews might change the whole insight before you spend time designing an experiment. 

The method depends on what you’re trying to learn. 

At Edgar Allan, this ordering is non-negotiable in a CRO program: get clear on the customer belief first, decide what evidence would test it second, and only then pick the method that fits the question, whether that's an A/B test, an analytics pull, a handful of sales calls, or customer interviews.

How confident are you in the customer insight?

Once you start writing these beliefs down, another question appears pretty quickly: How much evidence sits behind each one? 

Some customer insights come from years of research and behavior, while others start with something one person heard on a sales call last week. This is where the BETS framework from my conversation with Zach becomes useful. 

BETS stands for Backed, Educated Guess, Theory, and Speculation, and it gives teams a way to describe how much confidence supports an insight as new information comes in. 

That’s what I’ll explore in more detail in the next article. 

Next: How to use the BETS framework to decide what to test in CRO.