Three concepts that most models collapse into one, and separating them is what makes the rest of this tier work.
| Persona | who someone is — an invariant identity |
| Operating context | where they are acting — a situation, a lens |
| Stakeholder | a persona situated in a context — the two combined |
Persona — the invariant who
A persona is an archetype of someone who acts in or around your business. It is deliberately invariant: who somebody is does not change because of where you meet them.
Classified on two independent axes:
nature — what they are made of. HUMAN, ORGANIZATION, GROUP, SYSTEM, AI_AGENT. Immutable, because a system does not become a person.
That list is longer than most persona practices allow, and each entry earns its place. A partner's API is a SYSTEM with real goals — availability, a stable contract — and no amount of writing it up as a human fools anybody usefully. As more work is done by agents acting on someone's behalf, AI_AGENT stops being exotic.
affiliation — which side of your boundary they stand on: EXTERNAL, INTERNAL, PARTNER, REGULATORY, COMPETITOR. Personas are born EXTERNAL and are reclassified deliberately.
Mutable, because affiliation genuinely moves: a competitor becomes a partner, a contractor becomes staff. The identity did not change; their relationship to you did — which is exactly why this is the axis that moves and nature is the one that does not.
⚠️ Regulators and competitors are personas. They are not customers and you are not serving them, but they hold goals that constrain you, and a model with no node for the regulator has nowhere to hang "must be auditable" other than as a requirement nobody can trace.
Operating context — the lens
An operating context is a coherent slice of your business through which a persona is viewed, and within which they hold a distinct set of expectations: onboarding, security, compliance, billing, a product offering, a support forum.
The insight it encodes:
The same persona seen through two contexts wants two different things.
A small-business owner in onboarding wants to not be asked for documents they do not have to hand. The same owner in billing wants to see exactly where the money went. Same person, same identity, entirely different expectations — and a model with one flat persona has to average them into something true of neither.
Draw contexts around coherent sets of expectations, not around your org chart. If two candidate contexts produce the same expectations from the same persona, they are one context. If a single context produces expectations that contradict each other, it is two.
Stakeholder — persona × context
A stakeholder is a persona situated in an operating context: the pair, made into a thing you can hang expectations on. Unique per (persona, context), so the same pairing cannot exist twice.
This is the bearer of two things:
- expectations — what this person, here, in this situation, is promised;
- principal-hood — whether they are the party whose interests are being served in this context, or a participant in someone else's.
The second is easy to skip and expensive to omit. In a support conversation, the customer is the principal and the agent is a participant; in an internal quality review of that same conversation, that flips. Without recording it, the model cannot tell you whose interests a design decision should favour when two stakeholders' expectations conflict — which is precisely the moment you want it to.
Why goals hang off personas and expectations off stakeholders
The single most important structural decision on this tier, and it pays off on the next page:
- a goal belongs to a persona — it is what someone is reaching for, and it travels with them everywhere;
- an expectation belongs to a stakeholder — it is what they are promised here, in this situation.
A small-business owner's goal — to feel in control of their finances — is the same whether they are onboarding or being billed. What they expect of you is entirely different in each. Hanging both on the same node would force you to choose which truth to lose.
Working practices
- Keep personas few, and make contexts do the work. Ten personas is usually one persona seen through ten lenses. That is a smell, and the fix is fewer personas with more contexts.
- Name personas by role, not by segment. "Practice manager" ages better than "SMB tier 2", which is a pricing decision wearing a persona's clothes.
- Situate before promising. You cannot record an expectation without a stakeholder, and that ordering is load-bearing: it forces you to say which situation the promise holds in.
- Add the unglamorous ones. The regulator, the partner system, the internal reviewer. They are where unstated constraints hide.
Read next: Goals and expectations — the move everything else hangs off.