Your designer and engineering lead have revisited the same product decision three times. Both have reasonable arguments. Each meeting ends with a temporary compromise, and the next one starts with less trust.

As the product leader, you can break the tie. But deciding too early may suppress useful disagreement without fixing what keeps producing it. Your first job is to determine whether the team is fighting about the work, the working relationship, or both. That diagnosis tells you whether to widen the discussion, run a test, repair the relationship privately, or bring in neutral help.

Name the conflict before choosing the meeting

Product-team conflict falls into two useful categories: task conflict and relationship conflict.

Task conflict is disagreement about the work: which problem matters, what the evidence means, how a solution should behave, whether a technical approach is viable, or which tradeoff best serves the outcome. This conflict can improve the decision because it exposes assumptions that would otherwise remain hidden.

Relationship conflict concerns how people work together: interruptions, dismissive feedback, unclear ownership, recurring surprises, broken commitments, or a decision process one person experiences as unfair. More customer data will not repair that pattern. The team needs a conversation about its working relationship.

What you notice	Likely conflict	First move	Common mistake
People disagree about evidence, priorities, constraints, or implementation	Task	Bring the decision and its assumptions to the product trio or relevant team	Trying to restore harmony before examining the disagreement
The recurring issue is tone, trust, communication, ownership, or decision behavior	Relationship	Start with a direct one-on-one conversation	Turning a personal repair attempt into a public team debate
A proposal is dismissed because of who presented it, while the underlying decision also remains unresolved	Mixed	Make the interaction safe enough to discuss, then return to the task evidence	Debating the proposal while ignoring the damaged working dynamic

Do not diagnose motives. Diagnose the observable unit of conflict. Ask:

• What exactly must be decided?
• What does each person believe, and what evidence would change that belief?
• If someone else made the same argument, would the disagreement remain?
• Is the objection about the proposed decision, or about how the proposal was raised and handled?
• Has the team resolved this issue before, only to have the same friction return?

Treat your classification as a working hypothesis, not a verdict. Saying, "This sounds like a task disagreement with a relationship layer" gives people something to correct. Saying, "You two have a personality problem" assigns blame before facilitation has begun.

Do not confuse silence with alignment. A team with no visible task conflict may simply lack the psychological safety to challenge an influential designer, engineer, or product leader. If decisions receive instant agreement in meetings but resistance during execution, look for disagreement that has gone underground.

Turn task conflict into a decision the team can test

Task conflict belongs in the team, not in a prolonged private contest between two people. Other members may share one side’s concern, hold evidence neither party has considered, or reveal that everyone is using the same word for different things. Widening the discussion also makes the disagreement less personal.

Replace positions with claims

"We need guided onboarding" and "A checklist is enough" are positions. They invite advocacy. A claim is more useful: "New users abandon setup because they cannot tell which action to take next." The claim identifies an assumption that customer evidence or a product test might challenge.

Use this sequence to move the discussion:

1. Write the decision in one sentence. If the team cannot name the decision, it is probably arguing about several questions at once.
2. State the shared outcome and constraints. Name what the team is trying to improve and which technical, commercial, operational, or timing boundaries are real.
3. Translate each position into assumptions. Ask what must be true for each proposed path to work.
4. Separate evidence from interpretation. Put observed customer behavior, technical facts, and existing results apart from predictions or preferences.
5. Ask what would change each person’s mind. If the honest answer is "nothing," the discussion is no longer an evidence dispute.
6. Choose the smallest credible test. Agree in advance on how the result will inform the decision.

The test does not have to be an A/B test. Depending on the uncertainty, it might be a prototype session, a technical spike, instrumentation of the existing journey, a targeted customer interview, or a deliberately limited release. Test the assumption creating the disagreement rather than building both complete solutions.

When the debate remains opinion against opinion, designing an experiment is usually more productive than escalating the strength of the argument. Agree on the decision rule before results arrive. Otherwise, each side can reinterpret ambiguous evidence in favor of its original position.

Know when an experiment cannot decide

Not every task conflict should become an experiment. A test cannot decide what the company’s strategy should value, make an ethical choice, or eliminate a constraint that leadership has already set. Some decisions also cost more to test than to reverse.

In those cases, identify the accountable decision owner, let the relevant people make their best evidence-backed case, and make the choice explicit. Record the assumptions behind it and the conditions that would justify reopening it. The goal is not unanimous agreement. It is a decision people understand well enough to execute without quietly relitigating it.

Repair relationship conflict before rewriting the roadmap

Relationship conflict should usually start in a one-on-one conversation. A larger forum can turn repair into performance: each person defends a public version of events, while observers feel pressure to choose a side.

Open with an observable event, its effect, genuine curiosity, and a specific request. For example: "When the review moved to a decision while I was still presenting the customer evidence, I stopped contributing. What was happening from your perspective? In the next review, can we separate clarification from the final decision?"

That construction matters. It avoids claims such as "You never respect design" or "You always block engineering," which ask the other person to defend their character. A concrete event can be examined. A motive you assigned to someone cannot.

Use the conversation to reach a working agreement:

• Describe the behavior without exaggerating its frequency.
• Explain the impact on the work or your ability to contribute.
• Ask what the other person saw, intended, or needed in that moment.
• Restate their perspective accurately enough that they recognize it.
• Agree on an observable behavior to try when the situation recurs.
• Decide how either person will flag the pattern without restarting the entire argument.

