Calibrating vs. Quitting

The hardest call in outbound isn't writing the message. It's deciding when you've learned enough to change it. Quitting and calibrating look the same from the outside.

A small brass compass on a dark surface with tilt-shift depth of field and warm side-lighting, needle sharp at center, background fading to blur.

The hardest call in outbound isn't writing the message. It's deciding when you've learned enough to change it.

Quitting and calibrating look the same from the outside. Both involve stopping what you're doing. The difference is whether you have sufficient signal to justify the change, or whether you're reacting to the discomfort of waiting.

When you're debugging, you don't change the algorithm after three data points. You run it long enough to produce output that means something. Three exceptions aren't a pattern. They might be noise. You hold the approach until the data earns a conclusion.

Outbound doesn't have a sample size formula. There's no threshold that says the loop has run long enough. So the discipline has to be pre-committed: you decide before you start what constitutes enough signal to evaluate. "I will review this message after 50 sends" is a defensible threshold. "I will review this message after 5 non-responses" is a feeling.

The trap is that changing the message feels like progress. You're doing something. You've identified a variable, proposed a fix, shipped a new version. It mirrors the feedback loop you know. But if you change the message at 10 sends because the silence is uncomfortable, you haven't calibrated anything. You've just reset the clock on a sample you never let mature.

I set a threshold before I started. It feels arbitrary now that I'm inside the wait. That's probably correct. Thresholds are supposed to feel arbitrary when you're holding them under pressure. That's the whole point of deciding in advance.

I haven't hit the threshold yet. So the message stays.