Role

Origin & evolution

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 decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → rights. Engineering management literature adds the engineering manager as a fourth. None of these is a job🔨JobUserJob 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.

Marty Cagan's *Inspired* gives the PM role its sharpest definition in this tradition: the PM is accountable for four risks🎲RiskComplianceA risk to the product or businessView reference → simultaneously — value (will customers want it?), usability (can they use it without help?), feasibility (can the team build it sustainably?), and business viability (does it work for the business?). Owning all four is what makes the PM role distinct from any other on the trio; a PM who delegates the viability question to the CFO or the feasibility question entirely to engineering has, by that reading, ceded the role.

The live refinement is the split between Accountable and Responsible. One person is accountable for an outcome🏆OutcomeStrategyA 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.

How it works in practice

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.

Role vs. its neighbours

• Person is the individual human, with a name and a calendar. A role is the responsibility they currently hold. One person can hold several roles; one role can pass between people. Keeping them separate is what lets a team model a vacancy or a hand-off without deleting anyone.
• Title is an HR and compensation artefact ("Staff Engineer", "Group PM"). It tracks seniority and pay band, and it changes slowly. A role tracks who owns what on a given piece of work, and it changes fast. A title rarely tells you who is accountable for the thing in front of you.
• Skill is a capability💪CapabilityStrategyAn ability that enables value deliveryView reference → a person has (TypeScript, user interviewing). A role is a responsibility they are assigned. You need🫀NeedUserA user need, pain, desire, or constraintView reference → the skill to do the role well, and the two are matched in a skills matrix, but holding the skill is not the same as holding the role.

In the graph

In the Unified Product Graph, role🪪RoleTeam & OrganisationA role within a team sits in the Operations & Quality region, in the team_org domain, as a leaf inside the team and department containers. Two edges anchor it: a team🫂TeamTeam & OrganisationA cross-functional teamView reference → is staffed through team_staffed_with_roleTeamstaffed withRolehierarchy, and any node, a feature⭐FeatureProduct SpecificationA product capability or featureView reference →, a service, a decision, can be owned through node_owned_by_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.

Matthew Skelton and Manuel Pais's *Team Topologies* argues that the team, not the individual, is the primary unit of delivery, and that the type of team — stream-aligned, platform, enabling, or complicated-subsystem — determines what responsibilities its roles can realistically absorb. A role that makes sense inside a stream-aligned team (end-to-end feature ownership, direct user feedback) may be structurally incoherent inside a platform team, where ownership is of a service consumed by others. The graph's placement of role as a leaf inside the team and department containers follows the same logic: the team shape bounds what the role can mean.