After the day · Page 63
Run it again
For you only
One build day is a story people tell for a month. The habit is what changes how the company decides. Three questions settle whether and how to rerun it.
Did it work? Judge the day by its own promise: not "did people enjoy it" but "did the decision ship". If the go landed in front of real users again within two weeks, the day worked. If the one-pager died in a drawer, the day was pleasant theatre, and the fix is almost always in Part 1: a softer sponsor than you needed, or a challenge leadership did not really want answered.
When again? When the signals fire, not on a calendar. The six signals from Chapter 6 recur naturally a few times a year in any product team; quarterly is the ceiling I would plan for, because scarcity is part of why the day gets decisions no Tuesday meeting gets. A build day that happens every second week is a meeting with snacks.
Who runs the next one? Not you, ideally. The second-best outcome of your first day is a shipped decision. The best is a second facilitator: someone who watched you, borrowed this book, and runs the next room while you judge. The method is Creative Commons for exactly this reason. Teach it forward, keep my name and the Product Build Day name on it, and the thing spreads without either of us in the room.
Growing it. The format holds at eight people, and the temptation after a good day is twelve, then twenty. Resist it inside a company. Two rooms of eight on two challenges beat one room of twenty on one, because the facilitation, the testing rotation, and the ten-minute pitches all stop fitting past four teams. Split rooms, not seams.
The day is repeatable because it is small. Keep it small and it keeps being repeatable.