16. Backlog, cadence, review

§The question: how does a team turn scattered experiments into a system that learns every week?

§A few good experiments are luck. A system that produces good experiments continuously is a capability, and it is built from three unglamorous parts. This chapter is the machine that keeps the loops from Parts II and III turning.

§ 16.1The backlog#

§One running list of hypotheses, always more than the team can run, always prioritized. Every idea, from a founder's hunch, a churned user's complaint, a funnel leak, a support pattern, enters the backlog as a hypothesis in the Part I form, not as a task. "Add dark mode" is not a backlog item. "Dark mode raises retention because users told us they use us at night" is, because it can be scored, run and read.

§The backlog is where the riskiest-assumption discipline lives day to day. It is prioritized by impact, confidence and ease, filtered to the weakest funnel stage, and re-sorted as results come in, because each result changes what is most worth testing next. A backlog that is not re-sorted after every result is a to-do list, not a learning system.

§ 16.2The cadence#

§A weekly rhythm: launch, read, decide. Sean Ellis's growth meeting is the model, and the weekly interval is not arbitrary. It is short enough that the team turns many loops before the runway ends, and long enough that most experiments produce a readable result within one or two cycles.

§Each week has the same shape. Launch the experiments chosen last week. Read the ones that finished, against their pre-written thresholds. Decide, by executing the pre-written decision rules. Choose next week's from the re-sorted backlog. The meeting is short because the decisions were pre-committed in the experiment cards; it is an execution meeting, not a debate, which is what keeps it from becoming the two-hour opinion session that kills cadence.

§ 16.3Documentation, so learning compounds#

§Every experiment is written down: the hypothesis, the metric, the threshold, the result, the decision, and, most importantly, what was learned about the users. Without this, learning evaporates: the team re-runs experiments it ran a year ago, forgets why it killed a feature, and cannot tell a new hire what it knows.

§Eric Ries called the accounting of what has been learned innovation accounting, and at a small company it is a single searchable document: one entry per experiment, findable by the part of the funnel or the assumption it touched. The compounding is real. A team a year in with a documented experiment history has a body of knowledge about its users that a competitor cannot buy, and a team that documented nothing is as ignorant as it was on day one, with more scar tissue.

§ 16.4Keeping the system small#

§At one to five people, the system must be maintainable by people who also build the product. That means the backlog is a shared document, not a tool that needs administration; the cadence is one short weekly meeting, not a ceremony; and the documentation is a page per experiment, not a report. Teresa Torres's weekly rhythm for discovery is the right scale model: light enough to sustain, regular enough to compound. A system heavier than the team can carry is abandoned in the first busy month, which is every month.

§ 16.5What you leave with#

§A prioritized backlog of hypotheses, re-sorted after every result. A weekly launch-read-decide meeting that executes pre-written rules rather than debating. And a searchable record, one entry per experiment, so learning compounds instead of evaporating. The next chapter is the instrumentation that feeds the system without drowning it.