The word stakeholder makes people sound like categories. In practice they are just people with jobs, and each of them is looking at the same product through the part of it that affects their week.
The same product looks like different problems
Someone using a system daily sees friction: steps that take too long, things they have to remember. Someone managing that team sees visibility, whether they can tell what is happening. Someone accountable for risk sees exposure. None of them are wrong, and none of them are describing the whole thing.
Learning to hold several of these at once, without immediately trying to reconcile them, was one of the more useful shifts for me.
Resistance usually has a reason
When someone pushes back on something that seems obviously good, the reflex is to explain it again, louder. That almost never works. The more productive move is to assume there is a reason I have not heard yet and go looking for it. Often there is a downstream consequence I did not know about, or a previous version of this idea that went badly.
Adjust the level, not the substance
I talk about the same decision differently depending on who is in the room, and for a while I worried that this was a kind of dishonesty. It is not. An engineer needs the constraint and the edge cases. A business stakeholder needs the outcome and the trade-off. Giving each of them the version they can act on is the job. Changing the actual content between rooms is where it would become a problem.
Write down what was decided, not just what was said
Notes that summarise a discussion are much less useful than notes that state the decision, the reason, and who is doing what. It sounds bureaucratic. It has saved me repeatedly, because a decision without a recorded reason gets relitigated a month later by people who are all sure they remember it correctly.
Silence is not agreement
The person who says nothing in a meeting is often the person who will be most affected. I have learned to follow up separately rather than reading quiet as consent.