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.
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.