Stakeholder

Origin & evolution

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 objectives🏁ObjectiveStrategyA 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 needs🫀NeedUserA 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 outcome🏆OutcomeStrategyA 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 feature⭐FeatureProduct SpecificationA product capability or featureView reference →, so the grid is a snapshot to redraw, not a filing decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →.

How it works in practice

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 cohort👥CohortGrowthA 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 roadmap🛣️RoadmapProduct 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 partner🗿Integration 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 dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → risk🎲RiskComplianceA 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.

Marty Cagan's Inspired frames this as one of four product risks every team must address before committing to a solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →: alongside value, usability, and feasibility sits business viability — the question of whether legal, finance, marketing, sales, and executive stakeholders will support what is built. By that framing, the compliance officer is not an obstacle to route around but a business viability constraint🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference → that belongs in discovery, not in post-code review.

Stakeholder vs. its neighbours

• Persona🎭PersonaUserAn archetype representing a user segmentView reference → is a fictional, evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →-based character standing in for a segment of users, built to guide design decisions about the product surface. A stakeholder is a real, named party whose influence shapes whether and how the product gets built at all. A user is one kind of stakeholder; a budget holder who never logs in is a stakeholder who is not a user.
• User is whoever operates the product to get a job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → done. Every user is a stakeholder, because they are affected by the work, but many of the people who can sink a project, legal, finance, an executive sponsor, never touch the interface. Designing only for users leaves those parties unmanaged.
• Customer is the party who pays, which in B2B is frequently not the user. The customer is a stakeholder defined by the commercial relationship; the stakeholder set is wider, taking in anyone with power or interest whether or not money changes hands.

In the graph

In the Unified Product Graph, stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the product sits in the Operations & Quality region, under team and organisation structure, and carries the note maps_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_board_includes_personaUser 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.