What can I do when reviewers give conflicting feedback on a deliverable?
Quick answer
Don’t combine incompatible instructions or guess whose preference wins. Put each comment beside the relevant deliverable element, label it as a stated requirement, preference, or unclear point, and note the conflict and its impact. Then ask the person with authority to decide which direction to follow. While you wait, continue work that does not depend on the decision and make any assumptions explicit.
The question, the details, the next step.
Two reviewers gave me feedback that seems to point in opposite directions. What should I do first, and how do I tell a requirement from a preference?
Capture each comment in the reviewer’s own words, the part of the deliverable it concerns, and any relevant constraint or audience need. Then compare the underlying requests: comments may only seem incompatible if they address different sections or goals.
A requirement is tied to an agreed constraint or specific need—for example, a required format or a stated audience. A preference is more often a proposed improvement, such as a tone or layout choice, without an explicit constraint attached. If you can’t tell, mark it “unclear” rather than deciding for the reviewer.
For example, if a project brief explicitly requires a one-page summary, that is a stated constraint. Requests for more background and a shorter opening may be preferences about how to use the space. If the added background makes the page limit difficult, flag the conflict and ask what should take priority. Don’t silently merge incompatible instructions; that can miss both reviewers’ aims and puts you in the position of choosing without authority.
Could you show me a neutral comparison format I can send?
Use one row per comment, keeping the description factual. You can copy this into a message or document:
Deliverable element: [section or item] Reviewer comment: [quote or close paraphrase] Type: [stated requirement / preference / unclear] Conflict or impact: [what it conflicts with, if anything] Decision needed: [specific choice to resolve]
Repeat those fields for each comment. For example:
Deliverable element: Opening Reviewer comment: “Put the recommendation first.” Type: Preference or unclear Conflict or impact: May leave less room for context. Decision needed: Should the recommendation lead, with context shortened?
Deliverable element: Opening Reviewer comment: “Explain the background before the recommendation.” Type: Preference or unclear Conflict or impact: Competes with the first request for opening space. Decision needed: Which order should I use?
If there is an explicit rule about the opening, include it as a separate entry and identify where it came from. Don’t label a suggestion a requirement just because it came from a senior reviewer.
Who should I ask to decide, and how do I keep the message from sounding like blame?
Ask whoever owns the deliverable or has been assigned to resolve review decisions. If that isn’t clear, ask your manager or project lead who should make the call; don’t assume the most forceful or most recent comment takes precedence.
Keep the message focused on the work and the decision needed. For example:
“Hi [name], I’m incorporating the comments on [deliverable]. I see two different directions for [section]: [reviewer/comment A] suggests [direction A], while [reviewer/comment B] suggests [direction B]. Doing both may [brief, neutral consequence]. Could you confirm which direction to prioritize, or whether there’s a specific requirement I should use to guide the choice? I’ll continue with [independent work] while I wait. Thanks.”
Include only the names or roles needed to identify the comments. Avoid judging either suggestion in the clarification request.
What can I work on while I wait, and what if the answer comes late?
Continue edits that don’t depend on the disputed choice, such as applying feedback both reviewers agree on or checking consistency in an unaffected section. Keep a note of what remains unresolved. Avoid making a version that assumes one direction unless you clearly label it as a draft assumption.
If timing matters, state the decision deadline and consequence plainly: “To keep [next step] on schedule, could you advise by [date/time]? If I don’t hear back by then, I’ll hold [affected section] and continue the rest.” Propose a default only if you’re allowed to do so; otherwise, ask who can authorize one. If no one responds, follow any agreed escalation or deadline process. Don’t treat silence as approval unless that is an established rule.
A practical checklist
Record each comment and the deliverable element it concerns.
Label comments as stated requirements, preferences, or unclear; note the basis for any requirement.
Describe the conflict or impact without judging the reviewers.
Ask the designated decision-maker one specific question about which direction to prioritize.
Continue independent work and state any deadline or assumption clearly.
A few more useful answers
Should I copy both reviewers on the clarification message?
Include the relevant people when that fits the team’s normal review process and helps them see the same decision. If you’re unsure who should be involved, ask the project lead rather than escalating broadly by default.
What if the reviewers disagree about a requirement?
Show the exact requirement or brief wording alongside both comments, then ask the person accountable for the deliverable to interpret it. If the requirement itself is ambiguous, identify the ambiguity instead of presenting either reviewer’s interpretation as settled.
What if no one replies before the deadline?
Follow the agreed escalation or deadline process if one exists. Otherwise, tell the project lead what remains unresolved and what work you can complete; don’t imply that a missing reply authorizes a choice unless that is an established rule.