Ask a team running twenty experiments a quarter which five actually moved a number, and watch how long the pause is. Not because nobody's tracking results — because the results were tracked in twenty different places, by twenty different people, against twenty different definitions of "worked," and nobody ever sat down to rank them against each other.

Velocity became the metric instead of the means to one

Running a lot of experiments looks like rigor from the outside. It photographs well in a board deck — "we tested twenty things this quarter" sounds like a disciplined, data-driven team. But test count is an activity metric wearing an experimentation costume. It measures how much motion happened, not whether any of it taught you something worth acting on.

The teams that actually get faster over time aren't running more tests than everyone else. They're running fewer, better-instrumented ones, and they're ruthless about two things almost nobody does consistently: killing a loser fast, and actually scaling a winner instead of letting it quietly become one line in a retro deck that nobody revisits.

Why nobody kills the losing experiment

A test that produced an ambiguous or negative result doesn't have a natural endpoint. Nobody's job is to declare it dead. So it lingers — half-implemented, still consuming a little bit of attention, never quite resourced enough to matter and never quite killed enough to free up the resources for something else. Multiply that by twenty tests a quarter and you get a team that's busy managing its own experiment backlog instead of learning from it.

The fix isn't more discipline in the abstract. It's a pre-agreed kill date on every test before it launches — a specific day when someone looks at the result and makes a binary call: scale it, kill it, or extend it once with a stated reason. No test survives past that date without a decision attached to it.

The lightweight process that actually fixes this

You don't need an experimentation platform to fix this — you need one shared doc where every test has the same five fields: hypothesis, metric it's supposed to move, kill date, result, and decision. That's it. The value isn't in the tooling, it's in forcing every test through the same funnel of accountability instead of twenty people each managing their own.

Review that doc, not the raw test count, in your next leadership sync. The number that matters isn't how many experiments ran. It's how many produced a decision anyone actually acted on.

The same five-field discipline applies to outbound tests specifically: hypothesis, signal, kill date, result, decision. It's easier to isolate which signal-message combination actually worked when the outreach is triggered by a specific signal in the first place, rather than a blanket sequence you're retroactively trying to explain. That's the structure Skyp runs on, which makes the kill-or-scale call faster to reach.