Stakeholder Management

Why Stakeholder Management is a Core PM Skill

A product manager has almost no direct authority. You typically cannot order engineers to work overtime, tell the CEO their idea is wrong, or force sales to stop promising features that do not exist yet. Instead, a PM leads through influence, evidence, and relationships. Managing stakeholders well is not a "soft skill" on the side of the job -- for many PMs, it is the majority of the job.

A stakeholder is anyone with an interest in, or influence over, your product: engineers, designers, the CEO, sales, support, legal, compliance, external partners, and sometimes regulators. At a company like Flutterwave or Access Bank, a single feature might touch product, engineering, compliance, risk, and a banking partner -- all with different priorities.

---

Mapping Your Stakeholders

A simple power/interest grid helps decide how much time to invest with each stakeholder:

Example: At a fintech like Paystack, the Head of Compliance is high power (can block a launch) but may have variable interest depending on the feature -- for a new savings product involving regulatory approval, they move into "manage closely." A regional sales rep might have high interest in a delayed feature but comparatively lower power to change the roadmap -- so they belong in "keep informed."

---

Managing Up

"Managing up" means proactively managing your relationship with people senior to you -- your manager, the VP of Product, or the CEO -- so they trust your judgement and are not surprised by outcomes.

Effective managing up looks like:

• Come with a recommendation, not just a problem. Instead of "checkout conversion dropped 8%, what should we do?", say "checkout conversion dropped 8% after the last release; I believe it's the new form field, and I recommend we roll it back while we investigate -- can I get sign-off?"
• Over-communicate on risk, under-communicate on routine wins. Leaders need to hear about problems early, not at the last minute. Small wins can go in a written update rather than taking meeting time.
• Translate your world into their language. An engineering delay caused by a flaky third-party payment gateway from a partner bank should be explained to the CEO in terms of business impact ("this delays the savings launch by two weeks and affects Q3 revenue targets"), not just technical detail.
• Ask for what you need directly. If you need budget, headcount, or a decision, say so clearly rather than hinting.

---

Building Alignment Across Teams

Alignment does not mean everyone agrees -- it means everyone understands the decision and why it was made, and can commit to executing it even if they preferred a different option.

Techniques that build alignment:

• Share the "why" early, not just the "what." When engineers understand a feature exists because Moniepoint agents are losing transactions during network outages, they build better solutions than if just handed a spec.
• Involve people before decisions are final. A stakeholder who is consulted during the process, even briefly, is far more likely to support a decision they did not fully choose.
• Write things down. A short decision doc or PRD prevents the "I thought we agreed on X" problem weeks later.
• Close the loop after launch. Tell stakeholders what happened as a result of the decision -- this builds trust for the next disagreement.

---

Handling Difficult Stakeholders

Every PM eventually meets a stakeholder who is demanding, dismissive, or simply disagrees loudly. Some patterns that help:

The "everything is urgent" stakeholder

A sales lead insists every customer request is a P0. Response: ask them to rank their own top 3 requests, so their most important asks do not get lost in a flood of "urgent" items. This also teaches them to prioritise internally before escalating.

The HiPPO (Highest Paid Person's Opinion)

A senior executive wants a feature built based on gut feeling, contradicting your user research. Response: do not simply say no. Show the data respectfully, propose a small, cheap experiment to test the idea, and frame it as "let's validate this quickly" rather than "you're wrong."

The stakeholder who was not consulted and is now upset

Someone finds out about a decision late and feels blindsided. Response: apologise for the process gap sincerely, explain the reasoning, and ask what information from them would have changed the outcome -- then actually include them going forward.

The chronically skeptical engineer or designer

Someone repeatedly pushes back on scope or feasibility. Response: often this reflects a past experience of being steamrolled. Involve them earlier in discovery, not just at handoff, so their expertise shapes the solution rather than reacting to it.

---

A Worked Example

At a Nigerian logistics startup, the Head of Operations (high power, high interest) is worried that a new same-day delivery feature will overload riders during the December rush. The engineering team (has already built half the feature) wants to ship on schedule. The CEO wants the press release ready for a launch event.

A PM handling this well would:

1. Map the stakeholders -- Operations is high power/high interest; CEO is high power/high interest; engineering is high power/medium interest on timing specifically.
2. Gather the real constraint -- talk to Operations about exactly how many riders and what capacity threshold is safe.
3. Propose a middle path -- launch in one city first as a pilot, satisfying the CEO's need for a launch date and Operations' need for safety, while giving engineering a smaller, lower-risk rollout.
4. Communicate the decision and why to all three groups, in the language each cares about (safety data for Operations, a real launch date for the CEO, a manageable scope for engineering).

This is stakeholder management in practice: not making everyone happy, but making a defensible decision everyone understands.