Stakeholders, Customers and Users
Three different relationships
Users interact with the product. Customers choose and often pay for it - they may never use it. Stakeholders have an interest in or influence over the product: internal groups, regulators, support, sales, partners. A candidate should be able to say why conflating them causes bad decisions - for example, optimizing for the buyer while ignoring the daily experience of the user.
The Product Owner is the single point of accountability for ordering, but not a wall between the team and the world. Effective Product Owners maintain open, frequent contact so the team hears problems first-hand. The Sprint Review is the primary recurring collaboration point with stakeholders: it is a working session where the Increment and the Product Backlog are inspected and adapted together. Invite broadly and deliberately.
Traps
- Restricting the Sprint Review to a demo for a chosen few, or turning it into a status report.
- Letting a stakeholder act as a proxy Product Owner, filtering and reinterpreting requests.
- Collecting requirements once and disappearing until delivery.
- Assuming stakeholders must never speak to Developers; collaboration is encouraged, decisions stay coherent through the Product Owner's ordering.
- Confusing “managing stakeholders” with saying yes to everyone.
Worked example
Two departments want conflicting features. The Product Owner maps stakeholders by influence and interest, meets each to understand the underlying problem and impact, then brings both to the Sprint Review with a transparent ordering that explains the trade-off. Disagreement is surfaced as evidence and value, not as escalation.
Rule of thumb
If a stakeholder request arrives as a solution, ask one level up: what outcome would this create, and how would we know?