Melissa Perri identified the build trap: building more does not make you better at building the right things. It makes you a more sophisticated producer of the wrong things. I want to name something adjacent. Something I see just as often, yet rarely questioned: the stakeholder management trap. Managing stakeholders more does not make you a better product professional. It makes you a more sophisticated reactor to problems that should perhaps not exist in the first place.
This is not a comfortable thing to say. Stakeholder management content is everywhere. It generates likes, fills training calendars, and speaks to a genuine felt pain. I understand why it is popular. But I think its popularity is partly the problem. Every article that teaches you to map your stakeholders more carefully, every workshop that drills you in expectation management techniques, every framework that helps you colour-code who to inform and who to satisfy — all of it treats the symptom. None of it asks why the symptom keeps returning.
I want to ask that question here.
Managing is not leading
Let me start with the language, because I think it matters more than it seems.
You manage things. You lead people.
Stakeholder management is a revealing phrase. It implies something reactive — a response to pressure, a containment of friction, a cleanup after something has already gone wrong. When I hear a product professional say they spent most of their week doing stakeholder management, I do not hear competence. I hear a signal. Something upstream is not working, and this person is absorbing the consequences.
Stakeholder engagement is a different posture entirely. It is proactive, relational, and purposeful. You engage someone because you have something worth sharing, a question worth asking, or a perspective worth testing. You are in motion toward something. You are not waiting for the fire to find you.
The distinction matters because it changes what you optimise for. If your goal is to manage stakeholders, you get better at managing them. If your goal is to build something valuable, you get better at that. Stakeholder engagement becomes a natural byproduct of the work, not a parallel track running alongside it.
How the trap closes
Melissa Perri’s build trap describes a vicious cycle: organisations measure success by output, so teams keep shipping features, so stakeholders keep requesting features, so there is never time to ask whether any of it is working. The trap closes around the team before anyone notices.
I see the stakeholder management trap operating the same way.
Organisations experience friction with stakeholders. So they invest in stakeholder management skills. So product professionals get better at managing, meaning absorbing, negotiating, appeasing. So the underlying causes of that friction remain untouched. The friction returns. More stakeholder management is required. The trap closes around the professional before they notice they are in it.
And here is the part that I find most troubling: the market rewards this. There are organisations and trainers in the Netherlands — and elsewhere — building significant visibility around stakeholder management content. I do not doubt their intentions. But I do question the effect. Every time we repackage the problem as a skill to be mastered, we postpone the more important conversation about why the problem exists. We reify a dysfunction. We call it professional development.
I think we can and need to do better as professionals wrestling with the challenges of product management.
What the trap is actually protecting
In my experience working with product professionals across organisations, the same structural gaps appear again and again beneath the stakeholder management fog. Each one is a factory for the kind of friction that stakeholder management is then called in to resolve.
No compelling product vision or strategy. When nobody can articulate where the product is going or why, stakeholders fill the vacuum with their own priorities. You are not managing stakeholders in that situation. You are managing the consequences of a missing story. The fix is not a better stakeholder map. It is a clearer vision. One you can tell convincingly, that connects today’s decisions to tomorrow’s outcomes.
A project mindset wearing product clothing. I see a lot of product owners who are, in practice, project managers without a Gantt chart. They own a timeline, not a product. They manage deliverables, not outcomes. In that context, every stakeholder becomes a competing claimant on a fixed pool of capacity, and your job becomes an endless negotiation over who gets what. Shifting toward a product mindset — asking not what are we building but what problem are we solving and for whom — changes the nature of the conversation entirely. You are no longer distributing a scarce resource. You are building toward a shared outcome.
No outcome or impact metrics. Output is easy to count and easy to argue about. Features shipped, story points completed, releases made, etc. These numbers create the illusion of progress while leaving the question of value entirely open. When you have no outcome metrics, every stakeholder can claim the product is failing by their own definition, and you have no ground to stand on. Start measuring things that matter — retention, task completion, satisfaction, revenue contribution — and suddenly you have a shared language that is harder to argue with than a feature list.
No clear quality criteria. When the bar for “finished” is implicit, every release becomes a negotiation. When is it ready? What does good enough mean? Who decides? If you cannot answer these questions before you start building, you will answer them under pressure at the end, which is exactly when stakeholder management feels most necessary and is least effective. Quality criteria, agreed upfront, remove an entire category of friction before it starts.
No product discovery. When you skip the work of understanding the problem before proposing a solution, stakeholders start ordering features. Not because they are difficult, but because someone has to fill the problem-definition vacuum, and they are willing. Discovery is not a luxury for teams with time. It is the work that makes all subsequent work coherent. Done well, it transforms stakeholders from feature requestors into collaborators. People who have helped frame the problem and therefore have a stake in the solution rather than a preference about its shape.
No transparent backlog of work. A backlog that is too technical, too abstract, or too long to read is a backlog that nobody trusts. When people cannot see the reasoning behind the order of work, they challenge it. When they cannot find their request, they escalate. Transparency is not just a Scrum principle. It is a stakeholder engagement strategy. One that works by making explanation largely unnecessary.
Developers removed from the conversation. When the product owner becomes the sole interface between stakeholders and the team, something important breaks. You become an order taker. You translate, filter, interpret, and absorb. In doing so, you deprive developers of the context they need to make good decisions and deprive stakeholders of the direct understanding that builds genuine trust. Bringing developers into conversations with stakeholders is not a process risk. It is often the most powerful engagement move available.
The vantage point you already have
If you start feeling worried, there’s something I want to say directly, because I think it gets lost in conversations about mandate and organisational context.
Regardless of what your organisation calls you, regardless of how much formal authority you have been given, every product professional sits at a uniquely valuable intersection. You are close to the team. You are close to the work. You see what is being built, what is being deferred, what is accumulating as debt. You understand the gap between what was promised and what is real.
That is a position of enormous informational leverage.
A lot of the product professionals I work with believe they do not have the mandate to do the things I have described above. Some of them are right. Their organisations have genuinely constrained them. But many of them are behaving as though they lack mandate they actually have. They are waiting for permission to act like entrepreneurs when nobody has told them they cannot. They are operating as scribes when they could be leading.
The question worth sitting with is not what mandate have I been given? It is am I using the vantage point I already have?
Start from there. Build upward. Make the vision clearer. Start measuring outcomes. Bring people closer to the work. Make your backlog more transparent. A missing discovery conversation is very often within your power to initiate. The structural foundations I described above are not all equally within your reach, but most of them are more within your reach than the stakeholder management reflex suggests.
What good looks like
A sign of a product professional who has done this work is not that they never engage stakeholders. It is that when they do, it is deliberate, purposeful, and relatively brief.
They engage because they have something to share, a decision to make together, or a perspective they genuinely need. They are not managing expectations because their expectations were set well in the first place. They are not defending the backlog because the backlog explains itself. They are not absorbed in organisational friction because the product’s direction is clear enough to make most difficult conversations answerable by reference to shared evidence.
This is not a special skill. It is what good product work produces as a side effect. And it is, I believe, more achievable than the stakeholder management industry would have us think. Not because stakeholder relationships are simple, but because most of what makes them complicated is fixable at the source.
The trap is real. But so is the exit.
I share these perspectives from my own practice working with product professionals across organisations and industries. Complex work resists universal answers. I offer this as a provocation, not a prescription. If it resonates, or if you disagree, I would genuinely like to hear from you.
