A stakeholder with interest in the product
A stakeholder is any person or group with an interest in a product or the power to shape it: users, yes, but also the finance lead who holds the budget, the legal team that can block a launch, the partner whose API you depend on. The discipline of stakeholder management is figuring out which of them you owe what, because treating everyone with equal attention is the same as treating no one with enough.
The term entered strategy through R. Edward Freeman's Strategic Management: A Stakeholder Approach (1984), which defined a stakeholder as "any group or individual who can affect or is affected by the achievement of the organisation's objectivesObjectiveStrategyA strategic goal (OKR)View reference →." That deliberately wide net pulled in employees, suppliers, regulators, communities, and customers, and it reframed management as the work of balancing claims, widening the duty beyond shareholders alone.
A definition that broad needsNeedUserA user need, pain, desire, or constraintView reference → a way to triage, and the standard one came from Aubrey Mendelow, who presented a power-and-interest grid at the Second International Conference on Information Systems in 1991. Stakeholders are plotted on two axes: their power to influence the work, and their interest in its outcomeOutcomeStrategyA desired business or user outcomeView reference →. The four quadrants prescribe different handling. High power and high interest get managed closely; high power and low interest are kept satisfied; low power and high interest are kept informed; low power and low interest are merely monitored. The grid's value is that it forces a deliberate answer to "who actually needs my attention this quarter," and exposes the trap of over-serving a loud, low-power group while a quiet, high-power one drifts toward a veto.
Later work refined the picture. Mitchell, Agle, and Wood added legitimacy and urgency to power in their 1997 salience model, and practitioners note that power and interest are not fixed: a regulator with low interest today becomes high-interest the moment you touch a sensitive featureFeatureProduct SpecificationA product capability or featureView reference →, so the grid is a snapshot to redraw, not a filing decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →.
A team shipping a payments feature lists its stakeholders and places them on the grid. The compliance officer has high power and, until now, low interest, so she sits in keep satisfied: bring her the design before code, not after, or she becomes a launch-blocking veto. A vocal beta cohortCohortGrowthA group of users sharing a common characteristicView reference → has high interest and low formal power, so it goes in keep informed: heard often, but not handed the roadmapRoadmapProduct SpecificationA strategic plan of features and milestonesView reference → pen. The VP of Sales has both, and lands in manage closely with a standing weekly check-in. The integration partnerIntegration PartnerPartners & EcosystemAn integration partnerView reference → whose API the feature calls has high power over the timeline and moderate interest, so it moves up to keep satisfied the day a dependencyDependencyTeam & OrganisationA cross-team or system dependencyView reference → riskRiskComplianceA risk to the product or businessView reference → surfaces. Six weeks in, the compliance officer raises a data-residency issue early enough to absorb in a sprint, the outcome the grid was built to produce.
In the Unified Product Graph, StakeholderTeam & OrganisationA person with influence over the product sits in the Operations & Quality region, under team and organisation structure, and carries the note stakeholdermaps_to persona: where a stakeholder is also a product user, the graph links the two and avoids duplicating them. It connects through edges such as User Advisory BoardincludesPersonacross-domain, tying the people who influence the work to the segments the work serves. The placement reflects a real division of labour: stakeholders are managed as part of running the organisation, while the personas they overlap with live in Users & Needs and drive design. Keeping them distinct but linkable stops a recurring confusion, the team that mistakes its loudest user for its most powerful stakeholder.user_advisory_board_includes_persona
Type-specific fields on BaseNode
stakeholder_typestringRelationship of the stakeholder to the organisation
influenceobjectHow much influence this stakeholder has over decisions (1 = minimal, 5 = decisive)
interestobjectHow much interest this stakeholder has in the outcome (1 = passive, 5 = deeply invested)
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
3 edge types connected to this entity.
product_influenced_by_stakeholderdepartment_includes_stakeholderstakeholder_maps_to_persona