Aruna Veerappan is Senior Director of Engineering at Upwork, leading Developer Enablement to reduce friction and boost team productivity.
Every product engineering leader knows the feeling. The product team wants a feature shipped yesterday. Engineering warns that the database may not survive the additional load. The meeting ends with one side prevailing and the other reluctantly accepting the outcome, until the same disagreement resurfaces a few months later.
The tension between the product and engineering teams is not a flaw. It is a structural characteristic of how modern software organizations operate. Product management is measured by customer value, market impact and business growth. Engineering is responsible for reliability, scalability, security and long-term system health. When both groups are performing their roles effectively, disagreement is inevitable.
The real question is not whether conflict will occur. It is whether the organization has a mechanism to make that conflict productive rather than destructive.
Stage 1: Diagnosing The Source Of Conflict
The first step is to stop debating solutions and identify the actual source of disagreement.
Most prioritization conflicts fall into one of four categories:
• Goal Conflict: Teams disagree on what success looks like.
• Timeline Conflict: Teams disagree on when work must be delivered.
• Resource Conflict: Multiple initiatives compete for limited capacity.
• Process Conflict: Teams disagree on how work should be executed.
Many organizations treat all disagreements as the same problem. As a result, identical arguments repeat every planning cycle.
Classification changes the conversation. Instead of “you are being unreasonable,” the discussion becomes “we have a structural misalignment that needs resolution.” Separating the people from the problem can reduce defensiveness, increase psychological safety and enable more objective decision-making.
Stage 2: Aligning Through Quantifiable Trade-Offs
The heart of the framework is a multi-criteria decision model (MCDM) that evaluates competing priorities using measurable criteria rather than opinions.
The scoring model is:
Score = (0.50 x ROI) + (0.30 x Risk Retention) + (0.20 x Reputational Damage)
Each initiative receives a score from 1 to 5 across all three dimensions.
This approach intentionally prevents a common organizational failure mode: prioritizing revenue-generating features while consistently postponing investments in reliability, scalability and technical debt.
To maintain objectivity, scoring should be anchored to measurable indicators such as service level objective (SLO) adherence, DORA metrics, customer impact data, compliance findings, incident trends or experimentation results.
Example
Consider a situation where product proposes a new sign-up experience projected to increase revenue. At the same time, engineering recommends database refactoring to address recurring SLO violations.
Historically, the feature would likely win because of its direct business impact. Under the MCDM framework, however, the database initiative may achieve a higher overall score due to its elevated risk and reputational impact. If the infrastructure work scores 3.5 while the feature scores 3.0, the organization can prioritize system health with a transparent and defensible rationale.
The decision is no longer based on influence or opinion. It is based on agreed-upon criteria.
Strategic Capacity Balancing
To reduce recurring timeline and resource conflicts, the MCDM should be paired with a modified “three horizons” planning model:
• Horizon 1: Short-term product delivery (50% to 70%)
• Horizon 2: Platform modernization and engineering health (20% to 40%)
• Horizon 3: Long-term innovation and experimentation (5% to 10%)
This model institutionalizes investment in technical excellence. Engineering health becomes a planned allocation rather than something that must be justified during every quarterly planning cycle.
When new requests arise, leaders discuss trade-offs explicitly. The conversation shifts from “Should we do this?” to “What are we willing to deprioritize to create capacity?”
Stage 3: Escalating With Data
Not every disagreement can be resolved through alignment alone. When impasses remain, escalation should follow a clearly defined path.
The first level involves the tech lead and product owner. If resolution is not achieved, the issue moves to the engineering manager and product manager. Final arbitration rests with a designated director or vice president serving as the directly responsible individual (DRI).
The key principle is that escalation is driven by data, not by re-arguing positions. Leaders review the MCDM scores, horizon allocations and supporting evidence. Their role is to evaluate trade-offs and assumptions, not to choose sides.
Every outcome should be documented in a decision log. Over time, this creates institutional memory, establishes precedents and reduces the frequency of future escalations.
What Changes When The Process Is Codified
Organizations that adopt a structured conflict resolution framework typically experience several benefits, based on my experience.
First, relationship conflict decreases because decisions emerge from a shared process rather than individual influence. Second, predictability improves as capacity allocations reduce reactive priority shifts. Third, organizational learning compounds through documented decision histories that help future leaders avoid repeating past mistakes.
Most importantly, engineering health becomes sustainable. Reliability, scalability and technical debt management are protected through governance rather than relying on individual advocacy.
Recognizing The Limitations
The D-A-E Framework is not a universal formula. The weighting model should be calibrated to reflect each organization’s risk tolerance, market position, and strategic priorities.
What matters is not the exact weighting itself but the existence of a transparent, repeatable mechanism for evaluating trade-offs.
Why This Matters Now
As organizations scale, informal negotiations become bottlenecks. High-performing organizations transform Product–Engineering tension into strategic advantage through structured, data-driven decision-making frameworks that improve alignment, preserve engineering health, strengthen trust, and enable sustainable business growth while reducing recurring prioritization conflicts.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
