Battle: Testing Rival Prototypes Instead of Merging Them

Definition

A "Battle" is what happens when the Sticky Decision process produces two (or three) winning solutions that cannot be combined into one coherent prototype. Rather than debating which idea is better, the team builds a separate prototype for each rival solution — giving each a distinct fake brand name and look so customers can tell them apart — and runs them head-to-head in Friday's customer interviews. Whichever tests better wins, based on real reactions rather than an argument won in the room.

In the Book

In the Slack sprint, Stewart Butterfield's supervote went to a sketch called "Equipe de bots" (Bot Team), simulating a new user chatting with software bots to learn the product, while Merci Grace's supervote went to a different sketch, "Tour completo" (Full Tour), a step-by-step walkthrough of the interface. Merci had genuine standing to disagree — an experienced founder herself and the sprint's designated Decider — and estimated the bot-team idea alone would take four to six months of engineering to build for real. With two strong, incompatible ideas and no way to combine them, the book says "só havia um curso de ação a ser tomado. Era hora de uma Batalha" (there was only one course of action: it was time for a Battle). The team built both — keeping the real Slack brand on one prototype and inventing a plausible competitor name, "Gather," for the other, using a fast, ten-minute group technique called "Anote-e-vote" (Note-and-Vote) to settle on the fake name quickly. The book also names the alternative: if winning sketches instead fit together without conflict, as with Savioke's separate robot-personality ideas (sound effects, look-around behavior, a "joy dance") which all coexisted on the one robot, teams should combine them into a single richer prototype ("Tudo em um," All-in-One) rather than force an artificial Battle.

Why It Matters

Most decision processes assume conflict must be resolved by argument before you act — pick a winner, then build it. Battle inverts that: when a disagreement is backed by real conviction on both sides and genuinely can't be arbitrated on paper, the fast, cheap move is to build both cheaply and let the environment (real users, in this case) settle it empirically, rather than let debate skill or seniority settle it socially. The underlying move — convert an internal disagreement you can't resolve by talking into a matched external test you can run for less than the cost of continued argument — applies anywhere prototyping is cheap relative to the disagreement it would otherwise absorb.