Understanding how to cultivate a relationship that leads to value instead of bullshit management.

I’ve got a confession for you: I hate the term stakeholder. I don’t mean I’m against stakeholders, but this terminology is one of the biggest sources of misunderstandings. This term leads to more confusion than you would ever imagine.

A stakeholder is anyone or anything that has any relation whatsoever with the product or service you work with. That’s too broad for my taste and unhelpful for most teams. 

Here are confusing everyday situations I’ve often come across:

• We need to gather requirements from our stakeholders
• Our stakeholders need to approve this feature before taking it live
• Our expectations are misaligned with our stakeholders

Why are those statements confusing? Because stakeholders can be almost anything. Whenever you hear stakeholders, the person may be talking about the sponsor, customer, business analyst, CEO, an API, institution, or anything related to your product. How can you get clarity into the scenario?

Stakeholder is an umbrella term that is a perfect breeding ground for confusion.

Now, you may wonder if the term stakeholder is so confusing. Why do we use it? Or how could we avoid such traps? No worries, I can help you out. 

Let me share what I’ve learned about managing stakeholders and how that aligns with Scrum.

Know Your Stakeholders

Treating all stakeholders the same way will put you in trouble. You’ve got to understand their power and interest in your product. That’ll simplify your decision-making process.

You’ll probably work with at least a dozen stakeholders, if not more. One thing that’s been helpful to me is creating a stakeholder matrix, a visual representation of which stakeholders to pay special attention to, and how to collaborate with them. 

The following image shows how you could work with a 2x2 matrix and categorize your stakeholders. Make this transparent to your whole Scrum team, and use it in your daily work. Don’t create and forget about it, otherwise, it’s just useless. 

Types of Stakeholders

I understand the term stakeholder is widely used in the business world. You cannot run away from it, but you can simplify it. When I’m talking to people around me, I do my best to be as clear as possible.

Not all stakeholders were born equal.

It’s common to generalize and perceive stakeholders either as customers or enemies. I like saying that stakeholders are neither one nor the other—they are your partners. Stakeholders should enable you to create the right conditions to deliver business and user value.

You may think I’m talking nonsense because stakeholders, per definition, also include business people and end-users. Theoretically, yes, and that’s the right way of creating misunderstanding. I think it’s better to have a sharper definition of stakeholders. For example:

• Business stakeholders: People who’ll help you understand the business and make your solutions viable, for example, legal, accounting, finance, business managers, etc. Business stakeholders are partners in crime but not your end-users.
• End-users: People who use your product or service. End-users are the ones you serve. Without them, your solution is meaningless. You must understand where they’re coming from, motivations, jobs, pains, and how your product improves their lives.
• Clients: This term is tricky. Clients are the ones who buy your product, but they may not be the ones using it. For example, in a B2B business model, the head of a department may buy your solution but not use it, yet this person is a decision-maker. You need to understand how your product serves your clients and end-users. Ignoring one or the other will mislead you.
• Sponsor: Your product lives because someone is funding its operation. This person or group of people is highly influential because they control the funding. Their support is critical for the product’s success. You must be closer to them and understand how their expectations align with your product.

Your customer doesn’t care how much you know until they know how much you care  – Damon Richards

Scrum and Stakeholders

A thin line between love and hate often separates Scrum teams and stakeholders. How could you have a sustainable relationship with them?

Let’s start by sharing what a bad relationship looks like:

• Scrum Master: Protects developers from interruptions. Scrum Masters ensure that no business stakeholders talk to the developers during the Sprint. The goal is to protect the team and ensure stakeholders don’t distract them.
• Product Owner: Gather requirements from stakeholders to ensure their wants are part of the Product Backlog. In this case, Product Owners spend a significant amount of time managing stakeholders and writing backlog items for them.
• Developers: They barely talk to stakeholders because their goal is to implement requirements. They get requirements from Product Owners and implement solutions. Their only interaction with stakeholders happens during the Sprint Review, but they don’t dare talk too much with business people because that’s the Product Owner’s responsibility.

Whenever you observe any of the above, you’ve got an excellent opportunity to improve your collaboration. Scrum teams and stakeholders should help each other reach the Sprint and Product Goals instead of acting as a service provider.

Now, let me share what I perceive as a sustainable relationship between Scrum teams and stakeholders:

• Scrum Master: Focus on mentoring business stakeholders to collaborate with the team as partners. Strive to encourage meaningful collaboration between business and Scrum teams and provide feedback whenever the collaboration mutates into something detrimental.
• Product Owner: Closely collaborate with business stakeholders to understand the business’s needs and how they align with end-users’ problems. Both sides challenge each other, aiming to uncover the best option for the product. Strive to build a valuable partnership that can create business and end-user value.
• Developers: Work to create meaningful solutions that solve real end-users problems. Developers talk to business stakeholders whenever needed. Both sides understand they are on the same boat and collaborate to ensure the solution makes sense for business and end-users.

The more you observe the above, the bigger your chances are to create value fast enough.

A dysfunctional relationship between stakeholders and Scrum teams will create unnecessary boundaries and silos. The outcome is ugly, resulting in all sides suffering from ordinary results. On the other hand, a functional relationship is based on context. Both sides understand what matters and how to create value. They work as a team and focus on helping each other reach goals instead of playing political games.

Final Thoughts

Clarity is vital to success. It leads to better collaboration, which means better products and more value, earning you success. That’s why you’d better be mindful of how you use the term stakeholders. I learned that the clearer, the better. You want to ensure that all sides understand what you mean. Otherwise, confusion will be a natural outcome.

It’s crucial to understand that your product cannot thrive if it doesn’t solve end-users’ problems. Scrum teams often spend time pleasing business stakeholders while forgetting who they really serve. 

You’ll be better off establishing partnerships with business stakeholders than pleasing them. Great Scrum teams know who they serve and work closely with business people to find valuable ways of solving problems and creating solutions that delights end-users.

Business is a cooperation between different persons. - Salvin Tuscano, Perfect Box Theory — A Framework for Sound and More Successful Business