Growth Sprint

Nothing happens on the day you postpone an experiment. An outage has to be fixed and a customer request has to be answered, but nobody comes looking when a week passes with no experiment running. So for as long as experimentation has no name on the calendar, it ends up last in line every week.

Pagedeck lived that. At the start of a quarter Mia wrote 30 experiment candidates on the wall of a meeting room, and by the end of the quarter two of them had run. Nobody had objected. There was simply something more urgent every week, and an experiment was the thing that could wait until next week. The retro said the team had run out of time, but no time had ever been set aside.

A growth sprint solves that with a calendar rather than with willpower. The window for running experiments is cut out in advance, and a session for reading results is booked on the last day of it. Something has to be live before that meeting or there is nothing to read, which is what makes the work impossible to defer. It isn't a device for making any single experiment better — it's a device against experiments never running at all.

With a two-week round, the sequence has six steps, and because the dates are fixed the same work lands on the same weekday every round.

1. Read the previous round's results on the morning of day one. Winners get turned on for everyone, losers get one line on what was wrong and then get closed.
2. Reorder the experiment backlog right after. What the last round taught changes how confident you are in the candidates, so a ranking from two weeks ago is rarely still correct.
3. Pick the two or three to run and lock each experiment hypothesis into a sentence before anyone leaves the room: what changes, which number is expected to move and by how much, and what makes you think so.
4. Build from day three through day seven. Anything too large to build in that window was never a candidate for this round, so it gets cut down or pushed to the next one.
5. Launch on day eight and run through day thirteen. The window is fixed in advance because a good-looking number on day three makes stopping tempting, and the smaller the sample, the easier it is for chance alone to produce a wide gap.
6. Meet on the last day to call each result and record it. That meeting is step one of the next round, which is what chains the rounds together.

Two weeks is common because of pressure from both sides. A one-week round leaves three days to build and three to run, so the sample falls short and most experiments end in no call at all. A four-week round cuts the year down to thirteen rounds. Products with low daily traffic are the exception: they stretch the round to three weeks, or keep a single experiment per round and spend the rest of the time preparing the next one.

Three or four people are permanent. Whoever designs and calls the experiments, Theo on engineering to put them live and take them down, Noa on design to produce the alternate screens, and an analyst to confirm the numbers can be trusted. Any more than that and the day-one meeting runs past two hours, and after three or four rounds people start skipping it.

There are only two moments when the group meets: 60 to 90 minutes on day one, 30 minutes on the last day. Nothing is scheduled in between. Adding meetings to the build window turns the rhythm into one more reporting process.

Everyone else joins only when there's a reason. Ravi, in growth marketing, sits in on day one for rounds that touch ads or landing pages. Grace, the CEO, joins the first round of each quarter to agree on which metric the team is watching, and after that reads the last-day record. Once executives start picking which experiments run, the low-confidence candidates quietly disappear from the list.

"Two experiments this round. Put in three and one of them doesn't ship again."

Something went half-built last round, so take on less this time.

"That can't make this round. Put it in the backlog and we'll look at it on the next day one."

Not a refusal of the request from outside the rhythm, but a redirect to the place where it gets ranked.

"We agreed to run through day thirteen, so there's no need to look at the number now."

Don't let a mid-run figure pull you into calling it early.

The first two months Pagedeck ran this rhythm, what stood out wasn't the win rate but the count. Two experiments in the previous quarter became nine in two months. Two of the nine moved a metric, which is a 22 percent win rate — but the quarter before had no sample large enough to produce such a figure at all.

Other things followed once the rhythm held. The time to put one experiment live fell from four days to a day and a half, because repeating the same work every other week led Theo to build the mechanism for showing a new screen to a slice of users as a shared piece of the product. This is usually how fixing the cycle pays off: no single experiment gets better, but the setup around every experiment gets shaved down.

The most common misreading is that a metric should be up at the end of every round. The word sprint has always meant a cycle that delivers something, so the assumption follows. But experiments win one to three times out of ten. Demand a result every round and the team picks only the sure things, and the quarter ends with twenty button-color tests and nothing learned. What a round commits to producing is a decided result, not an increase.

Treating volume itself as the goal is the other one. Counts are easy to measure, which makes them easy to set as targets. But count and win rate only mean something together. Twenty-four experiments in a quarter with zero winners says the team is poking at random; an 80 percent win rate across four experiments says they only picked what they already knew. The first number is experiment velocity and the second is win rate, and targeting either one alone reliably breaks the other.