How I’ve Learnt to Handle Disagreements
First, seek to understand before being understood. This is an area I need to improve in, too: I should listen to what the other person is saying, without looking for an opportunity to get my point in. Or to use what he’s saying as a jumping-off point to making my own point. Which superficially sounds like building on the other person’s point, but is actually not, so it’s in a way dishonest. When listening, you can ask clarifying questions to understand, or to probe areas he may not have thought about to figure out if he has a view there, but not disagree. An analogy is a journalist asking questions to draw out the subject, but not to make it about himself.
People argue not because they insist on having their way, as much as because they feel that their point of view hasn’t been first considered, second understood and third appreciated. So, listening to the other side with full attention and respect often defuses the disagreement by itself.
Second, acknowledge the benefits of someone’s proposal even if don’t intend to adopt it. When someone comes up with an idea, they often express it in a flawed form, so instead of taking it literally, try to look behind the proposal to what the person is trying to get at. There must be some reason why he’s proposing that, so try to understand that.
Third, when arguing, stop, summarise both points of view, and ask if you got it right. For example, “I think we should launch this feature, but you think we should improve the UX further before launching. Did I understand you correctly?”
An argument often starts somewhere but then takes on a life of its own, unmoored from the issue it was supposed to resolve. Or people respond to imagined attacks on what’s important to them, such as a designer feeling that engineers dismiss the importance of UX. People also form opinions from prior encounters with someone else, and respond to that, instead of to the issue at hand. For all these reasons, arguments may start with an issue to resolve, but then take on a life of their own, so you need to bring them back to the issue at hand by summarising both sides’ points of view.
Doing so often defuses the argument because both sides realise that there’s actually no disagreement. In the previous example, the other side may clarify, “No, we should launch, but we should improve the UX eventually, not leave it as it is.” Since both of you agree that the next step is to launch, you can stop arguing and get back to work. Even if stating both sides’ positions doesn’t end the argument, it refocuses the discussion constructively towards resolving that.
Fourth, when arguing, make sure you’re in agreement regarding what aspect you’re disagreeing on.
a) Disagreements often happen because both sides have different goals in mind. For example, Futurecam was intended to be a camera app for photography enthusiasts who want the best photo quality, but people sometimes proposed features that would Futurecam easier to use for a broader audience but with noticeably worse photo quality for the target audience. This is an example of being misaligned with the goals.
b) Once a goal is agreed upon, disagreements can still happen about the high-level plan to get to the goal. For example, in the initial days of Futurecam, the plan was to launch the four major features as quickly as possible with a low quality, and only then improve UX, add onboarding, fix occasional bugs, handle edge cases, and so on. This was the high-level plan. Now, when we were working towards launching the second of four features, the designer insisted that it have a much higher level of quality than our plan called for. This contradicts the big picture plan the team was working by.
c) Our designer wanted a video editor to be built into our camera app Futurecam, but that would take multiple person-quarters, which we didn’t have.
People can argue for things without understanding the goals, high-level plan, or constraints. When this happens, stop the argument, take a step back, explicitly articulate the goals/high-level plan/constraints, and ask if the other side agrees. If not, resolve that disagreement first before going back to the original disagreement. Otherwise, any attempt at discussing will be counterproductive.
d) If we’re doing something that has three parts, and there’s a disagreement, confirm which of you the three you (dis)agree on.
When you implement this suggestion, you may find that people are sometimes unclear about what they disagree with. In that case, ask them to think through it, and then resume the conversation later. Never continue arguing with someone who’s unclear about what he’s arguing for — it will only waste time and generate negative emotion, eventually chipping away at the relationship.
Fifth is understanding prioritisation, that “no” can mean “not now”. In the above example, when I said no to the designer, he felt bad thinking that I didn’t value UX. But I meant only that we won’t be focusing on UX at this stage. So it’s good for both sides to stop and check what’s actually being said.
Sixth, disagreements sometimes happen because one side doesn’t understand launching and iterating. This is related to launching and iterating. People sometimes look at it as a one-time event, so they argue and try to get what they want in. When that happens, remind them of the philosophy of launching and iterating, that we should push ourselves to launch things before they’re ready.
Seventh, disagreements can be about quality, about the bar we should have to launch something. Someone often claims that the product “needs” something or that something “is table stakes”. For example, a friend said that in a camera app, it’s mandatory to have a thumbnail that you can tap to view the photo you just took. And it did seem like a must-have. So we spent multiple person-months implementing it. But I’ve found our most successful competitor to not have this supposedly manatory feature, and it had good reviews, and was very usable. We eventually removed it, and no one complained.
So, it’s easy to say that the quality should be higher, but there’s a huge opportunity cost, time that could have been spent on things I actually cared about as opposed to implemented out of a sense of obligation. So, the next time there’s a disagreement about where the bar should be, err on the side of lower rather than higher. If you’re wrong, users will let you know, or it will stick out like a sore thumb as you and the rest of the team use the product day-to-day as users. By contrast, if you set the bar too high, you’ve wasted time, multiple months, and you won’t get it back.
Eighth is preconceived notions: we sometimes form opinions about others from prior disagreements. For example, I may have thought that my designer is an idealist and can’t build products. And he may have thought that I don’t know or understand how to build a high-quality product; all I care about is shoving out stuff. We’re human, and we can’t help form such opinions, fair or unfair. When this happens, put this on the table in a non-accusatory manner like, “I have a feeling about you that you are an idealist, that you take forever to launch. I’m not blaming you, I’m just being transparent about how I feel, right or wrong, and putting it on the table so that we can work together to make a better decision.”
Ninth is clear roles. For example, it’s the product manager’s job to define the business value of each task. This is better than everyone thinking they’re responsible for product, which leads to arguments. And someone can disagree with the PM, but they still need to commit to what she’s decided.
Tenth, distinguish between discussions and arguments. A discussion is where new information is being added to the conversation. This can be objective, like “Option X is 30% faster than option Y.” Or anecdotal, like “My friend’s startup tried that, and it didn’t work.” Or adding a perspective that wasn’t considered, like “Option Y respects users’ privacy more than X.” All these are good. What’s not good is an argument, where people are insisting on the same thing again and again, or ignoring what another person just said. Stop and ask yourself, “Am I having a discussion or an argument?” If it’s an argument, stop it. Don’t get carried away.
[1] Typically people whose job it is to ask for things but not necessarily be held accountable for their delivery: designers, sales, marketing. This isn’t a criticism — it arises from the way different roles are structured.
