Experimentation / CRO

Experimentation and Testing Programs acknowledge that the future is uncertain. These programs focus on getting better data to product and marketing teams to make better decisions.

Research & Strategy

We believe that research is an integral part of experimentation. Our research projects aim to identify optimization opportunities by uncovering what really matters to your website users and customers.

Data and Analytics

90% of the analytics setups we’ve seen are critically flawed. Our data analytics audit services give you the confidence to make better decisions with data you can trust.

How to Build a Research System That Actually Drives Tests

Many companies do research. But too often, those insights live in Notion graveyards, PowerPoint decks no one opens, or researcher memories.

Imagine spending countless hours on user interviews, only for those profound 'aha!' moments to vanish into a digital black hole. Or worse, to be overshadowed by the loudest opinion in the room when it's time to decide what to test. This isn't just inefficient, it's a silent killer of growth, turning valuable insights into digital dust.

A 'typical' Research Graveyard

If you’re running a growth or experimentation program, you need more than data. You need a research system designed to fuel action.

Over the last few years, I’ve worked with SaaS and ecomm teams to build experimentation programs that don’t just test random ideas. They test ideas rooted in evidence. 

Implement this research system and process, you can expect:

  • A shift from scattered insights to a structured system that makes test ideation and prioritization much easier.
  • A consistent push toward evidence-backed experiments, reducing debates and opinion-driven decisions.
  • Greater clarity on where to focus optimization efforts, so your roadmap targets the problems with the biggest impact.

In this post, I’ll share what I’ve learned about turning scattered insights into a structured system that drives high-quality testing.

When Research Doesn’t Work

You’ve probably seen this:

  • A team runs surveys and usability tests, but no one uses the findings.
  • Insights are scattered across Slack, tools, or personal folders.
  • Test ideas are based on stakeholder opinions or trends, not evidence.
  • There’s no connection between what users say and what the team builds.

Why does this happen? Often, it's not a lack of effort or good intentions. It's because:

  • Insights are isolated: Data lives in different tools – a Miro board here, a Slack thread there, a Google Doc somewhere else.  There's no single source of truth, making it impossible to see the full picture or track connections.
  • Analysis Paralysis: Teams collect so much data they become overwhelmed, struggling to synthesize it into clear, actionable themes.
  • Lack of defined process: Without a clear pipeline from research to hypothesis generation, teams default to intuition or trending ideas, leading to 'random acts of testing' rather than strategic experimentation.

Research alone doesn’t improve conversion. It only works when it is connected to decisions and embedded into how you plan, prioritize, and run experiments.

“I don’t want to do research just for the sake of doing it. I want to watch the research light a fire under my stakeholder’s asses so they go fix the damn thing that customers just spent hours bitching about.” 

Step One: Centralize Your Insights

Before you can act on research, you need to find it. That means creating a central research repository. What this could look like:

  • Using tools like Airtable, Confluence, or even a shared spreadsheet.
  • Creating a record for each research project and specifying what methods or tools were used.  
  • Summarizing clearly: What was found, and why it matters.
  • Adding data to keep track of records: When the research was conducted, etc. 

A snapshot of Airtable-based Centralized Research Repository

But it’s not just about where insights live. It’s also about how they are structured. One of the most effective models I’ve seen is atomic research.

What is Atomic Research?

This approach breaks down research into three connected parts. Let’s use a real example to illustrate how it works. In one project, we reviewed dozens of customer support transcripts. Instead of summarizing everything in one long document, we recorded the learnings in Airtable, based on the atomic research framework.

Atomic research breaks down research into three connected parts:

  • Observations are raw findings from a specific research activity. These can be quotes, user actions, or complaints. For example:
    • Observation: Customers say discount codes are not working during checkout.

  • Insights are patterns or conclusions that emerge when multiple observations point to the same issue. For example:
    • Insight: Users experience friction with promo code redemption, especially during mobile checkout

