The best growth teams ship faster than they strategize.

I spent the last twelve months embedded with twelve growth teams. Some of them moved their numbers a lot. Most of them moved their numbers a little. A handful didn't move their numbers at all, despite being staffed with smart, ambitious people running expensive tools.

The differences between the three groups had almost nothing to do with talent. It had everything to do with the ratio of strategy-talk to shipping.

The high-leverage teams strategized for two days and shipped for twelve. The low-leverage teams strategized for twelve days and shipped for two.

Here are three concrete things the high-leverage teams did differently. None of them are clever. All of them are uncomfortable for someone in the room.

1. They wrote a one-paragraph hypothesis, not a deck.

The shipping teams used a single template. "We think [user X] does [behaviour Y] because of [reason Z]. If we change [thing W], we expect [metric M] to move by [delta D] over [window T]. We'll measure it via [event/signal S]."

That paragraph fits in a Linear ticket. It takes 40 minutes to write. It cannot be padded. Crucially, it forces you to commit to a falsifiable claim — which means the test can win or lose in a finite amount of time.

The non-shipping teams wrote 18-slide pre-mortems for every test. Sometimes the test then took two weeks to actually build. Sometimes it never got built. The deck became the deliverable.

2. They had an editor for "no", not a committee for "yes".

One person on the high-leverage teams was authorised to say: "good idea, not this quarter, here's why." That person had calendar weight — usually the founder, a VP, or an experienced operator on a Wednesday-only consulting basis. The teams that didn't have this person ran open-loop: every idea entered the backlog, no idea left, the backlog became an unreadable list of seventy items.

Critically, the editor's job was not to greenlight things. It was to kill things. New ideas have to get past the editor; existing prioritised work does not. This subtle inversion makes the system stable.

3. They shipped on Tuesday and Thursday, not "when ready".

This sounds trivial. It is not.

Teams with a fixed ship cadence built smaller things. They built the smaller things faster. They learned faster. They iterated faster. The cadence was both forcing function and scoping discipline — "if this can't ship by Thursday, what's the smaller version that can?"

Teams without a ship cadence built bigger things, slower, and then sometimes shipped them, but mostly delivered them on the day of the all-hands and then moved on. The biggest predictor of whether an experiment got followed up wasn't its result — it was whether the next experiment had a deadline.

The number worth tracking.

If you're trying to diagnose your own team, here's the single metric I'd use: strategy-to-ship ratio = (hours spent in planning, alignment, debate, slack threads, design review, decks) / (hours spent merging code or shipping a campaign).

Anything above 1:3 is suspicious. Above 1:1 is broken. Below 1:6 is suspicious in the other direction — you might be shipping without thinking. The teams that compound landed between 1:4 and 1:6, consistently, week after week.

The good news is the lever to fix this isn't hiring. It isn't tooling. It isn't a new operating model. It's two days of editing your backlog, picking a ship day, and saying no to the deck.

Filed under: Operating · Series B+ teams · 2026