Introduction · Page 9
Not the only method: the Lightning Decision Jam
For you only
The other method people ask me about is the Lightning Decision Jam, created by Jonathan Courtney of AJ&Smart in Berlin in 2017. It takes a team from problems to prioritised action steps in about an hour, with almost no discussion: silent writing, dot votes, an effort and impact scale, three action steps with an owner. It is the best one-hour meeting replacement I know.
The difference is what settles the argument. An LDJ decides with votes. A build day decides with working software in front of real users. At the end of a jam, both axes of that effort and impact scale are estimates. The group is guessing how much work something takes and guessing how much it would help, and for office problems that is the right trade. If the team guesses wrong about a new standup format, you lose a week and run another jam.
Product bets punish guessing harder. Teams guess impact wrong constantly, in both directions, and the only cure I know is contact with a user. An LDJ optimises the quality of your next guess. A Product Build Day replaces the guess with a reaction.
They also stack, and this is the part that gets missed when people frame them as rivals. Step four of an LDJ reframes the top-voted problem as a "How Might We" question. A build day starts from a challenge written in almost the same grammar. If your jam surfaces a customer-facing question with real money behind it, do not send it to the backlog. Tighten it into a proper brief (Chapter 13 is the rewrite manual), recruit five users, and give it a build day. The jam picked the fight. The day settles it.
If your stuck decision is "which of these process fixes should we try", run the jam. If it is "should this product exist, and in what shape", run the day.