What if we stopped “managing stakeholders” and started collaborating ?
Who hasn’t heard that “stakeholder management” is a skill that every Product Manager (PM) should master? But why? Aren’t PMs and their stakeholders supposed to be part of the same team, or at least of the same company ? Why should the first “manage” the others? It conveys at best the idea of influencing, and at worst of manipulating. In any case, it prevents true collaboration from happening.
Everyone is responsible for that situation. Companies, first, which still often separate business and tech people, while tech is now part of every business. That leads many PMs to still consider themselves as “tech” people and not enough as business, making in turn business stakeholders see them as providers rather than valuable counterparts.
PMs get stuck in managing the incoming demands from business people while true collaboration should aim at co-creating with them. It should lead to the unveiling of great solutions that neither Product nor Business could have found on their own, rather than choosing between Product’s or Business’ solution.
In order to achieve such a great collaboration, everyone needs to change their behaviors. To do so, we first have to deconstruct several beliefs and then learn new tools to be able to collaborate better.
Product is business, business is product
Let’s start with a brief history about Product Management. In the pre-internet ages, “Business” ruled the world. Tech was just another department in the company that you barely needed, made of developers and project managers who were supposed to coordinate and ship what the business asked for.
Then, software companies appeared in the 80s, followed by Saas companies. In these companies, “Tech” ruled the world because the company’s products were only tech products (“Product is business”, as Melissa Perri said). PM embodied tech and became all mighty. Business functions were at the service of the Product, to such an extent that the Product Department absorbed several of their jobs adding “Product” in front of them: “Product Marketing”, “Product Ops” or “Product Designer”.
With the rise of tech, beyond Saas and software companies, traditional companies started hiring PMs, mainly to prioritize what had to be done, because tech resources were never enough to answer all Business needs. By now, tech has become a key component of every product, like cars for instance that are now full of tech: “Business is Product”! Everyone in the company is now highly dependent on Tech for almost everything, like installing an off-the shelf Saas software. They can feel frustrated for having to get the approval, and more often the denial, of a person (the PM) for every decision they make.
This is probably the moment where “stakeholders management” started being a competency that every PM needed.
Collaboration is about co-creation, not influence nor convergence
The problem with “stakeholder management” is that it comes along with several implicit and negative assumptions.
In many companies, decisions are taken by one person, usually a PM but it might also be the CEO or a very influential business stakeholder. This creates a very limiting vertical relation: as soon as the solution is imposed by one person or one department, it kills collaboration and makes it shift into coordination: please organize yourself to deliver what has been asked for. The person who made the decision will try to convince or influence the other stakeholders that their solution is the right solution for them, undermining their engagement.
In some other companies, decision making is more collective: everyone has its words to say. Managing stakeholders is then more about convincing the other side that one’s solution is the best. It’s more of a competition than a collaboration, as if only one solution could win. It prevents co-constructing a third solution that could be a better solution for both stakeholders, rather than downgrading tech or business’s solution to please the others.
Being part of separate BUs reinforces a kind of “mistrust”, fuelled by “negative intentions” that prevent both parties from having good discussions. For instance, on the PM side, one might think that “Business does not understand anything about tech, so we won’t even try to explain them”. Same on the business side : “These Product/tech people are so disconnected from the real business world, they don’t understand what is at stake”. Pushing it to an extreme, it leads to a “us vs them” approach. I want to protect the interests of my BU (marketing, sales, tech) instead of maximizing the interests of a Customer-Oriented Product Team. In an ideal word, people should feel they belong first to a Product team before their own BU!
The right solution should never be imposed or forced. It should be naturally agreed on by every stakeholder. But that requires empathy and trust to have constructive discussions even if people might disagree at first. First, empathy to be able to consider the situation from another stakeholder’s perspective and then trust to acknowledge that other stakeholders do not disagree to annoy you ! But trust takes time to build that companies do not always have (or rather do not think it is important enough to take vs. shipping at all costs).
So how to make this true collaboration happen? We need to change our behaviors to better collaborate.
Beliefs we need to get rid of in order to better collaborate
Beliefs prevent us from changing our behaviors (more about this in the Dilts Pyramid), especially one : individual ownership. Think about it: when starting a new project, to what extent having a clear ownership carried by one person is key to you? If this is a tech related project, there are chances that the PM will carry the ownership.
But does a clear individual ownership really help deliver a better outcome? Does it foster a true collaboration? We think the answer is negative. Making one individual responsible for a whole project makes all the others less responsible. It also puts an overdue pressure on the individual owner.
But if you do not assign individual ownership, how can you be sure that someone will feel responsible for the team? Through shared responsibility. Everyone needs to feel responsible for the project, to the same level. Think of a relay stick. When a stick falls between two runners, who is responsible? The runner who gave it? The one who received it? The team trainer? The maker of the relay stick? Everyone has their share of responsibility.
So responsibility can be shared, and even must be shared, so that everyone feels concerned. But responsibility can be diluted, so you have to limit the size of the team to less than 10 persons in order to avoid responsibility becoming too diluted. Good news, all product teams are made of less than 10 people. What if you need to scale ownership? Create teams of teams.
What other beliefs should we deconstruct? Perhaps the one stating that the PM is the CEO of the product. You must have understood reading this article that it both creates a vertical relationship while attributing the whole responsibility on a single person.
Another deeply rooted belief is about meetings. Meetings are key to collaboration but they have been discredited. Some companies even proudly claim that they got rid of every meeting. But meetings can be great! The most hurting belief is that a meeting is more efficient with the smallest amount of people required in the room. Hush… You miss important perspectives from the uninvited, and you will need to convince all the persons who were not there that the decision you took in a small committee is the right one, probably through additional meetings. In the next paragraph you will find the perfect tool to invite as many people as you want in your meetings.
Last belief : you can’t challenge “expert” people (tech, ops, marketing…) if you are not an expert yourself… But challenging is critical to shape up good decisions, and challenging doesn’t mean you don’t trust the person. Some argue that they can’t challenge experts because they don’t understand the technical points. It doesn’t prevent them from asking questions, and the person being challenged should be able to explain in simple terms why they took the decision. To quote the French writer Boileau, “Whatever is well conceived is clearly said, and the words to say it flow with ease”. If the person is not able to do so, you might wonder if it’s really clear for them. You might also help the person to clarify their thoughts.
In every case, by sharing responsibilities, by making many people share their perspective through meetings, and by challenging the experts, you should foster true collaboration. Now that we got rid of our limiting beliefs, it still remains the competencies issue.
What we need to learn for a better collaboration
Indeed, even if you are now convinced you need to cooperate better, you still need the right skills or tools to collaborate. Here are some artifacts that proved to be very efficient to ease collaboration.
1–2–4-All would be the first tool we recommend. It’s a core exercise of the Liberating Structures created by Henri Lipmanowicz and Keith McCandless. It’s a very simple way to hold meetings with as many participants as you wish. The key is to parallelize the discussions between groups that become bigger as the meeting goes on: first individuals, then pairs, then groups of 4 and then the whole assembly. Everyone has to participate, everyone has the same share of voice, and the time constraint makes them very efficient.
Another very useful artifact is Event Storming. It was created by Alberto Brandolini whose book is in free access. It’s a great way to have many different stakeholders collaborate and share their perspectives on a business flow. It is mainly about agreeing on flows and words to finally unveil all ambiguous elements. For instance, what does this “approval of the profile” really consist of during the registration process? What happens when the profile is validated by a KYC department? There are often way more ambiguities than one could imagine. You will be amazed by the results it brings!
Absolute responsibility is a principle that lies in several ancient philosophies. It is also a pillar of the great Austrian psychologist Adler. More recently, Jocko Willink made it popular through his book telling how the Navy Seals used this concept in Iraq. To summarize it in a few words, when a problem occurs, it consists in avoiding excuses and always asking oneself: what could I have done to avoid the problem? For instance in the Product world, if the Developers did not code properly a functionality, was I clear enough expressing my need as a business person? Did I test the functionality as a PM? If I (PM) complain that business people are fluffy, did I challenge them enough? Did I go and see them on the field to really understand the problems they were facing ?
The Product Pyramid can also prove to be very useful to have constructive discussions. Based on Dilts’ Pyramid and NVC (NonViolent Communication) framework, it forces business and people Product to go up to the right level of the Pyramid until they converge instead of keeping stuck at the lowest level, the solution’s one. People rarely agree on the solution, way more often on the needs! Once convergence is found, you can try to find a new solution that fits everyone’s needs.
A last artifact you could use is the Gemba Walk, a classic from the Lean methodology. In a nutshell, it consists of going down to the field (the Gemba) to observe actively how operators do a task. By actively, we mean that the observer must always ask himself why the operator does his task the way he does. You should not judge, just be curious. For instance, business people could come and see a test session, a sprint planning. On the contrary, tech people could come and sit behind an Ops team member at the customer support center or attend a meeting with a sales rep.
Conclusion
As we could see, “Managing stakeholders” comes with several limiting behaviors as regards team work. So why is it so widespread? Because it is easier to manage stakeholders than to collaborate with them. Collaboration requires empathy, trust, time, creativity to elaborate new solutions that bring more value than the initial solutions. It implies that we get rid of deeply rooted beliefs and that we learn new tools. But the outcome is really worth it. According to Jeff Sutherland, one of the writers of the Agile Manifesto, an A team outperforms a B team by a 1000 x factor, while an A player outperforms a B player by a 10 x factor… think about it, you have no more excuses not to truly collaborate!
If you enjoyed reading this article, feel free to subscribe to my Newsletter (every quarter). It talks about Product, Business, HR, Management… (mix of French and English articles). If you want to have a look at the kind of articles I write, feel free !
If you want to learn more about Discovery, I created a 5 sessions training that keeps improving after every session’s feedback. The average mark is 9,5 out of 10, dozens of respondents coming from top French scale ups.
My new project WILL also deals with trainings, helping employees solve their recurring problems at work for long: misalignment, bad collaboration, overload, conflicts, micro-management…
