Two stakeholders give you directly contradictory requirements. How do you resolve it?

Most contradictions are not real

The first move is diagnostic rather than diplomatic. A stated requirement is usually a solution somebody has already chosen, and two people proposing different solutions to the same underlying need will appear to contradict each other while actually agreeing.

So trace each requirement upward. For each one, ask what business outcome it serves, what happens if it is not met, and who is affected. Operations asking for a mandatory approval step and Sales asking for one-click submission look irreconcilable at the level of the screen. At the level of intent — Operations wants to prevent bad data reaching fulfilment, Sales wants to reduce time-to-submit — they are compatible, and asynchronous validation with an exception queue satisfies both. That solution is invisible until you go up a level.

This is the technique the question is testing. Candidates who immediately start negotiating between the two stated positions have accepted a false constraint.

Get them in the same room

Shuttling between stakeholders is the most common mistake and it fails in a specific way: you become the medium through which the disagreement is conducted, each party hears their position relayed rather than heard, and you end up owning a conflict that is not yours.

Bring both together with the tension stated as a shared problem: "Both requirements are reasonable, they cannot both be satisfied as written, and I need your help choosing." Come with the analysis prepared — the two objectives, the specific point of conflict, the options with their trade-offs, and what each option costs. A facilitated session with prepared options resolves in twenty minutes what weeks of email cannot.

Bring evidence rather than opinion where you have it. Data on how often the disputed path is actually used, or what the current process costs in rework, moves a room in a way that argument does not.

When the conflict is real

Some conflicts are genuine, mutually exclusive trade-offs — strict data validation versus submission speed, for instance, where you can shift the balance but not eliminate the tension. When that is the case, the important recognition is that this is a decision, not a compromise to be invented, and it belongs to someone with the authority to make it.

Your job is to make the decision easy to make well: state the options, the consequence of each, your recommendation with reasoning, and what you need decided and by when. Then take it to the person who owns the outcome — the product owner, the sponsor, or the steering group, depending on how the project is governed.

Two failure modes to avoid here. Do not split the difference to keep the peace, because a compromise nobody asked for typically satisfies neither objective and you will own the result. And do not quietly implement the preference of whoever is more senior or more persistent, because that produces a requirement with no recorded rationale that gets challenged in UAT.

Document it as a decision

Whatever the outcome, record it where it will be found: the conflict, the options considered, the decision, the reasoning, who decided, and the date. This is the step that gets skipped, and skipping it is why the same argument recurs three months later with different people and no memory of why the current design exists.

Link it to the affected requirements in your traceability matrix so anyone reading the requirement can see the decision behind it. If your organisation uses architecture decision records, the same format works for requirements decisions and is worth borrowing.

Preventing recurrence

A recurring contradiction between the same two stakeholders is usually a governance gap rather than a personality problem. The structural fixes are a single named decision-maker for the product area, an agreed prioritisation basis so trade-offs are resolved by a shared rule rather than by whoever escalates hardest, and a stakeholder map maintained early so you know who must be consulted before a requirement is treated as settled — much of this conflict comes from someone being brought in late and reasonably objecting to a decision they were not part of.