Not only “what” but also “how”

Over the past few months in our company, along with other members of the leadership team, we have tried and are trying to improve, change, and update a lot. In general, striving for the better is a normal, permanent process, but now we are in a period of active shake-up. In the product team, among other things, we decided to improve interaction with adjacent departments and involve them in prioritization and planning. Within our direction, we use the ICE framework — super simple and understandable. It works well, so we didn’t change it but simply expanded the composition of the participants in the prioritization sessions by inviting the CS team as the voice of our customers.
Nothing worked. The involvement at the meeting was about zero, faces were bored, and the atmosphere was sleepy. After the call, I received feedback from the head of the CS team that it was all nonsense and didn’t work. Thinking they were just lazy, unwilling to do anything and adopt good product approaches, I went on to think further. Meanwhile, these same colleagues continued to complain about the lack of transparency and their voices not being heard. As you understand, this all led to misunderstandings, disagreements, and mutual dissatisfaction. Later, I abandoned the practice of joint prioritization by ICE and simply began to gather the leads together in an attempt to tell them what we were planning on the roadmap. And again, it was sad — we constantly deviated from the subject, nobody wanted to understand the essence, and the involvement was extremely low.

I really didn’t understand what to do with it. Often blamed and got angry at the leadership team. But after some time, when I started working on the product strategy and vision and encountered a similar story, I finally got the insights that helped me understand what was wrong.

Special thanks to the co-founder (who is also the CTO) and CRO, who pushed me towards these insights and helped me rethink the approach.

Both in the case of prioritization and in the case of presenting product plans and strategy, I saw a clear picture: how this framework works and what decision-making is based on, how it can improve our product, what problems it will solve for our customers. But from the executive team’s side, I encountered resistance and misunderstanding. **And it was not because the idea was bad. The problem was with me. I couldn’t convey my thoughts correctly.

More precisely, I couldn’t convey the thought in a way that was understandable to the audience and met their goals.**
Here are the insights I was able to realize:

***1. Often, the failure of some initiative happens not because you try to sell/communicate to other people, but because of how you do it.

2. Do not flatter yourself with confidence in your correctness and the wonderful and modern approaches you offer. It doesn’t matter. What matters is whether they meet the needs of your counterparts.

3. The needs of your counterparts are important not because they are more important than yours, but precisely because only by hitting them, you can achieve your own goals.***

“You’re telling me,” you’ll say, and you’ll be right. It really doesn’t sound like revelations. I seemed to understand this before. However, in a crystallized and executable format, it seems I was only able to formulate this now, and it is a powerful tool.
So, what to do with all this? Here are a few tips on how to make your communication work and your initiatives resonate with colleagues:

• Know your audience.

Talking with developers is different from a dialogue with executives. They have different goals and interests. They possess different toolsets. And most importantly, they use different optics to study the same things. Start adapting your story so that it resonates with their unique needs and goals. If you don’t know them — learn them. Don’t try to scale everything in the same key to the whole company. This can be a breath of fresh air in your discussions.

• Tell stories, not just share facts.

The importance of storytelling is not new, just don’t forget about it. People love stories. We all grew up on fairy tales, and our brain loves to absorb information through narrative. Imagine the ultimate goal of what you’re trying to communicate, and then come up with a simple and structured story on how to get there.

• Simplify and adapt.

Prioritization was another stumbling block. As the experience with changing the prioritization process showed, no matter how good and advanced the approach you advocate is, it will not work if it is not understood or if it takes too much resources. You can easily face that your approaches are too complex and take a lot of time. And no matter that you consider them understandable and simple. Go back to the first point and match, do they meet the needs of your audience? In the end, it’s not only the audience’s task to understand something, but also yours to make it applicable. Simplify, make approaches more succinct and transparent, convey the thought in broader strokes, adapt to the expected outcome. Does your CS team need information about the ICE score of your features? Do they even need to understand how this method works? Do they need details for each task (even though they affect the overall prioritization)? Or do they need a simple top-level picture of what you will be doing and why?

• Listen to hear.

Last but not least: be open to feedback and learn to listen to hear. Many people listen only to respond, to defend their position. Try to listen to understand and to learn.