Person

Origin & evolution

Modelling the individual apart from their function is a long-standing convention in organisational data. HR systems separate the employee record from the position; the position from the job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →; the job from the grade. Each layer changes on a different clock, and conflating them produces well-known failures: lose the position-versus-person distinction and a resignation deletes the work, a promotion rewrites history, a maternity cover looks like a duplicate employee.

Product practice imported the same discipline through the responsibility assignment matrix. RACI charts (responsibility charting, traceable to the 1950s and named through the 1970s, Perfony) deliberately assign roles, not named people, to tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, so that a chart survives a reorganisation. The person is the late binding: you fill the role with a name only when you need🫀NeedUserA user need, pain, desire, or constraintView reference → to know whose calendar to check.

The refinement worth keeping is that a person is real where a persona🎭PersonaUserAn archetype representing a user segmentView reference → is invented. The two words sit one letter apart and get muddled constantly, but they answer opposite questions. A persona is a research-derived composite that stands for a segment of users. A person is one actual employee on the building team. The graph never confuses them, because they live in different regions and connect to different things.

How it works in practice

A platform team has five people. One of them, call her Priya, holds the engineering manager role and also, for one quarter, an interim tech-lead role on a spun-up payments initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference →. The graph records Priya once, as a person, and connects her to two roles. When she takes four weeks of leave, the tech-lead role reassigns to a colleague; Priya's node is untouched, her EM responsibilities are flagged as covered, and the payments work keeps its owner. A naive model that pinned the work directly to "Priya" would have stranded it the day she logged off. A query for "who is overloaded" can now count roles per person and surface that Priya is carrying two before the burnout does.

Person vs. its neighbours

• Role is the responsibility; the person is the human who holds it. A person can hold many roles over time, and a role can pass between people. The edge between them is deliberately a connection, not an identity, so either side can change without the other.
• Persona is a fictional, evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →-based composite representing a user segment, used for design decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. A person is a real, named individual, usually on the building team. Personas live in the Users and Needs region; people live in Operations and Quality. The near-homonym hides a hard boundary.
• Stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → is a role-like position of interest in the product (the sponsor, the compliance owner), and it maps to a persona for design purposes. A person may occupy a stakeholder position, but the stakeholder is defined by interest and influence, where the person is defined by being a particular human.

In the graph

In the Unified Product Graph, person🧑PersonTeam & OrganisationA person entity sits in the Operations & Quality region within the team_org domain. Its defining edge is node_owned_by_personany entityowned byPersoncross-domain: any node can name a specific human as its owner. That edge exists alongside node_owned_by_roleany entityowned byRolecross-domain, and the choice between them is meaningful. Point ownership at a person when you genuinely need the individual (the only one who knows the legacy billing code); point it at a role when you want the work to survive a rotation. Separating person from role is what lets the graph answer both "who personally owns this" and "what does this role own" without forcing one to stand in for the other.