Taking "personas" and "user journeys" from the relatively mature practice in traditional Product Management to the level of stakeholders and adversarial network effects (a term I coined but may not ultimately be right) is what makes protocol design a ripe space for discovery, exploration, and growth (both personally and for businesses).

Personas tend to be a set of users, and typically these are desirable users, although with different JBTD.

For example, when working in a security SaaS company, I took two approaches to defining personas in the early days (which eventually matured over time) but, honestly, had alot of legs even with the added complexity.

I called one the "Easy Button" user. The other was the SecOps expert.

Interestingly, this persona approached spanned different firmographics (which I'll describe the breakdown of in a second).

The Easy Button user wanted just that: something which "just worked" across the domains of security, performance.

The SecOps expert wanted control, and knew the ins and outs of their security and performance posture.

Yes, the actual roles were different at times. In larger companies, the Sec was different from the Ops, for example. In smaller companies, they were the same person.

On the firmographics side, I broke things down into Internet, Modernizing, and Regulatory. This helped to inform the appetite for things like features, innovation, "enterprise-features" and so forth. These also worked across typical firmographics like "size" and "industry" and also helped us to figure out the value to cost ratio.

A regulatory company, for example, may not incur many real costs in terms of the use of the network. The TCV may be high. But there may have been alot of "chrome" features like SSO, auditing, SOC2, etc.

The other side of the equation were just "attackers" and it was a different team that focused on mitigation, and we usually sided with the customer to help identify what attacking behavior was, and ways to just detect and mitigate.

In the protocol world, potentially attackers are also stakeholders, they just have negative intent.

The in a protocol, each user could potentially be placed in an "adversarial" relationship in the sense of who gets there first, or who contributes more, or whatever. This "adversarial" nature could potentially drive bootstrapping adoption, and is a common technique in crypto via bonding curves.

Bonding curves rewards early users for being first, and, by virtue of being earlier than N+1, benefit; N+1 "loses" by coming in later.

It's often not articulated that way, but there are ways to imagine an adversarial-game-theoretic approach to building out the different stakeholders that ultimately drives network effects.

This above illustration, based on the Hitchers Guide to Token Engineering, is one of several ways to map out stakeholders.

Notice I don't just put the target customer, which is a persona-based way of building product; I also think about the space of Attackers, and other stakeholders in the protocol.

Exploring and identify each of the parties then helps one to design for each party where possible.

The following is one way to map stakeholders^[1]

It's an interesting approach of thinking about both the ledger layer and the market layer.

When examining token economies, we essentially look for the merged optimization of two sets of economics, which we call layered economics, where the token acts as the interface between these two layers:

• ledger layer economics: it provides the trust framework than enables all market layer activities.
• market layer economics: is where all the transactions occur

I think it helps to tilt things slightly differently and make participants the first class citizen. This may be very simplistic, but I think it starts the conversation.

Coordinating different people and what value they add to the Network, and any beneficial effects (via Network Effects and/or flywheels) is a critical part of the design.

So I would start with identifying who the participants are, what we want them to do, what is some bad behaviors they may do, and how they are incentivized. But it's also important to think through the value -- even potentially the bad actors....

But even if bad actors cannot add any positive value, then make sure those who do add behavior are incentivized.

The value creation side is very important to be clear upon, which I talk further in the protocol design.

But for Stakeholder design, let's do a brisk example:

Footnotes