Marcus has been a product manager for six years. He's seen a lot. But nothing in his career quite prepared him for the Tuesday in March when both his VP of Sales and VP of Engineering sent him identical calendar invites — title: "Roadmap Alignment" — scheduled for the same time on Wednesday afternoon.

Separately.

The VP of Sales wants more features. There are three enterprise deals currently stalled because the product is missing capabilities that competitors have. The pipeline is healthy but conversion is suffering. Every week without those features is a week those deals could go to a competitor.

The VP of Engineering wants to stop shipping features entirely for one sprint. The codebase has accumulated six months of technical debt. Two senior engineers have flagged burnout. The incident rate is at an all-time high, and the next major feature launch will be built on a foundation that could collapse under load.

Both of them are right. Both of them are coming to Marcus expecting alignment. And Marcus knows, with bone-deep certainty, that if he walks into those meetings without a plan, he will leave them having picked a side — which means he will leave them having made an enemy.

This is one of the hardest recurring situations in product management: the conflict between two senior stakeholders who both have legitimate, well-founded priorities that are currently incompatible.

Why the Standard Advice Fails

Most PM advice about executive conflict falls into one of two buckets:

"Facilitate a conversation between them." This assumes that if you get the VP of Sales and VP of Engineering in a room together, they'll reason their way to a shared understanding. In practice: they'll each present their case, neither will fully capitulate, and the meeting will end with vague agreements to "find balance" that don't survive contact with the next sprint planning session. The conflict goes underground. It resurfaces three weeks later, more entrenched.

"Escalate to the CEO." This is the right move sometimes. It's the wrong first move almost always. Escalating to the CEO signals that you can't navigate organizational conflict — which is a core PM competency. It also forces the CEO to adjudicate a conflict between two of their direct reports, which creates resentment regardless of whose side they take.

The reason both approaches fail is the same: they treat executive conflict as a disagreement that needs a winner. It isn't. It's a resource allocation problem that needs a reframe.

The Incentive Archaeology

Before you can navigate this conflict, you need to dig beneath the stated positions to the actual incentives driving them.

For the VP of Sales:

  • Surface position: "Ship the three missing features."
  • Incentive: Not lose the three pipeline deals. Not miss Q2 quota. Not be in a position where they're losing to competitors on features.
  • Underlying fear: "If we don't ship this, I miss numbers. If I miss numbers, I lose credibility with the board."

For the VP of Engineering:

  • Surface position: "Stop shipping features for one sprint."
  • Incentive: Reduce the incident rate. Prevent engineer attrition. Rebuild technical confidence that the team has been losing.
  • Underlying fear: "If we keep shipping at this pace, something will break in production at the worst possible time, and we'll spend three weeks in crisis mode instead of building."

Now notice what you have: two people whose underlying fears are actually about the same thing — a bad outcome that damages the business. The Sales leader's fear is a bad outcome in Q2 revenue. The Engineering leader's fear is a bad outcome in Q2 reliability. Both fears are legitimate. Both are pointing at real risks.

The conflict isn't that their incentives are opposed. The conflict is that they haven't seen the picture together.

The Unified Framing Approach

The Unified Framing Approach is the mental model that breaks this pattern. Instead of treating the two priorities as competing, you reframe them as two dimensions of the same risk picture.

Here's how Marcus prepares for both meetings:

Step 1: Build the shared risk picture

Create a document that presents both sides of the argument honestly — not diplomatically, but analytically:

Q2 Revenue Risk: Three enterprise deals ($420K ARR) are currently at risk due to feature gaps. Estimated probability of loss: 60-70% if features don't ship by end of April. Expected impact of full loss: ~$420K ARR and three reference customers.

Q2 Technical Risk: Current incident rate is 2.3x baseline. P99 latency has degraded 40% over last two sprints. Engineering has flagged that next major release is being built on components with known stability issues. Estimated probability of a production incident during next major launch: 65-70%. Expected impact of major incident: 2-3 days of remediation, potential customer churn from affected accounts.

The Trade-off: Shipping the three features on the current timeline addresses the revenue risk but increases the technical risk. Taking the tech debt sprint addresses the technical risk but worsens the revenue risk. A structured compromise may be able to reduce both risks simultaneously — but it requires a clear decision from leadership about the relative priority of each.

Step 2: Propose a structured compromise

Most executive conflicts can be partially resolved through a structured compromise that doesn't fully sacrifice either priority. For Marcus, the proposal looks like this:

Option A: Pure revenue priority Ship all three features on current timeline. Defer tech debt entirely. Revenue risk ↓ Technical risk ↑↑

Option B: Pure technical priority Full tech debt sprint. Communicate proactively with Sales on deal status. Revenue risk ↑↑ Technical risk ↓

