Skip to content

The Decider

Definition

Every sprint needs a Decider (capitalized deliberately) — a specific named person, usually a founder, CEO, or senior product owner, who has explicit authority to make the sprint's calls: which problem to tackle, which sketch to prototype, whether the result is worth pursuing. This isn't consensus by another name; it's a formal, acknowledged transfer of decision rights to one person (or occasionally two), made before the week starts.

In the Book

The book grounds this in a failure story: an early sprint at a company the authors call "SquidCo" ran without Sam, the director of products, who was traveling that week. The team built a prototype, tested it well with customers — and when Sam returned, he killed the project anyway. Not because the test failed, but because he judged it the wrong problem to solve given other priorities. The authors call this their own fault: "We tried to guess what Sam would say, and we failed. The Decider should have been with us." They contrast this with the Blue Bottle Coffee sprint, where CEO James Freeman's presence let the team draw on his knowledge of company values and barista training directly, and with a startup CEO who once emailed a design director: "I hereby grant you the authority to make decisions on this project" — absurd-sounding, the authors admit, but effective, because it produced total clarity about who could say yes.

Why It Matters

Groups can generate excellent-looking outputs — validated prototypes, strong test results — that still die on contact with the one authority whose approval was never actually secured. Naming a Decider up front (or explicitly deputizing a stand-in) converts an implicit, undiscovered veto into an explicit, upfront constraint the whole process can plan around, rather than a landmine discovered after the work is done. This generalizes past workshops: any collaborative process that produces a recommendation for someone not in the room is exposed to the same risk.