Product Managers, here's how to change someone's mind
Approaching disagreement with an open mind
Disagreement is part of the job of product managers. You’ve got to build some thing. That means not building other things. Unfortunately, a bunch of folks want those other things.
You can tell those folks, tough luck. But the job is easier, especially in larger scale-ups and big companies, if you bring them along.
So - how do you deal with disagreement?
As the first port of call, I ask my teams to start with the three Es:
Empathy: Understand the other person’s point of view
Evidence: Bring the data and evidence to give direction
Experiment: Experiment your way to a solution (and out of conflict) acknowledging you may be wrong but the quantitative and qualitative evidence will send the team in the right direction.
Of the three, getting empathy right is key to ensuring you can move fast with open minded partners across your business. Get it wrong and, particularly when your data is sparse, you’ll see your teams get caught in a doom loop of roadmap justification.
To make sure teams and their partners can tackle problems with an open mind, I suggest three tactics to my product managers (based on a framework developed by former colleagues at the UK’s Behavioural Insights Team):
Ensure a shared sense of purpose
Affirm values and expertise
Map the detail (with an open mind)
1. Ensure a shared sense of purpose
A shared identity can unify team members, transforming disagreement into constructive discussion.
A study conducted by Mark Levine and co-authors found that Manchester United fans were more likely to help other Manchester United fans facing a small injury than fans from Liverpool or an unidentified team. This effect disappeared when participants were prompted to think of themselves as fans of football, rather than just fans of one team. Similarly, Rebecca Bigler shows that dividing children into groups based on the color of their t-shirts produces stronger group cohesion. A shirt with the same color is enough to create shared identity!
In Tech: Spotify's 'squad' framework is an example of shared identity. Cross-functional teams are organized around shared missions, fostering a sense of unity even amidst internal disagreements.
In my own work, I’ve witnessed cross-disciplinary teams working effectively when banded under a shared domain or mission. It is how every squad I’ve worked in tech manage conflict between product, design, and engineering - having clear goals and metrics owned as a whole by the team.
At my current company, whilst each of our squads is known by the problem space they own we also give them animal names. Most new joiners are skeptical about why they are joining the ‘Audacious Octopi’ but it serves an important purpose to create a shared identity even when priorities change.
For your practice: Develop symbols and rituals that reinforce a sense of shared team identity, such as team logos, mission statements, or team-building exercises. When a disagreement or a conversation appears to be going off the rails, take a step back and remind people of your shared direction and mission.
2. Affirm values
Validating different perspectives is a powerful tool to mitigate conflicts. Studies show affirming the values of others make them more open to ideas and new behaviours.
In an argument, the easiest approach is to dismiss the other’s perspective or approach. Instead, the evidence shows you should lean into understanding their perspective and affirming it. Voice what you hear from the other side and, as is often the case, the legitimate arguments within their point of view.
In Tech: The idea of ‘Disagree and Commit’ is part of Silicon Valley’s founding companies - with the phrase attributed to Andy Grove at Intel. More lately, “Have Backbone; Disagree and Commit” is one of Amazon’s core leadership principles. The idea welcomes disagreement whilst acknowledging other perspectives exist (and can be disagreed with!).
For your practice: Be careful not to dismiss expertise and alternative views. Instead, openly engage with and affirm them. You may change your mind or perspective as a result - and you’ll make it easier to change other people’s minds as well.
3. Dive into the details with an open mind
Leonid Rozenblit and Frank Keil's research introduced the "illusion of explanatory depth." This showed people often overestimate their understanding of complex topics until they are asked to explain them. Once people try to explain a firmly held view, they uncover gaps in their knowledge. This leads to awareness of their own limitations and the potential value of other people’s ideas.
In Tech: In retrospectives following a serious coding error, it is standard to start with a detailed timeline of what happened. This serves the obvious purpose of establishing exactly what occurred. However, it also ensures everyone is open to gaps in their own knowledge before the team considers potential solutions.
"Code reading clubs" are forums where engineers explain sections of the code to each other, encouraging each person to understand the limits of their understanding.
For your practice: When facing a disagreement about an approach or process, you can suggest writing down your understanding and comparing that with the other person. Avoid disagreements where it is simply two teams or people speaking at each other. Roll-up your sleeves and map out the logic of your argument or process with the other person. You’ll be surprised at the gaps in your own approach - but so will the other person as well.
The hardest task in the world is to change someone’s mind. To get there, start with empathy. If you’re struggling to make progress, remind people of your shared mission, affirm their perspective, and dive into the detail. You may be surprised how quickly this opens up your solution space.
Let me know how you go.