Stakeholders - Who are they? What are they?

We are all stakeholders at one time or another. Being a stakeholder isn’t a job description, it is just a capacity in which we operate when needed.

Being a stakeholder isn’t a nod towards seniority or special status it is just a term that we use to define a person from within the business who needs something. Requests fall into two broad categories, promote & prevent.

Promote

Stakeholders help develop the offering by promoting new ideas that will drive value. Typically, these will be requests for new features that allow the business to grow, innovate, and outpace its competitors. These requests can be inspired by user demand as much as internal business needs. Examples of promote requests could be push alerts, automation, or digital signatures. 

Prevent

Stakeholders help avoid expensive mistakes by making requests that stop bad things from happening. Legal, risk, and compliance are good examples of teams that will have a vested interest in making sure teams are building features that are necessary to operate above board. Examples of prevent requests could be T&Cs, copyrights, GDPR, data security, and conduct.

Working with Product Owners

In order to have their requests prioritised, stakeholders need to get them on to the relevant product backlog. This means that they should develop a good relationship with the correct product owner, who is the guardian of the value of the quality and relative ordering of the items on the backlog. There are often competing priorities and pulling rank should not be condoned.

Good practise

Being a good stakeholder is about collaboration and conversation. It needs understanding and self-discipline. Top tips include: routing all requests through the relevant product owner, or head of product; providing the correct amount of detail and justification for requests being made; and providing the time to explain the need behind the request, not the solution.

What actions can I take?

Work out when I am a stakeholder and when I am not. Understand which product owners I should be working with. Help provide supporting information in a simple-to-digest format. Know when to interact, events, routines, meetings, etc. Not bypass product owners and go directly to teams.

Previous
Previous

How does an empirical process work?

Next
Next

How do I plan a release in Scrum?