12.2 Stakeholders & Customers
Key Takeaways
- A product has a clear boundary, known stakeholders, and well-defined users or customers—those definitions help decide what is one product
- The Product Owner represents the needs of many stakeholders in the Product Backlog without becoming a passive order-taker for every request
- Effective Product Owners identify and learn about challenges key stakeholders face so the product can deliver the value those stakeholders seek
- Customers and users often differ from the broader stakeholder set; exam scenarios test whether you optimize for real value recipients vs. only internal politics
- Stakeholder input informs ordering; stakeholder voting or bypass does not replace Product Owner accountability for the backlog
12.2 Stakeholders & Customers
Scrum Guide 2020 (product): A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Stakeholders & Customers is a PSPO I focus area because value is relational: products create outcomes for people. The Product Owner cannot maximize value without knowing who those people are, what challenges they face, and how internal stakeholders influence investment—while still holding a single ordering authority.
Product Boundary, Stakeholders, Users, Customers
The Guide’s product definition is exam-critical. “One product” is not “whatever fits in one Jira project.” It is a value vehicle with:
| Element | Meaning for Product Ownership |
|---|---|
| Clear boundary | What is in this product vs. another; one Product Backlog and one Product Owner for that product |
| Known stakeholders | People or groups with interest, influence, or impact related to the product |
| Well-defined users or customers | Who uses the product and/or who pays or chooses—clarity about beneficiaries of value |
If stakeholders are unknown and users are undefined, you do not have a coherent product for Scrum’s model—you have a shared cost center or a request sink.
Stakeholders vs. users vs. customers (discrimination skill)
These terms overlap in casual speech; PSPO I rewards precision:
| Role | Typical relationship to the product | Example (B2B SaaS) |
|---|---|---|
| User | Interacts with the product to accomplish work or goals | End-user analyst who runs reports daily |
| Customer | Chooses, buys, renews, or contracts for the product (sometimes the same as user; often not) | Procurement / department buyer who signs the renewal |
| Stakeholder | Broader set with interest or influence: sponsors, regulators, support, sales, partners, executives, adjacent teams, and often users/customers too | CRO, compliance officer, support manager, implementation partner |
Key point: Every customer or user can be a stakeholder, but not every stakeholder is a customer or user. Internal stakeholders may demand features that do not help users. Customers may demand features users never touch. Product Owners must learn and balance, not equate “loud stakeholder” with “user value.”
| Scenario | Risk if confused |
|---|---|
| Only sales stakeholders define the backlog | Product optimizes demos and contracts; users churn |
| Only end users define the backlog | Compliance or operational constraints that protect the license to operate are ignored |
| Only executives define the backlog | Strategy slides without user evidence; weak outcomes |
| PO treats “stakeholders” and “customers” as identical always | Misses multi-sided products (marketplace, platform, regulated services) |
The Product Owner Represents Many Stakeholders in the Product Backlog
Scrum Guide 2020: The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
Precision trap: stakeholder representation is not one of the listed items of effective Product Backlog management. That list has exactly four entries — develop and explicitly communicate the Product Goal; create and clearly communicate Product Backlog items; order Product Backlog items; ensure the Product Backlog is transparent, visible and understood. Representing many stakeholders appears separately, in the sentence establishing that the Product Owner is one person rather than a committee. Multiple-answer items like to slip a fifth plausible-sounding duty into that four-item list.
“Representing” is active synthesis, not stenography.
What representation means
| Representation includes | Representation does not mean |
|---|---|
| Gathering needs, constraints, and desired outcomes from many parties | Every stakeholder request becomes a top backlog item |
| Making those needs visible as Product Backlog items or decision context | The backlog is a verbatim transcript of every email |
| Ordering for value toward the Product Goal and strategy | Ranking by who yelled last or who outranks whom on the org chart alone |
| Explaining trade-offs so stakeholders understand what is in/out | Giving each stakeholder a private promise outside the backlog |
| Integrating customer/user evidence with internal stakeholder input | Ignoring users because internal stakeholders fund the team |
The Product Owner is one person accountable for the product’s value. Many people contribute information; they do not each become a Product Owner for the same product.
Multi-stakeholder tension is normal
| Stakeholder A wants | Stakeholder B wants | PO move |
|---|---|---|
| Fast new capabilities | Strict change control and auditability | Order a thin capability slice that includes necessary controls, or sequence learning vs. compliance by risk |
| Custom work for one logo account | Scalable product for the segment | Prefer productized value unless strategy explicitly funds custom; keep transparent |
| Feature X for demo next week | Product Goal path Y for retention | Protect Goal unless evidence shows Goal should change; do not run dual secret commitments |
Representation is judgment under transparency, not averaging every request into mush or satisfying everyone partially in a way that satisfies no one.
Learn the Challenges Key Stakeholders Face
PSPO competencies emphasize understanding stakeholders and customers deeply enough to deliver the value they seek. Value is often defined by jobs, pains, constraints, and desired outcomes—not by feature checklists.
Identify stakeholders deliberately
Map categories relevant to your product:
- Economic buyers and budget holders
- End users and user managers
- Operational partners (support, success, ops, security)
- Risk and compliance owners
- Channel partners or implementers
- Internal sponsors and portfolio funders
- Adjacent product teams that create dependencies
Unknown stakeholders still appear—usually late, with veto power. Early identification reduces surprise cancellation of “almost done” work.
Learn challenges (not only requests)
| Shallow intake | Deeper learning |
|---|---|
| “Build export to CSV” | “Monthly board packs take 12 hours; errors cause audit findings” |
| “Need a dashboard” | “Regional managers cannot see same-day fulfillment risk before trucks leave” |
| “Add SSO” | “Enterprise deals stall in security review without SSO and logging” |
Techniques vary (interviews, observation, support analytics, sales win/loss, Sprint Review conversations, usage data). Scrum does not mandate a persona template; it demands empiricism about value. Challenges learned should influence Product Goal selection, ordering, and acceptance of outcomes.
Deliver the value they seek
Learning is wasted if it never changes the backlog. After insight:
- Express needs as clear Product Backlog items or Goal refinements.
- Order for impact on outcomes that matter (including risk and learning).
- Deliver Done Increments that enable inspection of whether the challenge actually eased.
- Adapt when evidence shows the challenge was misunderstood.
Customers vs. Stakeholders in Exam Scenarios
Use this decision tree when a question names multiple parties:
- Who experiences the product outcome? → users (and sometimes customers)
- Who pays or chooses commercially? → customers (may differ from users)
- Who influences, constrains, funds, or is impacted? → stakeholders (superset)
- Who orders the Product Backlog? → Product Owner only
- Whose needs must appear in the backlog? → many stakeholders, synthesized by the PO
- What defines success? → value in context—often customer/user outcomes constrained by stakeholder realities (legal, ops, strategy)
| Exam stem pattern | Strong direction |
|---|---|
| “Stakeholders want X; users hate X” | Investigate value; do not auto-ship X because stakeholders are louder; represent both transparently; order for product value |
| “Customer wants customization; strategy is productized scale” | Represent the need; order against strategy/Goal; avoid secret side agreement |
| “Only the sponsor’s opinion counts” | Sponsor is a stakeholder; users/customers still matter for value; PO still orders |
| “Committee votes the backlog” | Wrong—convince the Product Owner; one PO accountability |
| “Unknown users; internal stakeholders only” | Product definition incomplete; learn users/customers; risk of building the wrong thing |
Representation Without Losing Accountability
Healthy multi-stakeholder systems still obey Scrum:
| Practice | Healthy | Unhealthy |
|---|---|---|
| Intake channels | Open paths for ideas and evidence | Shadow backlogs per department |
| Ordering authority | Single Product Owner | Multiple “POs” for one product |
| Communication | PO explains order and Goal | PO hides trade-offs; politics fill the vacuum |
| Evidence | User/customer outcomes + stakeholder constraints | Only HIPPO (highest-paid person’s opinion) |
| Scaling | One backlog/Goal/PO per product | Clone Product Owners to “keep stakeholders happy” |
The Product Owner may delegate work (research, drafting items) but remains accountable for representing needs effectively and for maximizing value.
Practical Stakeholder Map Checklist
When a scenario feels political, force clarity:
- What is the product boundary?
- Who are users and customers for this product?
- Who else are key stakeholders, and what challenges do they face?
- What value does each seek (outcome, not feature)?
- What is the current Product Goal, and which needs advance it?
- Is the Product Owner synthesizing or being bypassed?
- Is there transparency so stakeholders can inspect the real order and Increment?
If you cannot answer (2) and (3), you are not ready to claim value maximization—you are guessing.
Quick Self-Check
- Product = value vehicle with boundary, known stakeholders, well-defined users/customers
- PO represents many stakeholders in the Product Backlog (synthesis, not stenography)
- Learn challenges to deliver the value stakeholders seek
- Customers/users ≠ all stakeholders; balance outcomes and constraints
- Stakeholders inform; PO orders; no multi-PO committee for one product
According to the Scrum Guide 2020 definition of a product, which elements help define a product as a vehicle to deliver value?
What does it mean that the Product Owner represents the needs of many stakeholders in the Product Backlog?
A sales leader (stakeholder) demands a feature that internal metrics show end users never use and that does not advance the Product Goal. What is the best Product Owner stance?