Direct repair is not the right opening when there is harassment, discrimination, retaliation, a threat, or a power imbalance that makes the conversation unsafe. Use the appropriate manager, people leader, HR, or formal reporting route instead. For an ordinary working disagreement, however, HR or mediation is an escalation path rather than the default first move.

Fix the norm, not only the incident

A team charter prevents the repaired conflict from reappearing under a different decision. The useful version goes beyond mission and outcomes. It makes implicit operating expectations explicit, including working hours, communication preferences, and decision-making preferences.

Your charter should answer practical questions:

• When is each person normally available, and which boundaries should the team respect?
• Which channel is used for discussion, decisions, urgent issues, and durable documentation?
• How does the team make a decision when discovery, design, engineering, and business constraints point in different directions?
• Who owns the final call for different decision types?
• How does each person prefer to receive difficult feedback?
• What information must accompany a request to reopen a decision?
• How will someone signal that a disagreement is becoming personal or unproductive?

Make each agreement observable. "Communicate respectfully" is an aspiration. "Critique the proposal before proposing an alternative, do not interrupt an evidence review, and have the decision owner restate the unresolved concern" describes behavior the team can notice and correct.

Protect the retrospective as the place where these norms are inspected. A retrospective is not only a delivery ceremony. It is a pause to ask how the team is working together. When the conversation stays vague, focus it on one tension: how decisions were made, how feedback moved, how ownership changed, or where information arrived too late. A Team Radar retrospective can help surface different views of that specific tension without forcing the team to begin with accusations.

Facilitate the room without quietly becoming the judge

Choose the facilitator for the conflict you have

A facilitator needs enough context to understand the decision, but not so much investment that they are already defending an outcome. An embedded coach may understand the history yet be seen as aligned with one side. A product leader or senior engineer may have credibility but also carry decision authority. Choose deliberately; familiarity is not the same as neutrality.

Look for someone who can:

• interrupt senior and junior participants consistently;
• summarize each position without making it sound weaker;
• distinguish facts, assumptions, interpretations, and requests;
• notice when a task disagreement has shifted into a relationship attack;
• remain outside the content unless a role change is stated clearly; and
• end with an owner, a next action, and a condition for revisiting the decision.

If you must facilitate and contribute, mark the transition explicitly. You can say, "I am facilitating while I summarize the disagreement. I will announce when I switch into decision-owner mode." A visible role signal, such as changing seats or moving to a different place in the room, can make that boundary clearer. Do not claim neutrality while using the facilitator’s position to advance your own proposal.

Give the conversation a decision-shaped agenda

A conflict session should not be an invitation to replay every grievance. Use a sequence that turns the tension into a bounded piece of work:

1. State the purpose. Name the decision or working pattern the group must address.
2. Set participation rules. Clarify how interruptions, corrections, and role changes will be handled.
3. Hear each account. Ask each person to distinguish what happened, what they inferred, what impact they saw, and what they need next.
4. Capture a neutral summary. Use concise labels that both sides recognize. The facilitator should not add a hidden third argument.
5. Classify the unresolved parts. Mark each as task, relationship, or mixed.
6. Assign the matching next move. That may be an experiment, a direct repair agreement, a decision by the accountable owner, or outside mediation.
7. Close the loop. Record who will act, what will be observed, and what would cause the team to reconvene.

Before moving forward, ask each person whether the written summary represents their position. They do not have to agree with the other side. They do need to recognize their own case in the record. If one person’s view survives only as a caricature, the meeting has not yet produced a usable decision.

Escalate one shared description, not two competing stories

If the team cannot resolve the conflict, ask the parties to write the escalation together. Joint escalation can make the disagreement smaller and more concrete before it reaches a leader.

The shared note should contain:

• the decision or working conflict in one sentence;
• what both parties agree on;
• the exact point of disagreement;
• the evidence and assumptions behind each position;
• what the team has already tried;
• the consequence of leaving the issue unresolved; and
• the specific decision, mediation, or support requested.

Route the escalation according to its type. A task conflict goes to the person accountable for the product, technical, or organizational decision. A relationship conflict goes to a manager, neutral mediator, people leader, or HR as its seriousness requires. A joint note does not replace a protected reporting route for unsafe conduct.

Key takeaways

• Classify the conflict before choosing an intervention: task, relationship, or mixed.
• Treat task disagreement as useful information. Bring it to the relevant team, expose assumptions, and move from positions to testable claims.
• When credible opinions remain evenly matched, design the smallest experiment that could change the decision.
• Start ordinary relationship repair one-on-one, then convert the resolution into an observable team agreement.
• If you facilitate and hold decision authority, announce when you change roles. Do not use procedural control as hidden decision power.
• When escalation is necessary, have both parties coauthor the problem, remaining disagreement, prior attempts, and requested decision.

The next time the same argument returns, resist the urge to cast the deciding vote immediately. Put one question in front of the team: "Are we stuck on the work, or on the way we are working?" The answer should determine the next conversation. Resolving the right conflict is more valuable than ending the current meeting quickly.

References

• Product Talk — Facilitation Skills – All Things Product Podcast with Teresa Torres & Petra Wille

---