Growth Hypothesis

For a long time teams changed things without writing anything down and interpreted the numbers afterward. The trouble is that once you see the number first, every outcome has an explanation waiting for it. Signup completion went up because the screen got fixed. It went down because the ads changed that week. It stayed flat because that part of the product was already fine. All three stories sound reasonable, and none of them tells anyone what to do next.

Meetings in those teams tended to land in the same place. Two weeks after the change, everyone agrees that conversion went from 24 percent to 26 percent, and from that point on each person tells a different story. The designer thinks moving the button worked. The marketer thinks the traffic that week was simply better traffic. The engineer thinks two percentage points is ordinary noise. With nothing written down about what was expected, nobody can be shown to be wrong.

A growth hypothesis exists to reverse that order. Before anyone touches the product, the team writes down how much they expect to move and why they expect it, and afterward they hold that sentence up against the real number. With the sentence in hand, the result is either right or wrong, and when it's wrong, what exactly was wrong comes out with it.

Three things belong in the sentence: what changes, which number moves and by how much, and the reason for expecting that.

1. The change — specific enough that whoever builds it can start immediately. "Improve the signup screen" reads ten different ways; "cut the signup flow from five input fields to two" reads only one way.
2. The number and the size of the move — name one metric and write both the current value and the expected one. "Signup completion goes from 24 percent to 30 percent" works. Without a size, a gain of 0.3 points can't be called a success or a failure.
3. The reason — why that number should move. "Drop-off concentrates on the third field, which asks for company name and job title" is a reason.

The third slot is the one most often left empty, and an empty one makes the result unreadable. If you believed the third field was the problem, cut the fields, and the number doesn't budge, you've learned that field count wasn't the cause, and the next candidate you look at changes. Cut the fields with no stated reason and all you're left with is that it failed, which sends the next decision back to instinct.

In practice two more lines get attached: who sees the change, and when to stop. The audience line sets the scope — new visitors, or people who already have accounts. The stopping line is a date or a number of users. Without those lines, a good-looking number on day two is tempting to act on, even though daily swings of that size are normal and the gap means nothing yet.

The first draft comes from whoever owns the metric. At many companies the growth lead or the marketer on that metric writes the first sentence, and the engineer and designer who will build it fill in the reason together. It isn't written alone and handed over, because the evidence is usually split across people. Whoever watches the analytics knows which step loses users; the designer knows why that step was built the way it was.

Three groups read it. The person building it reads the sentence to learn how far to build and where to stop. The person judging the outcome puts the sentence and the number side by side two weeks later and calls it. The third reader shows up six months out, when someone wants to touch the same area again. For that person the sentence is a record of what has already been tried, and if the reason survived with it, the same failure doesn't get repeated.

That's why the document isn't thrown away when the test ends. It gets filed next to the result, and many teams read back through old hypotheses before adding new candidates to the experiment backlog.

"The reason field on this one is blank. Can you give me a line on why you think it goes up?"

There's no standard for reading the result yet, so the test shouldn't start.

"We predicted six points and got one. The direction held, the size didn't."

The change did something, just less than expected, so the team has to decide between pushing harder in the same direction and moving elsewhere.

"That's a task, not a hypothesis. There's no number in it and no reason."

Only the change is written down; the metric and the reasoning are missing.

At Pagedeck, writing these sentences is what Ravi does on day one of a growth sprint. Once he has read the last cycle's results and picked two or three candidates, he fills the three slots for each one and compresses it into a line. When he gets stuck on the reason, he asks Mia which step is losing people, and a candidate with no such number drops out of the cycle.

Theo takes the sentence and scopes the build from it. If cutting the fields to two is the whole change, he hides fields on the existing screen instead of designing a new one. Two weeks later the three of them read the sentence out loud and set the real number beside it.

The most common belief is that a good experiment is one where the hypothesis turns out right. A wrong prediction looks like a badly written prediction, so the assumption is easy to make. The truth runs closer to the opposite. A team that is right eight times out of ten is only picking tests whose answers it already knows, which means almost nothing new gets learned. Writing only hypotheses that will hold up pushes a team toward safe candidates, and the ones with genuinely uncertain outcomes — the ones with the most to teach — are the first to fall off the list.

Treating the hypothesis as a form to fill in once is the other common mistake, since it does sit in front of the test like a required field. But the value of the sentence arrives when it gets reread at the end. If nobody sets it against the result and notes which parts held and which didn't, the same idea about the same screen comes back two quarters later looking brand new.