Note: The insight can be supported by other data points, like Analytics or usability studies.

  • Actions are ideas or experiments proposed based on those insights. For example:
  • Action: Test a clearer input label and helper text near the promo code field.

This approach not only creates structure, it also allows teams to trace every test idea back to a concrete insight and every insight back to real user data.

Observations>Insights>Actions Table

Each observation can be tagged with the source (in this case, chat logs), and linked to other insights where relevant. This creates a searchable library where analysts, CRO specialists or designers can quickly pull up themes, see past ideas, and avoid repetitive work.

This 'atomic' approach is a cornerstone of an effective Experimentation Operating System (XOS). Think of your XOS not just as a place to store data, but as the central nervous system for your entire growth program. 

When insights are atomic and linked, your XOS transforms from a passive repository into an active intelligence hub, making it easier for every team member to contribute and benefit from collective learning.

Creating atomic entries ensures your insights stay usable, searchable, and easy to build on, even months after the research is done.

Tools that work well for this
You can build an atomic system using tools like Airtable, but even a spreadsheet works as long as you consistently track the observation, insight, and action for each record.

By treating research as building blocks rather than final reports, you make it easier to turn findings into decisions. It becomes possible to spot recurring problems (especially if you tag them well), reuse past insights, and generate better ideas during test planning sessions.

Research as building blocks

For instance, your 'Insight' records in Airtable might include fields like:

  • Theme: UI/UX issues, Clarity issues, etc. 
  • Tags: Friction, discount code, banner, etc.
  • Touchpoint: Checkout, Product listing page, etc. 

This structure makes filtering and cross-referencing insights incredibly powerful. 

The traceability and linking of research records are incredibly important. Imagine a stakeholder questioning a test idea; with an atomic system, you can immediately show them: 'This test is based on this insight, which stems from these methods  (chat logs, usability test notes, etc). ' 

Over time, this helps you improve the effectiveness of your program, buy in and ultimately, an experimentation culture.

Once you make a central source of truth, the next challenge is to make sense of everything you’ve collected. That’s where synthesis comes in.

Step Two: Synthesize by Theme

Once you centralize insights, the next challenge is making sense of them. That is where thematic analysis comes in. 

The magic of thematic synthesis lies in its ability to elevate individual data points into strategic opportunities. Instead of a scattered list of user complaints, you get a clear overview of major user pain points. This helps you answer crucial questions like, 'What are the top 3 friction points impacting conversion right now?' or 'Where are users consistently getting stuck?' 

What is research synthesis?

  • Affinity mapping or tagging to cluster findings.
  • Visualizing recurring themes in a Miro board or in-person sticky note mapping.
  • Quantifying observations, when possible, such as “four out of five participants didn’t understand the CTA wording”

In a workshop session, we can take the raw notes and group them by task. Then track how often certain behaviors or commented mentions appear across participants or respondents.

Speero's Thematic Analysis Example

Strong synthesis helps teams move away from scattered quotes and toward problem themes to solve together.

How to do thematic analysis: 

  • List out sticky notes (e.g. on a Miro board) for different observations from a variety of data sources.
    • Optional: colour code different observations per data source (e.g. green sticky notes for usability studies, blue sticky notes for chat logs, etc.)
  • Read through different research observations with the team, to start identifying recurring themes. 
  • Drag sticky notes to different ‘theme’ buckets, based on the mentions or categories that occur more frequently. 
  • Find the buckets with the most sticky notes and discuss together as a group
  • Label your top themes and prioritize them. 

It’s not about statistical significance here, it’s about recurrence. If something comes up consistently across numerous users, or from multiple data sources, it’s a strong signal.

A real example of thematic analysis in action

Let’s walk through a real case where we used multiple research methods to identify test-worthy problems and shape better design solutions. The process starts by collecting insights from a variety of sources:

  • Heatmaps
  • Session recordings
  • Heuristic reviews
  • Customer surveys
  • Site polls
  • Analytics
  • Remote usability tests
  • UI audits
  • Design surveys

