Jonathan Blow on priorities
Game designer Jonathan Blow argues that disciplined prioritization—deciding what not to do—is the single habit that keeps projects from failing. The talk underscores that converting many valid user requests into ranked tradeoffs is the core operating skill for product teams. For people coming from support, the recommended move is to turn ticket patterns into prioritized problem statements that guide specs and roadmaps. (youtube.com)
Jonathan Blow’s point is blunt: projects usually do not fail because teams lack ideas; they fail because teams keep too many ideas alive at once and never cut the list down. In a 46-minute clip posted on YouTube, he frames priority as the act of deciding what will not get done. (youtube.com) Blow is not a generic management speaker. He is the designer of Braid from 2008 and The Witness from 2016, two puzzle games built over long development cycles at his studio Thekla, which gives his advice the tone of someone talking from production scars rather than theory. (wikipedia.org) His argument starts with a simple workplace fact: users, coworkers, and customers can all ask for reasonable things at the same time. A backlog full of valid requests still becomes a trap if nobody ranks them against one another. (youtube.com) That is why he treats prioritization as subtraction, not collection. A team that says yes to ten features with one schedule has really made ten promises with one budget, which is how deadlines slide and quality thins out. (youtube.com) This lands hardest in product work because product teams sit in the middle of sales, support, design, and engineering. Every group brings real pain points, but a roadmap only works if one problem gets solved first and nine others wait. (youtube.com) It also changes how support work gets used. A support inbox is usually a pile of individual complaints, but Blow’s framing pushes teams to convert repeated tickets into one ranked problem statement, the way a doctor groups symptoms before choosing a treatment. (youtube.com) That move matters because ticket volume can distort judgment. Five loud requests from one customer can feel bigger than one issue blocking 5,000 users, so the job is to translate anecdotes into scope, frequency, and cost before writing a specification. (youtube.com) Blow’s talk also pushes back on a common failure mode in software teams: treating prioritization as a one-time meeting. In practice, priorities have to survive new bugs, new requests, and new information without collapsing into “everything is urgent.” (youtube.com) That is why his advice resonates beyond games. Whether the team is shipping a puzzle game, a billing tool, or a mobile app, the operating skill is the same: turn many true demands into one ordered list that people will actually defend when the next request arrives. (youtube.com) The uncomfortable part of the message is that good prioritization disappoints people on purpose. If a roadmap never makes anyone unhappy, it usually means nobody made a real choice. (youtube.com)
