Run outbound like an experiment (the freeze rule)
Most outbound programs change constantly and learn nothing. Hold variables constant, change one at a time, tag exceptions, and guessing becomes a method.
- #outbound
- #experimentation
- #method
Most outbound programs change constantly and learn nothing. The subject line gets rewritten on Monday. The ICP tightens on Wednesday. The offer softens on Friday because a deal stalled. Every change feels like progress, and every change contaminates the only thing that would tell the team whether any of it worked.
Outbound is an experiment. It has a treatment, the copy, the targeting, the offer, and a measured outcome, the reply and meeting rate. Run it like an experiment and it produces learning. Run it the way most teams do, changing variables whenever someone has a feeling, and it produces noise. You send ten thousand emails across a quarter, change the treatment nine times, and at the end you have no idea what moved the number. The data is unreadable because the experiment was never held still long enough to read it.
The discipline is the freeze. You pick the variables, the copy, the ICP, the offer, the sequence, and you hold them constant until a meaningful sample lands. Not forever. Until the sample. Fifty sends, a hundred, whatever the team decides is enough to draw a conclusion above the noise. Then you read the data, change one variable, and re-freeze. One variable at a time, because changing two means you can’t attribute the result to either.
This is the experimental method, applied to the thing most teams treat as a vibes-driven craft. It’s unglamorous and it works, and almost nobody does it, because freezing feels like giving up. The instinct is that activity is progress, and changing things is activity, so changing things must be progress. It isn’t. It’s the fastest way to spend a quarter and learn nothing about why the numbers moved.
The freeze has rules for when it has to break, because reality doesn’t honor experimental purity. A structural correction, a list that turns out to be the wrong companies, an offer that’s factually wrong, can be changed mid-window. But it gets logged, with a date and a reason, and the affected sends get tagged as a cohort, so the readout stays honest. A change you don’t tag is a change that quietly invalidates the whole sample. The cohort tag is the difference between a contaminated experiment and a documented one.
The payoff is that outbound becomes legible. Instead of “we changed a bunch of stuff and the reply rate went up, probably,” you get a result you can build on: everything held constant except the subject line, two hundred matched contacts, and the reply rate moved from here to here. The next freeze tests the next variable, and the program compounds instead of churning.
The team that freezes learns. The team that doesn’t just spends. Most outbound programs are expensive guessing dressed up as momentum. Freeze the variables, tag the exceptions, change one thing at a time, and the guessing turns into a method.
Most outbound programs change constantly and learn nothing. I run it like an experiment. Worth a 30-minute look at your stack? → Book a call.
Like the cut of this?
I write about GTM infrastructure like an engineer, because I am one.