Each method was color-coded and observations were documented as sticky notes. We then clustered these into recurring themes through thematic analysis. In this case, major clarity issues emerged: users were struggling to understand how to deposit or use crypto, and how the bonuses work on the site. 

Once the patterns were clear, we translated them into specific problem statements, such as ‘users don’t understand how to deposit or use crypto’ and then turned that into a how-might-we statement. For example:

  • How might we improve information clarity and guide users better
User Problem and Definition Analysis

We then created a scorecard, based on the user problem and defined the problem + hypothesis, as well as the key metric the change would impact. 

Finally, we moved from the idea scorecard to our first working prototype. Using the insight from research, the team created a Figma wireframe aimed at solving the issue, in this case, improving layout clarity and the bonus feature explanation within the conversion flow.

Why this matters:

This method doesn't just surface user pain points. It creates a clear path from raw research to structured themes, prioritized problems, and evidence-based solutions, all without losing traceability.

Step Three: Connect Insights to Experiments

The biggest gap in most organizations is not research quality. It's about making use of it.  In my work with experimentation teams, especially during ideation workshops, we use several practical techniques to bridge the gap between research and action.

During these workshops, we can run exercises for mapping solutions, where teams rapidly brainstorm on ideas from a 'How Might We' statement, or create test scorecards where they quickly visualize potential solutions to a specific user problem.

‘How might we’ is also found in ‘What's in a strategic testing roadmap?’ blueprint, letting you base this question on research itself, once you add insights, issues, and patterns.  Go through the punch list of insights and watch the needle move on those goal-associated KPIs.

Making research actionable with team workshops

We can begin by reviewing research themes. These are clusters of related insights that point to common user problems. Examples might include:

  • Pricing & Plans
  • Checkout friction
  • User Journey & Navigation

From here, we can start framing questions such as:

  • How might we improve clarity for plans
  • How might we increase sense of security in checkout
  • How might we provide better paths to guide product discovery

Why do we use “How Might We” statements?

A 'How Might We' statement is a short, optimistic question that reframes a problem into an opportunity for design and innovation. It's a way to launch a brainstorming session without being too broad or too restrictive. 

The magic is in the wording:

  • "How" suggests that the solutions exist and are waiting to be discovered.
  • "Might" gives permission to explore ideas that might be wild or might not work, removing the pressure of finding the perfect solution immediately.
  • "We" instills a sense of collaboration and shared ownership of the challenge.

This is partly based on Speero’s Problem-statement Focused Hypothesis blueprint. It helps you ground experiment ideas (or solutions) to research, using ‘problem statements’ as their bridge. 

You can even have alternative solutions as long as they are grounded in the same hypo (and problem statement).

How Might We Scorecard

Collaborative workshops, like ideation sessions are useful for gathering ideas and inputs from a range of backgrounds and roles and fill out the roadmap together. 

The impact of these workshop extend beyond just generating ideas, they help with stronger collaboration and more actionable roadmaps. Check out Speero’s workshop templates!

In a large-scale ideation session with Comcast, we used this collaborative approach to help cross-functional teams co-create 50 test ideas in a single day.

"Speero's approach to ideation helped Comcast in one key way: it gave full ideation access to teams that are connected to these projects but don't normally contribute. This brought a sense of collaboration in real-time where everyone understood the impact."

Lee Carson, Sr. Director of Digital Experimentation, Comcast

Turning themes into test ideas with a structured format

Once the problem is defined, we use a clear format to turn it into a testable idea. We use a format like this:

  • Problem: What issue are we solving
  • Hypothesis: What’s our assumption about fixing it
  • Metric: What will be measured

Example:

  • Problem: Users don’t understand what differentiates our plans. Three out of five interviewees said the pricing page “looks the same across tiers”
  • Hypothesis: If we clarify key feature differences in plain language, more users will feel confident choosing a plan
  • Metric: Plan selections