Option C: Hybrid (recommended) Ship two of the three features (the two with highest deal-velocity impact) over the next three weeks. Reserve the last week of the sprint for targeted tech debt work on the three highest-risk components. Communicate timeline shift to Sales for the third deal — frame as "ensuring a stable launch." Revenue risk ↓ (two of three deals protected) Technical risk ↓ (partial but meaningful reduction)

The key: you're presenting this as a risk-informed trade-off framework, not as your opinion about whose priority is more important.

Step 3: Present both meetings identically

Here's the move that most PMs miss: walk into both meetings with the same document, the same framing, and the same proposal. You are not an advocate for either side. You are the only person in the organization who sees both sides of the complete risk picture.

When you present to the VP of Sales:

"I want to share something with you before we talk about roadmap. I've been building a complete risk picture that includes both the revenue risk you're seeing and a technical risk that I think you should understand. I don't have an opinion about which risk is worse — that's a business judgment that should come from leadership. But I want to make sure that decision gets made with full information. Here's what I'm seeing."

When you present to the VP of Engineering:

"Same thing" — you share the same document.

Both stakeholders will feel heard. Both will see that you're not taking sides. And critically: both will learn something about the other's risk that they didn't fully appreciate before.

In most cases, this shared visibility shifts the conversation. The VP of Sales hasn't been thinking about the technical risk. The VP of Engineering hasn't been calculating the revenue exposure. When they see each other's real situation, the need for a structured compromise becomes apparent to both of them — without you having to advocate for it.

The Escalation Decision Tree

Sometimes the Unified Framing approach doesn't produce alignment. The two VPs review the shared picture and still want incompatible things. When that happens, you need to escalate — but escalate cleanly.

Use this decision framework:

Question 1: Can you find a decision that serves 70%+ of each priority? If yes → present the hybrid option and request a decision from both VPs jointly.

Question 2: Is this conflict about resources (people, time, money)? If yes → escalate to whoever controls the resource allocation. Frame as: "I need a decision about resource prioritization between these two priorities. Here are the trade-offs."

Question 3: Is this a values conflict (speed vs. quality, revenue vs. reliability)? If yes → escalate to the CEO or CPO. Frame as: "This is a question about what we optimize for as a company when these two things conflict. I don't think this is my call to make."

Question 4: Is the conflict unresolvable at the VP level because it requires trade-offs that affect the company's strategic direction? If yes → bring both VPs and CEO together. Present the unified picture. Make the escalation explicit: "I'm bringing this to leadership because this decision requires business context that I don't have access to."

The critical rule throughout: always bring a recommendation, even if you're escalating the decision. "Here's the conflict, here are the options, here's what I'd recommend, and here's why" establishes you as a professional navigating ambiguity — not a PM who got stuck.

Protecting Your Relationships After the Decision

Once a decision is made — even a decision you recommended — the stakeholder who "lost" in the trade-off will need careful relationship maintenance.

Three things to do after a conflict resolution:

  1. Privately acknowledge their sacrifice. "I know this wasn't the outcome you were hoping for. I want you to know that I understood the risk you were carrying, and I'll be tracking [specific metric] closely."

  2. Create a explicit future commitment. "Once the tech debt sprint is complete, I'm committing to make the enterprise feature deal my top priority in Q3. I'll put that in writing."

  3. Follow the outcome closely and share data. If the decision was made and the predicted outcome materialized — either the sales win or the tech improvement — share that data with both stakeholders. Let the outcome teach rather than making it a personal vindication.

The Prodinja Angle

Navigating conflicting VP priorities requires multi-stakeholder context that's almost impossible to hold in your head simultaneously — particularly in fast-moving organizations where each VP's position is shifting regularly. Prodinja's Conflict Radar scans your journaled interactions and surfaces contradictions in stakeholder priorities before they become meetings you're unprepared for. It also generates Unified Framing suggestions calibrated to the specific incentive structures of each stakeholder involved.

For the broader framework of working within a complex stakeholder ecosystem, see the Complete Guide to Stakeholder Management.

Key Takeaways

  • Conflicting VP priorities aren't a disagreement to adjudicate — they're a risk trade-off to make visible. Build the unified risk picture before you walk into either meeting.
  • Incentive archaeology reveals that both sides usually fear the same thing in different forms. Surface the shared fear, and the need for compromise becomes apparent to both parties.
  • Walk into both meetings with the same document. You're the only person with the full picture. Present it identically — don't be an advocate for either side.
  • Escalate when the conflict requires a values decision or resource allocation above your authority — but always with a recommendation, never with just the problem.
  • Protect the relationship of the "losing" stakeholder through private acknowledgment, future commitment, and data sharing. Decisions without relationship maintenance become the seeds of the next conflict.