Why should you design the tournament instead of picking winners?

THE SHORT ANSWER

Because you cannot prototype all fifty ideas on the backlog, so someone still has to decide, before any evidence exists, which ones earn an hour. When a test cost a quarter of engineering time, the first decision picked the winner. When a test costs an hour, the first decision picks the bracket: which eight of fifty get prototyped at all. Same judgment, radically cheaper to be wrong. Picking winners is a conviction exercise. Designing the tournament is a portfolio exercise. Then let the prototypes settle who wins.

Product judgment did not die when prototyping got cheap. It moved up a level. Last week Marton Gaspar pushed back on my claim that prototypes replaced the upfront bet. His point: you cannot prototype all fifty ideas on the backlog, so someone still has to decide, before any evidence exists, which ideas deserve an hour. He is right, and conceding the point revealed something better than the point itself.

The bet survived, it shrank

When testing an idea cost a quarter of engineering time, the first decision picked the winner. You got one shot, so judgment had to carry the entire weight of the outcome, which is why we wrapped it in twelve pages of justification and called it a PRD. When testing an idea costs an hour, the first decision picks the bracket: which eight of the fifty get prototyped. Same judgment, radically cheaper to be wrong. Building the prototype is now the easy part, the hour any PM can run. The job before data did not disappear. It moved from picking winners to designing the tournament.

What tournament design looks like

Picking a winner is a conviction exercise: you stack evidence, build a narrative, and defend one choice in a room. Designing a tournament is a portfolio exercise, built on three questions.

Which ideas are cheap to test and expensive to skip? Those enter the bracket automatically, because the cost of wrongly excluding them exceeds the hour it takes to check. This is the cost of being wrong run in reverse: not what a bad bet costs, but what a skipped test costs.

Which ideas share a prototype? Five backlog items that all hinge on the same workflow assumption are one test, not five. Bracket design is mostly deduplication.

Which ideas cannot be settled by a prototype at all? Pricing, positioning, and platform bets do not resolve in an hour of building. Those stay judgment calls, and pretending a prototype settled them is how teams fool themselves.

The failure mode has a name

Marton called it cosplay, and his definition is the cleanest I have seen: not PMs writing code, but PMs dropping the betting to become part-time engineers. Building the prototypes yourself feels like progress. It is the middle of the job. If nobody is designing the bracket, you are just a slower engineer running an unseeded tournament where whatever got built first wins.

The scarce input was never the prototype. It was the fifty-to-eight cut that happens before anyone opens an editor. That call got cheaper to get wrong. It did not get less necessary, and deciding well under repeated, low-cost pressure is exactly the muscle of judgment reps. This week, take your backlog and instead of arguing for one winner, seed a bracket: mark which ideas are cheap to test and expensive to skip, group the ones that share a prototype, and set aside the ones a prototype cannot settle. Then let the prototypes play it out.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read