Working with stakeholders as a Product Owner

Every Product Owner meets the same afternoon sooner or later. The sponsor wants a reporting feature before the next board meeting. A key customer needs an integration, and the support lead has a list of fifteen annoyances. They are all reasonable, and they cannot all be first. How the Product Owner handles that afternoon is most of the job.

Who the stakeholders are

The Guide does not define "stakeholder" at length. It uses the word for the people the Scrum Team collaborates with and who are affected by the product. It says the Scrum Team is responsible for stakeholder collaboration, that the Product Owner may represent the needs of many stakeholders in the Product Backlog, and that the Sprint Review is where the team and its stakeholders look at the outcome and decide what to do next.

The SBOK® Guide is more explicit and splits business stakeholders into customers, users and sponsors. The customer is the individual or organisation acquiring the product. Users directly use it. The sponsor provides funding and resources and is the stakeholder to whom the team is accountable. It also notes that one person may hold several of these, for example when the sponsor is also the customer. It assigns the Product Owner the responsibility for keeping stakeholders engaged, with four recommended actions: ensure collaboration and involvement, continually assess the business impact, maintain regular communication and manage expectations.

A working list for your own product is usually longer than that: internal users, support and operations, legal and compliance, sales, partners, and the leadership who fund the work. Write the list down. People who are not on it find other ways to be heard.

What the Guide gives you

Two sentences in the Guide do a lot of work for a Product Owner. First, those wanting to change the Product Backlog can do so by trying to convince the Product Owner. Second, for Product Owners to succeed, the entire organisation must respect their decisions, and those decisions are visible in the content and ordering of the Product Backlog and through the inspectable Increment at the Sprint Review.

Together they describe a working relationship. Stakeholders are free to argue. The Product Owner is free to decide. The decision is in the open, and the Increment shows whether it was a good one. Without the first, stakeholders feel shut out. Without the second, the backlog becomes the sum of whoever shouted last.

Habits that work

Listen for the need, not the feature. A stakeholder asks for an export button. The need may be monthly reporting for a finance team, which a different feature solves better. Asking "what would you do with it?" brings that to the surface without a debate.

Make the order visible and give reasons. A Product Backlog that stakeholders can read, with the Product Goal at the top, answers many questions before they are asked. When you move an item down, say why, in terms of the goal and value, not in terms of capacity.

Say what would change your mind. "This is below the Sprint Goal work now. If three more customers ask for it or the renewal date moves, it comes up." This turns a refusal into an agreement about evidence. We cover refusing in how a Product Owner says no.

Bring them to the Review. The Guide calls the Sprint Review a working session, not a presentation. Stakeholders who see the real Increment give different feedback from those who read a status report.

Be regular, not occasional. The GOV.UK Service Manual advises making prioritisation decisions on a steady rhythm, for instance weekly for the sprint backlog and quarterly for the wider roadmap, based on performance analysis, user research and stakeholder input. A rhythm gives stakeholders a time to be heard and spares you ad hoc lobbying.

A worked example: three requests, one week

This is an illustrative situation. A Product Owner for an online appointment service has three requests on Monday.

The sponsor wants a dashboard of bookings for the board meeting in three weeks. A large customer wants calendar sync with their own system, and says they might not renew without it. The support lead wants fixes for a confusing cancellation flow that generates about a third of her team's tickets.

The Product Owner asks each person for the outcome. The sponsor needs one chart for the meeting and will not use the dashboard afterwards. The customer's renewal is in four months, and the sync would take most of a Sprint. The support lead can show ticket counts.

She decides: a simple booking chart is built from existing data in two days and goes into the next Sprint. The cancellation fixes are the Sprint Goal for the Sprint after, because they cut cost and also improve the product for everyone. The calendar sync goes on the backlog with a date to review it before the renewal, and she tells the customer exactly that. All three hear a reason, and the order is in the backlog where they can see it.

None of them gets everything. Each knows where they stand, and each can challenge the reasoning with new evidence.

What the Scrum Master does

The Guide says the Scrum Master serves the Product Owner by facilitating stakeholder collaboration as requested or needed, and serves the organisation by removing barriers between stakeholders and Scrum Teams. In practice that means setting up a Review stakeholders want to attend, coaching a sponsor who sends tasks straight to Developers, and noticing when the Product Owner is overloaded by too many conversations.

Common mistakes

• Treating the loudest as the most important. The order should come from the Product Goal and the value, not from volume.
• Promising dates in corridors. An estimate given to a stakeholder in passing becomes a commitment. Refer to the Product Backlog and the next Review.
• Hiding trade-offs. If a request displaces another, say so. Silent trade-offs become disputes later.
• Delegating all contact to someone else. A Product Owner who never speaks to stakeholders loses the information they need. See the proxy Product Owner problem.
• Letting stakeholders instruct the Developers. The Developers take their work from the Sprint Backlog. Requests go through the Product Owner.

How to practise it

Choose your three loudest stakeholders and write what each actually needs, in a sentence. If you cannot, you have found your first conversation. In the simulator you play the Product Owner or deal with one, and you see how a plausible request changes when it meets the Product Goal.