Protocol Strategy
Why Product Strategy is already hard and critical in protocol-land
In Product-land, gurus and leaders often talk about the strategy.
But as Rumelt points out, most product people and executives mistaken a “strategy” with a goal and the tasks to execute.
quote here
The default reason, and certainly true, for why people do this is true, but insufficient: coming up with a proper strategy is hard.
However, just because it’s hard doesn’t mean it should be entirely absent as is often the case.
We wouldn’t cheer a football team if they announced that their strategy was “to win the Superbowl”; and that the key indicator was “score more points than the other team;” and the plan is “run fast; throw the ball; practice every day.”
I’d be curious to research whether there were, in fact, any Superbowl winning teams that would say that they were strategic in this way.
However, I bet that despite it’s brawn and brute nature, Superbowl winners and the coaches who lead them to victory, were likely very strategic.
Example of a strategy here
Yet, in product software land, and more so in protocol-land, this level of strategic insight is largely absent. And not just because it’s hard, because the difficulty should just lead to lots of bad strategies.
Why, then, is the setting of goals and an execution plan a default way to be strategic in many technology companies?
Conversely, the ones that do succeed and win significantly appear to execute deep, multi-move strategies. While the insider stories are missing, there’s enough external visibility that these strategies are observable.
Protocol-land, where strategy is critical to the adoption, is more often missing.
It could be because the web1 versions of protocols “seem” much more pure; they were technical specs written collaboratively in the open.
But I suspect that many specifications were part of a contributors own strategy; and when there are multiple players with highly strategic contributors, the outcome has some degree of strategic intent leading to its success.
Many web3 protocols, on the other hand, presumed inevitability: if it’s built, it will dominate and has, in fact, already won. Ethereum is a good example, where early success (and this is probably the primary driver) of economic rewards created a negative incentive — one absent in both web1 and web2.