"Data-driven" has become a way of describing a team rather than a way of working. Plenty of teams have dashboards, weekly metrics reviews and a testing tool they pay for. Far fewer have a steady cadence of small, well-designed experiments that change what they do next.
This post lays out a working cadence for growth experiments that a lean team can sustain: what counts as an experiment, how to pick them, how to run them, and how to decide when you have learned enough.
What counts as an experiment
An experiment is a change you make on purpose to learn something, with a way to tell whether it worked. Three parts:
- A hypothesis written before the change: "If we do X for audience Y, metric Z will move, because of reason R."
- A baseline: the before-state of that metric over a comparable period.
- A decision rule: what result would make you keep, kill or extend the change.
A redesign launched with a vague hope that "conversion goes up" is not an experiment. It is a project. Projects are fine, but they do not teach you much, because too many things changed at once.
Where good experiment ideas come from
The best ideas are grounded in evidence you already have, not in what a competitor just launched:
- Audit findings. A page that fails a usability heuristic or a Core Web Vitals threshold is a ready-made hypothesis. The free Spryxa audit names the element and the reason, which is most of the hypothesis written for you.
- Search data. Queries in Search Console that show impressions but few clicks point at titles and descriptions worth testing.
- Paid performance. Ad groups with healthy click-through and poor conversion point at the landing page, not the ad.
- Sales feedback. Objections that come up on every call belong on the page before the call.
- Customer language. Phrases buyers use for the problem are copy tests waiting to happen.
How to prioritise
Use a simple score and do not overthink it. For each idea, rate three things on a small scale: how much the metric matters to pipeline, how confident you are in the reason, and how cheap the change is to ship and undo. Run the top few. Revisit the list every two weeks.
Two practical rules help more than any scoring model:
- Favour pages with traffic. An experiment on a page with very few visits will take a long time to read. Start with the homepage, pricing, demo flow and top landing pages.
- Favour changes you can undo. Copy, layout and form changes are cheap to reverse. Pricing and positioning changes are not, so they need more evidence before you run them.
Running the experiment
A few habits separate experiments that teach from experiments that confuse:
- One change per surface at a time. If the hero and the form change together, you cannot tell which one mattered.
- Record the ship date and what changed. This sounds obvious. It is the most common gap in marketing experiment logs.
- Hold the rest steady. Do not launch a new campaign to the same page the week you change it.
- Run long enough to cover a normal cycle. At minimum a full week, so weekday and weekend behaviour both show up.
- Watch quality, not just volume. More form fills from the wrong buyers is not a win.
When traffic supports it, a split test is the cleanest option. When it does not, a before-and-after comparison against the page's own baseline is still useful, as long as you are honest about the confounders.
Deciding what you learned
Most experiments end in one of three places: a clear win, a clear loss, or not enough data to call. The third is common and not a failure. Write it down, decide whether to extend or move on, and do not dress it up as a win in the monthly report.
Keep a simple experiment log: hypothesis, change, ship date, metric, result, decision. After a quarter, that log is worth more than any single test, because it shows you which kinds of change actually move your numbers.
How the crews fit into the cadence
The bottleneck in most experiment programmes is not ideas. It is the time between "we should test this" and "this is live". Spryxa's crews are built to shorten that:
- Website Crew (Nova) writes site changes as structured fixes with a rationale, evidence and a risk rating. Low-risk fixes can ship inside guardrails. Visual or risky changes, and starting a conversion test, wait for your approval.
- Search Crew (Vega) turns search evidence into briefs and site fixes, measured on Search Console clicks, impressions, click-through and position.
- Paid Media Crew (Orion) proposes budget shifts and flags asset gaps. Budget, targeting, creative and launches all need your approval.
- Measurement Crew (Echo) reports anomalies and attribution notes and recommends who should follow up. It does not change anything itself.
You stay in the decision seat: which hypotheses to run, which changes to approve, and what the result means.
A two-week rhythm that works
- Day 1: review last cycle's results and the experiment log. Kill, keep or extend.
- Day 2: pick the next two or three experiments from the prioritised list.
- Days 3 to 5: changes are drafted, staged and approved.
- Days 6 to 14: run, watch for anomalies, do not tinker.
Two or three well-run experiments a fortnight is a sustainable pace for a small team, and over a year it adds up to a real body of evidence about your buyers.
Fill your experiment backlog with evidence. The audit names specific elements and reasons, page by page. Run your free Spryxa audit.