Experimentation

Experiment velocity is the number of experiments you ship and learn from per unit of time, and it is the growth metric that matters because growth compounds from many measured tests, not from a few large bets. Higher velocity means you find what works sooner and waste less on what does not.

TL;DR in 60 seconds

• Definition: experiments shipped and read per week or month, not just launched.
• Velocity beats volume: raw output means nothing if you never measure and log the result.
• Velocity serves value: the goal is learning that moves revenue, so speed only counts on tests tied to a real KPI.
• The human cap is the ceiling: a person can only design, ship, and read so many tests at once.
• Agents lift the cap: velocity starts scaling with compute rather than headcount.

Defining it properly

Velocity is not "how many things did we launch". A launched test you never measured is not an experiment; it is a change you shipped and forgot. Real experiment velocity counts only tests that complete the loop: hypothesise, ship, measure against a KPI, log the result.

That definition matters because it is easy to inflate. Ten unread tests look busy and teach nothing. Three read, logged, and understood tests move the business.

Velocity vs volume vs value

Three words that get confused, and the difference is the whole point.

• Volume is how many tests you start. On its own it is a vanity number.
• Velocity is how many you complete and learn from per unit time. This is the engine.
• Value is how much the learning moves revenue or margin. This is the destination.

You want high velocity aimed at value. Volume without velocity is noise; velocity without value is a fast treadmill. The agentic GTM stack is built to keep all three aligned by grading every test against an outcome that matters.

Why the human cap limits it

A skilled growth operator is the bottleneck, not the villain. One person can hold only so much: designing a clean test, writing the variant, watching the data, and reading the result all compete for the same attention. Attention does not divide, so tests get run in series.

That serial cap is why most teams ship a handful of meaningful experiments a month and call it a good month. It is not a lack of ideas. It is a lack of hands and hours to run the ideas properly.

How agents lift the cap

Agents do not share the human attention limit. One agent can run a paid-audience test while another reworks a lifecycle sequence and a third trials a page section, each reporting into the same log. The work runs in parallel and nothing gets dropped.

The result is a genuine shift in scaling: experiment velocity starts tracking your compute and traffic rather than your headcount. You add capacity by adding agents and approvals, not by hiring a bigger team. Humans still gate hypothesis selection, copy, and ship-to-production, so speed does not cost you control. See how to run growth experiments with AI agents for the mechanics.

The compounding is the reward. Every logged result feeds the next hypothesis, so a system at high velocity gets sharper over time while a low-velocity team keeps relearning the basics.

FAQ

Is experiment velocity just A/B testing speed?

No. A/B testing speed measures one type of test on one surface. Experiment velocity spans every GTM surface: paid, web, lifecycle, social, and CRM. It also insists that each test be read and logged, not just launched. It is a portfolio metric for the whole growth system, not a single-channel stat.

How do I measure my current velocity?

Count the experiments over the last quarter that completed the full loop: shipped, measured against a KPI, and logged with a conclusion. Divide by the number of weeks. Be strict; only count tests you can actually point to a result for. That honest number is usually lower than teams expect, which is the useful part.

Does higher velocity mean lower quality?

Not if you keep prioritisation and human gates in place. Quality drops when speed comes from skipping measurement or review. It holds when speed comes from parallel execution of well-chosen tests. Use a scoring method like ICE, PIE, or RICE so the fastest system still runs the right experiments.

Can velocity be too high?

It can outrun your traffic. A test needs enough volume to reach a trustworthy result, so running more tests than your traffic can power just gives you noise. The fix is prioritisation, not slowing down: run the highest-value tests your data can actually resolve.

Cadence exists to raise your experiment velocity without giving up the human judgement that keeps it pointed at value.