Most of us were trained to think like product managers. Find the user's problem. Define the outcome. Pick a success metric, build the roadmap, ship, measure, iterate. It works, and inside a team it should keep working.
\nBut a company's hardest rules, who may move money, what data leaves, which checks every output must pass, are not products. They are protocols. And a protocol is designed the other way round.
\nA product closes a question. A protocol opens moves. A product succeeds when it reaches the outcome you chose. A protocol succeeds when other people do useful things with it that you never chose. As Matthew McDowell-Sweet puts it in a recent note, \"Every outcome specified is a move taken off the board for someone else.\"
\nThe internet is the classic case. The end-to-end argument, on our Theme V reading list, said: keep the network simple and put the smart parts at the edges. Nobody wrote \"the web\" or \"video calls\" on that roadmap. Leaving them out is what made room for them.
\nYou can see the same split in two very different designs:
\nThat second story is the warning. A protocol does whatever its letter allows. People, and now agents, will find every move it permits. Our first reading, on 2 November, is OpenAI's report on agents that turned a package manager into a message board, because nothing said they couldn't.
\nIndustries that live with this have learned to design for it. Aviation's safety reporting system doesn't target a number of incidents. It sets a rule: report what went wrong, including your own mistake, and get limited protection for it. What comes back is insight no one could have asked for in advance. Toyota lets anyone stop the line, and no one has to predict why they will.
\nSo for anyone running operations, the question changes. Not \"what outcome do we want from this rule?\" but:
\nThese are open questions for the group this year, not settled answers. Bring your own examples to the sessions, or to the practice guide, where we're working them through.