A real named individual, not an abstract persona.
A person is a specific human being: a named individual with a real calendar, real availability, and a real set of skills. The graph treats the person as distinct from the role they hold. People rotate between roles, hold several at once, go on leave, and leave the company, while the responsibilities they carry persist.
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 jobJobUserJob 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 tasksTaskProduct 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 needNeedUserA 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 personaPersonaUserAn 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.
Cooper introduced the persona into software product practice as a direct counter to this muddling: his argument was that teams designing for everyone — the abstract, shapeless "elastic user" — produce products that satisfy no one, and that committing to a named, fictional but research-grounded composite forces concrete design decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. On that account, the persona is deliberately not a person: its value lies precisely in being a stable archetype rather than a fluctuating individual.
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 initiativeInitiativeStrategyA 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.
In the Unified Product Graph, personteam_org domain. Its defining edge is node_owned_by_personnode_owned_by_role
Type-specific fields on BaseNode
role_titlestringFree-text job title. Distinct from the structured `role` entity.
time_zonestringIANA time zone (e.g. "Europe/Berlin"). Useful for capacity / on-call planning.
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering