What you need to do
The practical activities and techniques you need to master – what to practice, what to get good at, and what to keep doing.
Stakeholder mapping
Identifying who has power, interest, and influence over your product – and tailoring your approach to each. The Power-Interest Grid (Mendelow's Matrix) categorizes stakeholders into four quadrants: high power/high interest (manage closely – these are your key decision-makers), high power/low interest (keep satisfied with high-level updates), low power/high interest (keep informed with regular updates), and low power/low interest (monitor with minimal effort). Map your stakeholders at the start of every major initiative. Update the map when organizational changes happen. The common mistake: treating all stakeholders the same. An executive sponsor needs a different cadence and level of detail than a peer in another team.
Influence without authority
Driving product development across functions without direct authority over anyone. Product managers work at the intersection of design, engineering, analytics, and marketing – but rarely have these disciplines reporting to them. Three foundations of influence: data (without it, you're just another person with an opinion), trust (built through consistency, follow-through, and competence), and relationships (the inner circle of direct collaborators, the middle circle of peer managers, and the outer circle of business stakeholders). Build coalitions strategically – start with your inner circle, get buy-in, then expand outward. Rational persuasion combines a request with logical arguments and factual evidence. The alternative – positional authority – doesn't scale and creates compliance, not commitment.
Cross-functional alignment
Making PM, design, engineering, and business agree on what to build and why. Organizations with aligned digital, marketing, engineering, and CX teams achieve 1.6× faster revenue growth and 1.4× better customer retention. The product trio (PM, designer, engineer) is the core unit – they should share context daily through standups or async updates. Beyond the trio, alignment comes from shared goals (everyone knows the outcome they're driving toward), shared context (everyone has access to user research, metrics, and business objectives), and clear roles (everyone knows who decides what). Technical requirement templates translate market needs to development tasks. Joint customer research sessions build shared empathy. The biggest alignment failure: separate goals for separate teams.
Conflict resolution
Surfacing disagreements early and finding acceptable paths forward – before they become toxic. Most product team conflicts stem from different mental models: engineering optimizes for code quality, design optimizes for user experience, business optimizes for revenue. Name the tension explicitly: 'Engineering wants to refactor first, business wants the feature now. Both are valid. How do we find a path that addresses both?' The collaborating style – assertive and cooperative – works through differences by creating space for all voices. Address conflicts promptly; unresolved disagreements don't disappear, they metastasize. Frame conflicts around the organization's broader mission: 'What would best serve our users and business?' not 'Who's right?'
Escalation handling
Knowing when to escalate, how to frame it, and how to de-escalate. Escalate when: a decision is blocked and the people involved can't resolve it at their level, a timeline is at risk and the team needs organizational support, or a conflict is affecting team health and needs intervention. How to escalate: describe the situation factually (not emotionally), explain what you've already tried, present the options with trade-offs, and recommend a path forward. Never escalate without a recommendation – bringing problems without solutions signals that you can't handle your role. De-escalate by: separating the people from the problem, focusing on interests rather than positions, and finding options that give both sides something they value.
Frameworks to know
The mental models and structured approaches that guide how you think about this skill – not rules to follow, but lenses to see through.
Power-Interest Grid
A 2×2 matrix for categorizing stakeholders by their power (ability to influence decisions) and interest (how much they care about your product). High Power / High Interest: manage closely – regular 1:1s, early input on decisions, detailed updates. High Power / Low Interest: keep satisfied – quarterly updates, involve only for major decisions. Low Power / High Interest: keep informed – regular newsletters, feedback channels, beta access. Low Power / Low Interest: monitor – minimal engagement, keep on distribution lists. Create the grid at the start of each initiative. Reassess when stakeholders change roles or when project scope shifts. The grid prevents both over-engaging low-priority stakeholders (wasting your time) and under-engaging high-priority ones (creating blockers).
RACI matrix
A responsibility assignment framework that eliminates ambiguity about who does what. For every decision or deliverable, assign exactly one person to each role: Responsible (does the work), Accountable (makes the final decision – always exactly one person), Consulted (provides input before the decision – two-way communication), Informed (told after the decision – one-way communication). The most common mistake: having multiple Accountable people, which means nobody is actually accountable. Create a RACI for recurring decisions (who approves PRDs, who decides on technical architecture, who signs off on launches) and revisit it when team composition changes. The RACI is especially valuable in cross-functional teams where reporting lines don't match collaboration patterns.
Disagree and commit
Amazon's framework for making decisions when the team can't reach consensus. After thorough discussion, if the team is split, the accountable person makes the call. Everyone else disagrees openly (their objections are recorded) and then commits fully to execution. This prevents two failure modes: decision paralysis (endless debate with no resolution) and passive resistance (people agree publicly but sabotage privately). The key conditions: the disagreement must be heard and acknowledged, not steamrolled; the decision-maker must explain their reasoning; and the team must genuinely commit to execution, not just compliance. Review the decision after execution – if the dissenters were right, update the process. The framework requires high trust and psychological safety.
Situation-Complication-Resolution
A narrative framework for framing any communication that requires a decision or action. Situation: the relevant background and context that everyone agrees on – establishes shared understanding. Complication: what changed, what's at risk, or why action is needed now – creates urgency without being alarmist. Resolution: your recommendation and the reasoning behind it – provides a clear path forward. This structure works for executive presentations, stakeholder emails, escalation documents, and roadmap discussions. It's the Pyramid Principle applied to organizational communication: lead with context, create tension, resolve with a recommendation. The complication should be fact-based, not emotional – 'Our activation rate dropped 15% after the redesign' not 'The redesign was a disaster.'
Good vs. bad
Common mistakes paired with what experienced practitioners do instead – and why the product builder approach changes the game.
Organizational navigation is the skill nobody teaches you and everyone expects you to have. I spent my first year as a PM thinking the quality of my PRDs would speak for itself. It didn't. The engineers who ignored my specs weren't bad engineers – they hadn't been involved in the decisions, so they didn't feel ownership. The moment I started including engineering in problem definition (not just solution specification), everything changed. Alignment isn't achieved through documents; it's achieved through shared understanding.
The Power-Interest Grid saved me from a pattern I didn't know I had: spending 80% of my stakeholder energy on the loudest people, not the most important ones. A VP who's passionate about your feature but has no decision-making authority shouldn't get the same attention as a quiet director who controls the budget. Map your stakeholders, then allocate your communication time accordingly. It's not about ignoring anyone – it's about giving each person the right level of engagement for their role.
Managing up is the most underrated career skill in product management. The PMs I've seen advance fastest aren't the ones with the best product instincts – they're the ones whose managers always know what's happening, never get surprised, and can confidently advocate for their team's work. A simple weekly update – what's on track, what's at risk, what I need from you – takes 15 minutes to write and saves hours of check-in meetings while building the trust that gets you more autonomy.
'Disagree and commit' is the organizational framework I use most often, but it only works in teams with high psychological safety. In teams where disagreement is punished, people 'commit' publicly and resist privately. The prerequisite is a culture where the accountable person genuinely listens to dissent, where dissenters are thanked for their perspective, and where the decision is revisited if the outcome suggests the dissenters were right. Without that culture, 'disagree and commit' is just 'comply or leave.'
Go deeper
Books to deepen your understanding beyond what fits on this page.
The classic framework for getting things done when you don't have formal power – covers exchange currencies, building coalitions, and navigating organizational politics ethically.
Tools for navigating high-stakes discussions when opinions differ and emotions run high – essential for conflict resolution, escalation handling, and cross-functional alignment.
Strategies for succeeding in a new role – stakeholder mapping, building credibility, securing early wins, and navigating organizational dynamics from day one.
How Amazon's leadership principles – including 'disagree and commit,' 'have backbone,' and 'earn trust' – create a culture where organizational navigation follows clear rules.
