Why I believe stakeholder management is the survival skill of a product manager – and how RACI helps you not go crazy
The first time I sat in on a talk about product management, I eagerly thought this job was only about “coming up with new features,” drawing wireframes, and then handing over to the dev team. But when someone asked: “So who will approve the budget?” – the whole room fell silent. At that exact moment, I suddenly realized I had completely misunderstood. Being a product manager is not only about managing the product, but also about managing people – especially those who have decision-making power, have interests, and have influence over your project. They are collectively called stakeholders. And what I believe most after self-studying this topic is: stakeholder management is exactly what determines whether your product lives or dies, no matter how good the code is.
If you are also on the path of learning about product management, this article will not only tell you who stakeholders are, but also help you understand why classifying them, managing expectations, and using tools like RACI are so important. This is knowledge I have just learned from my own self-study process, and I want to share it in the most understandable, approachable way – not as a teaching expert, but as a fellow learner, struggling together with this tangled mess.
Stakeholders are not just “people involved” – they are a network of power
When hearing the term “stakeholder,” many newcomers will think of bosses, customers, or partners. True, but not enough. In a product management project, stakeholders range from the company’s CEO to the general public, with very different levels of influence and interest. Some have high decision-making power, some only care about a small corner, and some do not even know you exist but are affected by the product you make. The scariest thing is: stakeholders with high levels of influence and interest can strongly impact the project, even push it to the brink of cancellation.
That is why the first thing I learned was to identify and classify them deliberately. Not everyone needs to receive the same kind of information. For example, your CEO may only want a one-page update every week, while an engineer needs a detailed report on the work they are responsible for, how much time it takes, and whether there are any blockers. If you send the CEO a 20-page Excel spreadsheet, or send the engineer a generic strategy slide, you will quickly lose trust from both sides.
In addition, stakeholders are divided into internal and external. Internal ones may be middle managers, functional teams, or the finance – accounting department. External ones may be suppliers, end users, or distribution channels. Each group has its own language, goals, and pressures. Newcomers like me often only focus on customers, forgetting that the accounting team can also be the one who approves expenses, or that a supplier can break the supply chain if they do not see the benefit of cooperating. So, the first practical advice for you: make a stakeholder list as soon as the project starts, assess each person’s level of influence (low – medium – high) and level of interest (low – medium – high). From there, you know how much time to spend on them, and what form of communication to use.
Your role: managing expectations and controlling mutual influence
Many people think that a product manager only needs to “please” stakeholders. But after learning this, I realized the real job is managing their expectations – that is, making them clearly understand the project’s constraints, and the reasons why those constraints exist. For example, if a customer asks that the feature run twice as fast while the budget stays the same, you need to sit down and clearly explain the trade-off between speed, cost, and quality. That is exactly when you have to be the “bearer of bad news” yet still not make them lose trust.
What is even harder is that you also have to manage how one stakeholder influences another. Consider the situation in the lesson I compiled: Raj is a supply director, always determined to find the cheapest supplier, even though he knows that a higher-quality component is necessary. Raj’s decision can force the engineering team to adjust the design, and ultimately reduce the product’s lifespan from 8,000 hours to 2,000 hours – something your customers definitely do not want. At this point, you cannot always simply say “Raj is wrong” because he has his own reasons; instead, you have to find a way to balance Raj’s cost goals with the actual needs of the customer.
One of the measures I find interesting is restricting access to information at certain stages. It may sound undemocratic, but in some contexts, letting a highly influential stakeholder directly access all sensitive information can cause unnecessary disruption. You need to proactively control the flow.
Top comments (0)