The one skill a product lead should focus on first

Photo by Volodymyr Hryshchenko on Unsplash

As promised in my first article. I would like to cover many topics to share experiences I’ve been through with my team as a product leader.

Today I want to focus on one of the most relevant topics you have to take care of from the very first day. At least this is what I learned from my years in product development. Of course, learned by not focusing on it from day one. But this is how it goes, right? Learn from your failures and grow.

The topic I’m talking about is communication. A product lead has to master communication himself. But also has to teach his team how to do good communication. And don’t get me wrong. I don’t consider myself a good communicator. It is still something I want to improve and to help others to improve. This writing is one of those activities to help me with this goal.

But why is this so relevant? Let’s think about the two core responsibilities of a product lead.

First, he has to build high performing, empowered, product teams. From recruiting on one hand and developing and growing skills on the other. There is this quote I read this week in the new book “Strong” by Petra Wille. It’s from former General Electric CEO Jack Welch:

“Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others.”

The second responsibility is to provide context to everyone. We have to make them understand the business and the respective objectives. Usually by building a product strategy. This translates into a roadmap that guides the team to reach those objectives.

Of course, there is much more to do. Several different tactics and practices but for now, let’s only focus on these two.

What has all this to do with communication you ask? If communication and the common understanding are broken there is a high chance you will fail on those responsibilities. At least you will have a much harder time reaching your goals when you don’t try to fix them. But how?

Let’s start with an example. A few days ago I observed a session from one of our product teams. Their aim was to health check their team’s performance and to improve their way of working. They have been through a lot of changes lately. Also new team members joined the cross-functional team. It was time to realign how they wanted to work together as a team.

To make sure we talk about the same thing when we say product-team. In our company they are cross-functional. A product manager, product designers, a tech lead, and many engineers working collaboratively. The teams are supported by business intelligence and data engineers. The goal is to enable them to do data-driven decisions. More on the topic of building an effective product team will follow in another article. Soon.

Back to the example. To kick off their session every team member had to prepare a user manual. The aim was to introduce themselves and to let the other team members know how to “use” them. A cool approach and one of those moments I’m super proud of our teams. One question they had to answer was the following:

“What is the best way to communicate with you?”

Most of them answered “Slack”. While I observed the session I asked myself how helpful this information was. Would it change anything if they would say Microsoft Teams or Skype? I would doubt this.

“Communication is the imparting or exchanging of information by speaking, writing, or using some other medium.” — Google Search

To build self-improving product-teams, you should always hunt for those findings. What are people talking about? Do they talk or do they communicate to reach a specific outcome?

Why do I talk about this observation? Well, it took me a while to realise that one of the most important things you have to get right in a team is communication. If you read the origin of agile as we know it, the agile manifesto, it is part of the first principle.

“Individuals and interactions over processes and tools”

I saw teams implementing ticket systems, following scrum or kanban. Teams not using scrum or kanban. Teams doing daily, weekly or monthly plannings. Teams building roadmaps, sitting together in intensive planning sessions, and many more. You know what I’m talking about. But it doesn’t matter which process we used. When I was talking with people in our weekly one on one sessions…

Yes, I do weekly one on ones. More about this and why they are the killer feature to lead teams in one of the following articles.

… I realized that members of the same team tend to use the same words by meaning completely different things. This can cause in an environment of high uncertainty, a typical habitat of a startup, a lot of problems.

Product leads and managers by nature know that listening and asking is bread and butter for the job. How important it also is for all other members of a product team and the company around we sometimes miss.

But why is communication such a thing? Well, humans have a powerful and flexible language. To get the most out of it we have to overcome our innate biases, which work against collaboration and connection.

Egocentric bias — Give self undue credit for positive outcomes

False consensus effect — Believe that personal views are commonly held

Gambler’s fallacy — Believe that a random event is influenced by previous outcomes

The illusion of control — Overestimate control over external events

Loss aversion — Value keeping a possession over gaining something of greater value

Naive realism — Believe personal view of reality is accurate and without bias

Negativity bias — Recall unpleasant events more readily than positive ones

Normalcy bias — Refuse to plan for a novel catastrophe

Outcome bias — Judge decisions by their results instead of by the quality of the decision-making process

Our cognitive biases pose a threat to any adoption of agile or lean methods. They can damage collaboration, relationships, and team productivity. As a product leader, you have to work against it. You have to create an environment where people can build trust, provide transparency, show curiosity and the will to always learn and to understand each other. Communication is key to achieve this. To make it work you have to communicate too. Ask your team members about their exchanges. Is exchange happening at all? What have they learned from their exchange? How do they make use of it? How it impacts their collaboration and decision-making processes?

A shared belief in continuous improvement can allow your team to create a learning and performance-oriented culture. More than a power-oriented or rule-oriented culture.

If you want to learn more about the topic and get hands-on help to improve conversations. I recommend Agile Conversations by Squirrel, Douglas and Fredrick, Jeffrey. The core argument of the book is the following. Members of a team are not interchangeable parts of a software or feature factory. Rather they are humans with a unique set of characteristics that they bring to any project. In short, the book is about conversations that help you deliver value.

The initial example I provided you with is one of many potential examples. Communication is everywhere. That’s also the reason why I picked this topic as the first one to talk about. One important goal to improve is the will to understand each other’s story and to align them with each other.

Imagine two of your team members. One complaints to you about the other’s pace. How can communication help? A typical approach, many leaders would go for, is to take over and to talk to the slow team member to push her. What could be the impact? The slow team member will wonder how you know about it. Someone must have told you. Trust decreases and safety decreases. If you don’t serve the feedback well even motivation will decrease. Do you think this will increase the pace?

What if we would try another approach? What if the complaining team member would talk to the slow one? Trying to get her story. Asking about her progress. Is she happy with the created outcome? Does she believe it was an easy task? What was the biggest challenge she was confronted with?

Can you imagine in which direction it could go? The complainer could discover that the other team member was struggling a lot. The user story was written without her participation. Even worse she was confronted with a browser-specific problem that cost her more than 50% of her time. By asking questions instead of judging and commanding we can reveal underlying problems. We will discover each other’s perspectives which will help us to improve the way we work together.

Talking about writing user stories there is this nice article I recently read. It explains why product managers should not write user stories.

You see this simple topic isn’t as trivial. I could provide you more examples and more details but for now, I would love to read and hear about your point of view. Do you agree? Do you have something to add? Would you doubt it? Do you have a different perspective? Let me know and let us talk about it. If I see a good amount of interest I’m happy to write more about this topic.

The next topic we are going to discover is related to communication. So we will expand our journey. I will talk with you about the power of writing. Not in a sense of writing for a blog. More about how you can make use of writing as part of your product work. Something I started to practice more and more but I immediately felt the impact.

Thanks that you made it to the end. I hope it was worth it.

It’s my passion to build and empower cross functional product teams in order to solve customer problems. I believe in servant leadership where coaching is key.