A role within a team
A role is a named bundle of responsibility: a set of things that must be owned, decided, or done, defined independently of who holds it. Product manager, designer, engineer, engineering manager. The discipline lives in keeping the role separate from the person who fills it and from the title on their contract, because those three drift apart constantly, and most confusion about "who does what" is really confusion about which of the three you are talking about.
The idea that responsibility can be named and assigned as a thing apart from headcount runs through twentieth-century management practice, and it crystallised in the responsibility assignment matrix. The most durable form is RACI (Responsible, Accountable, Consulted, Informed), which traces to responsibility charting work in the 1950s, sometimes attributed to internal practice at firms like DuPont, and took on the "responsibility assignment matrix" name through the 1970s (Perfony). The point of RACI was always to clarify ownership for a piece of work without rewriting the org chart, which is exactly the role-versus-headcount line.
Software product practice narrowed the general idea to a small, recurring set. The product trio that Teresa Torres popularised in Continuous Discovery Habits (2021) names three roles, product manager, designer, and engineer, with shared decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → rights. Engineering management literature adds the engineering manager as a fourth. None of these is a jobJobUserJob To Be Done: what the user is trying to accomplishView reference → title in any strict sense; each is a responsibility set that a person picks up.
The live refinement is the split between Accountable and Responsible. One person is accountable for an outcomeOutcomeStrategyA desired business or user outcomeView reference → (the buck stops there); several may be responsible for doing the work. Teams that collapse the two end up with five people who all think someone else owns the result.
A nine-person team ships a checkout redesign. On paper there are nine job titles. The roles that matter for this work are four: a PM accountable for the outcome, a designer responsible for the flow, two engineers responsible for the build, and an EM responsible for delivery and the people. A new hire joins as a "Senior Product Designer" by title, and for this project holds the designer role; next quarter she holds a research role on a different team. The title stays fixed on her contract. The role moves with the work. When the PM goes on leave, the role reassigns to the EM for three weeks without anyone changing jobs, and the graph records that the responsibility moved while the person did not.
In the Unified Product Graph, RoleTeam & OrganisationA role within a team sits in the Operations & Quality region, in the roleteam_org domain, as a leaf inside the team and department containers. Two edges anchor it: a TeamTeam & OrganisationA cross-functional teamView reference → is staffed through teamTeamstaffed withRolehierarchy, and any node, a featureFeatureProduct SpecificationA product capability or featureView reference →, a service, a decision, can be owned through team_staffed_with_roleany entityowned byRolecross-domain. Pointing ownership at a role rather than a person is the deliberate move: the work keeps its owner when the person rotates off, goes on leave, or leaves the company, and a query for "what does the PM role own" returns the same answer regardless of who holds it this month.node_owned_by_role
Type-specific fields on BaseNode
responsibilitiesstring[]Key responsibilities of the role
seniority_rangestringSeniority band this role sits in
required_skillsstring[]Skills expected for the role (structural refs to Skill entities go via edges)
reporting_linestringRole this one reports to (name or role id)
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: proposed
1 edge type connected to this entity.
team_staffed_with_role1 framework use this entity type.