In this keynote from MTP Engage Manchester, Shaun Russell explains why product people need to lean into conflict.
Key Points:
- Conflict aversion is learned behaviour
- The path of least resistance is rarely the right direction
- The stakeholder and product manager relationship should be transparent
- As product people, we must lean into conflict
Shaun describes a great product manager as “someone who can throw a well-placed, well-measured tantrum about the important things”. He describes how, as product people, it’s our role to hold the product accountable by asking difficult questions like “should we build this?”, “will it work?”, and “do our customers really need it?” Such questions will often lead to conflict – something we have to learn to embrace because “conflict is where the magic is”.
Shaun asks us to think about the last MVP we built, was it really the minimum viable product or was it a compromise? The MVP exemplifies conflict management; it’s something we build when choosing to test an idea in order to learn, even though we risk failure or unwanted cost.
The Path of Least Resistance
Shaun has found himself adopting different forms of avoidance throughout his career, developing what he calls “conflict anti-patterns”.
The first of these is mediator, where you look at the different perspectives of your users and the needs of your stakeholders and the capacity of your developers and try to find a single answer, a compromise. It’s the path of least resistance, but one which rarely provides the best solution. Shaun notes that, when compromise is the goal, the solution seems simpler so we often take on too many projects at once and not do any justice. Compromising shows stakeholders that you can’t truly manage your product. Once it’s realised that compromise is your only weapon of negotiation, stakeholders will know to fight you for scope or quality on their terms. Avoid being the mediator.
Data-driven Dismissal
The second is intellectual, a product person who uses evidence and runs AB tests to say what is true or what is not. Shaun tells how he met a stakeholder who told him, “I will be the worst customer you have ever had”. They discussed requirements and the stakeholder’s suggestions for improving the product and Shaun disagreed. He used tests to prove the stakeholder’s needs and suggested changes were not suitable. But a year later, working on a different product, Shaun looked back to find all the changes he’d dismissed had been made. Here’s what he learnt:
- Evidence doesn’t stand up for itself – you are required to produce it for stakeholders but also show the business why it’s worth acknowledging (otherwise they’ll forget).
- You have to back it continually – retesting and reassessing ideas is imperative when they keep coming back.
- You need to be open to change – it’s your job to build the best products, sometimes that means looking to be proved wrong.
Shaun saw a pattern of conflict avoidance when he accepted the statement “I will be the worst customer” at face value. He says it’s important to learn how your stakeholder perceives your relationship because we should aim to be a team, working together. Having shared goals, clear upfront communication, and being able to tackle conflicts as soon as they occur are some of the best ways to align and build better products.
Vision-based Bias
The third role is that of the deviant – a product manager with power and vision and the final say. Shaun was working on a website which showcased discounted clothes and wanted to launch a tool specifically for Black Friday. When asked to justify the decision to build this feature with a five-day timeline, unstable data sources and a lack of real evidence, Shaun thought: “I’m the product manager, I have had enough of being pushed around by the business, we are going to launch.” The resulting build was, he says, unusable, infeasible, and unviable.
Shaun says you can’t ignore stakeholders and puts forward the case for transparency. He asks: “Why can’t we just be honest about what we really want to achieve?” If we do this we can openly discuss conflicts, identify risks, and then use evidence in order to further clarify decisions made. Using tools such as the Opportunity Solution Tree, a KPI tree, or even just a whiteboard and Post-Its, we can bring structure to user and stakeholder needs before we look at solutions – and avoid getting attached to our own biases.
It’s human to find our own conflict anti-patterns, but as product people, we must lean into conflict and find the right solutions that will bring about success.
