In my previous post sharing results from our collaboration survey, I said that if we want to make progress in our content projects, we need to stop arguing and open up to understanding the reasons behind our stakeholders’ positions.
In this post I’ll show you how to do that with three examples.
Let’s recap the problem. The evidence we present to stakeholders—analytics, lab research, neuroscience—doesn’t have the effect we intend. We assume that our stakeholders are operating from the same reality as us. They aren’t. That’s why our evidence doesn’t convince them that our recommendations will work. Now the question becomes, how can we create a shared reality between us and our stakeholders?
Collaboration techniques create a shared reality
We can use collaboration techniques to create a shared reality with our stakeholders, by:
- building a shared understanding of all the requirements around a content problem
- inventing an approach that meets all of of those requirements
The trick is to reframe a difference in opinion as an opportunity to discover requirements. When stakeholders resist your recommendations you can integrate their perspective through dialogue. Here are three examples.
1. Ask why stakeholders want to use legalese or jargon
Imagine you’re advocating for plain language on a website and a stakeholder prefers to use legal language. Normally we’d see this as a conflict, an either-or. Instead you can find a third way by integrating the stakeholder’s perspective. First identify the constraints around the content problem by asking what requirements are driving each of our positions. Starting with yourself: you want to use plain language so that users can understand the content. Then ask the stakeholder why they want to use legal language. They might say, “so that users can comply with relevant rules”. Keep going until you have all the requirements written down, like this.
Our content needs to:
- allow users to understand what we mean
- allow users to comply with relevant rules
Once you have all the requirements written down, you can invent a third way. Work with your stakeholders to suggest approaches that can meet all of the requirements.
2. Find out why stakeholders believe their opinions or anecdotes are relevant
When we present data to stakeholders and they respond by sharing opinions or anecdotes, it can seem like they’re trying to reject our perspective or undermine us. However, they probably aren’t doing this deliberately—it’s more likely that they’re trying to reconcile their reality with the evidence we’re offering. The trick here is to understand why the stakeholder believes that their opinion or anecdote is relevant.
For example, imagine that you show usability testing videos where users struggle to understand part of a website. The stakeholder responds by telling you that they believe that the website is intuitive, and that they know many users of the site who have no problem with it.
Ask yourself what this story means to your stakeholder. Why are they choosing to share it with you now? Ask them what they think is working for the users that they know, and how they interpret the testing video. They might say something like, “you asked the wrong users.” The key is to request more understanding. “I’d like to understand how the experience of this website is different for the users you’ve talked to, because the people I’ve seen using it found it difficult to understand.”
You will find something out about the reality of your stakeholder. Perhaps they have a different perspective on who the site is for, or what it can offer to users. Or maybe they’re sharing anecdotes because they want their years of experience to be considered.
3. When stakeholders play politics or disregard your expertise, discover what’s driving their behaviour
When we talk about stakeholders “playing politics”, we usually mean that they choose to ignore our recommendations. For example, we might present evidence that shows users don’t understand the guidance around a service. Despite this, the product manager chooses to keep the existing content. Sometimes we might characterise this as, “not seeing us as experts in our field,” or we might joke that, “everybody thinks they’re a writer.” All of these responses are defence mechanisms. We respond in this way out of frustration that we haven’t contributed effectively.
Our stakeholders see things differently. They don’t come into work resolving to disregard our expertise, and they don’t walk up to our desks and tell us that they’re better writers than us. They’re thinking about how our recommendations relate to their worldview. And they’re noticing that they don’t share our perspective.
This opens up an opportunity to build your understanding about stakeholders’ perspectives. Try asking them why they don’t want to change the content. What didn’t resonate, what’s missing? What’s the reasoning behind their decision? When someone sends you a polished draft and resists your edits, ask them why. What are they hoping to achieve with the wording they’ve chosen, and what problems did they see with the changes you made? Would they be willing to explain their thought process?
Once you begin to integrate everyone’s perspective, you’ll notice that concepts like “playing politics” fade away, and the question of respecting expertise becomes less of an issue.
There’s one thing we need to fix before these techniques will work. We need to go into interactions with stakeholders believing that we can find a way to work together. How often have you said, “I’d like to hear your feedback,” when what you really mean is, “I’ve written this and I want you to agree to my solution”? Don’t do this. People can tell when you’re taking a position, even when you dress it up in the language of requests.
The way out of this trap is to acknowledge difference. Tell your stakeholders that you believe it’s possible to find an approach that satisfies everyone’s requirements, even though there are differences of perspective. If you show that you believe collaboration is possible, your stakeholders will be willing to try it.
Collaboration takes work. It’s worth it, though, because it ends with everyone’s requirements being satisfied.