Protocol thinking is way more distinct from product thinking than I appreciated. Not different by degree. Not even different by kind. It’s different at the paradigmatic level.

First, traditional product thinking is outcome-based. One picks a target state, evaluates risks, and constructs archetypical cases to steer toward it. Success is arriving at the intended destination.

Protocol thinking optimises for something else entirely: an expansion of the moves available to players of the game. The protocol designer does have near-term goals, such as interoperability, legibility, and a low cost of compliance, but beyond them, they deliberately under-determine what gets built. That restraint is the point. Every outcome specified is a move taken off the board for someone else.

This is why indexing on outcomes, or even a cluster of them, fails. The upside a good protocol unlocks isn’t just hard to predict; it’s unnameable in advance. Steering toward a target state, however carefully chosen, narrows the space that’s meant to be widening. The question is whether others can now do surprising things in surprising ways neither they nor we could have specified beforehand.

Second, because protocol thinking solves for, essentially, unanticipated upside and future ecosystem optionality, one’s stance toward value capture and accumulated credit must change dramatically. Not softened. Abandoned.

Credit requires attribution, and attribution requires a nameable outcome. The moment one starts keeping score, one is pulled back toward the outcomes one can point at, which is to say back toward product thinking.

Value capture does the same damage more directly: every toll taken is a tax on the very moves the protocol was meant to make available. The aim is to expand others’ agency, not enlarge the designer’s share.

Protocol thinking in this sense asks for something product thinking never does: surrendering one’s own agency, credit accumulation and value capture in exchange for others’ capacity to accrue them.

Third, inbound changes must be guarded far more judiciously. In product, a feature request is a signal to weigh against a roadmap. In a protocol, a proposed change is an amendment to the rules everyone plays by, and it deserves scrutiny proportional to that, especially when it foregrounds someone’s value capture.

Some open-source projects have closed themselves to outside contributions rather than drown in evaluating them. That’s one answer. The better one is explicit criteria and quality gates that make the bar legible before anything is proposed. The bar must be high because, in a protocol, the letter and the spirit have to be synonymous.

Product teams can lean on intent, norms, and a terms-of-service page. Protocols can’t. Anything the rules permit will eventually be done; anything extractable will be extracted, as maximal extractable value shows with grim reliability. A change that’s harmless in spirit but exploitable in letter is simply exploitable. If the spirit isn’t encoded in the letter, it doesn’t exist.