Hypothesis Creation Blueprint

A strong hypothesis isn't just a guess; it's an educated prediction rooted in evidence.  

The 'Because' part of the hypothesis (e.g. 'because we observed multiple users struggling with unclear pricing tiers') is critical. It grounds your experiment in user problems, not just intuition.

Check out Speero’s Hypothesis Creation blueprint if you want to find out more about creating well-crafted hypotheses. By focusing on the problem, defining a specific change, and identifying the expected outcome with a rationale, you reduce ambiguity and improve the strategic quality of your experiments.

Using strategy maps to connect research to goals
To go one step further, you can create strategy maps to keep teams aligned and connect themes to broader business goals and tactics. 

These maps aren't just for tests; they are powerful communication tools. They help leadership understand the why behind your experimentation roadmap, showcasing how tactical tests directly contribute to larger business objectives by addressing core user needs identified through research.

When we build a strategy map, we’re not just mapping tests. We’re mapping the path from research insight to business outcome. Each map typically includes:

  • Insight or theme: A clear, research backed observation or recurring pattern (for example, users struggle to understand pricing differences)

  • Supporting data: Data sources that support the idea. This can include customer surveys, analytics, or heatmaps.

  • Relevant KPIs: Metrics that would be affected by improving this area. These help focus efforts on impact (for example, trial start rate or conversion from pricing page)

  • Strategic and tactical recommendations: Suggestions for how to address the problem. This might include experiments or long-term design changes.

Speero's Strategy Maps Blueprint


When strategy maps are used consistently, they create a clear thread from what users need to what the business needs, making test ideas easier to align and prioritize.

Step Four: Make It a Habit

Even a great research system won’t help if no one uses it. You need to embed it into your team’s rituals.

These rituals aren't just checkboxes; they are the bedrock for cultivating a truly research-driven culture. When insights are consistently reviewed and linked to action, teams naturally begin to think with a user-first mindset.

Tactics that help:

  • Including a research link or an identified problem in every test brief.
  • Test planning meetings, where recent research insights are reviewed with the team.
  • Reviewing past themes and insights during retros or QBRs to track learnings over time.
  • Standardizing the research request process (such as a “submit a research need” form) to avoid ad hoc chaos.

When paired with atomic research entries, these rituals help your team reuse and amplify past insights rather than starting from scratch.

Keep the Process Lightweight

You do not need a full research repository to get started. Even a few strong quotes, chat log entries, or findings from a past usability test can be enough to spark meaningful test ideas.

The goal is not to be perfect. It is to be consistent in how you move from insight to action so that teams learn to build hypotheses from real user problems.

If your team is investing in research, it's time to ensure that investment truly pays off.

Start by structuring your insights, revisiting them systematically, and embedding them into every decision-making ritual. The best test ideas don’t come from guesswork; they come from deeply listening to your users and acting on what they tell you. 

Conclusion or Why Systems Beat Results

Here’s the thing about experimentation: it's not a magical black box that spits out revenue. It's a system. And the best systems are built on a solid foundation of user research. If your insights are scattered and disconnected, your experiments will be, too.

But when you take the time to centralize your research, synthesize it into clear themes, and connect those themes directly to your experiments, everything changes. You stop testing for the sake of testing and start solving real user problems. 

You can prioritize tests based on objective evidence, not just the loudest voice in the room. You can show your leadership that your work isn't just about a "win rate"—it's about making good decisions that drive real change.

This is the way to build a growth program that actually works. It's about deeply listening to your users and then acting on what they tell you. The best test ideas don’t come from guesswork; they come from a clear, structured system that turns knowledge into power.

Did you like this article?

(Your feedback helps us write better!) worst 1 - 10 best

Did the article resonate with you?

What aspects did you enjoy or find lacking?
Were there elements you felt we should've covered?
Thank you.
Oops! Something went wrong while submitting the form.

Related Posts

No items found.

Who's currently reading The Experimental Revolution?