Tackling the challenge of communicating effectively in product management
One of my biggest challenges in product management has always been communication. As a product manager, you act as the glue between multiple departments with very little immediate power to enact actual change. That means that despite being accountable for execution, your ability to actually execute well lies entirely on communication.
Over the years, I’ve discovered also that tactics for communication have to change depending on what type of company you are at and how they tend to build product. It also has to change depending on who you are talking to and what their incentives are. In this post, I wanted to cover a couple different topics in this order (1) how do you know if your communication style isn’t working, (2) how do you discover a new communication style, (3) what are some concrete examples of lessons I’ve had where I’ve failed at communicating, and (4) what are some consistent principles that have remained the same on successful communication, regardless of the company or situation?
The tell-tale signs that your communication style is not working
I’ve seen so many cases where team members are failing to communicate, but they don’t even realize it. It’s so easy to see from the outside when things aren’t going well for others, but it’s very hard to see the same thing happening to yourself. So how do you tell if things aren’t working out for yourself?
Your team members are generally unresponsive to what you’re saying and don’t provide the feedback you need
This has definitely happened to me often - but essentially, you’ll say something that is completely met with silence. The problem with this is that as a product manager, you’re often trying to solicit feedback from your team, or push your team towards a path of execution, so silence is an execution killer. A couple strategies to try here are:
Explicitly call out team members who have the expertise to provide the feedback you are looking for, and ask specific questions. For example, “I’m not entirely sure about whether or not this feature is even technically feasible or worth doing. What do you think ___?”.
Ask your team members if anyone has questions, and wait at least 9 seconds so that they have time to process and respond.
Ask your team members what they need to provide the feedback you’re looking for. Is it more time to think? Is it more context? Is it more time to review the problem statements? For example, “I’m looking for confirmation that this feature is scoped correctly. Do you all think you have enough information to make an educated guess here?”
You experience a lot of push back all of the time that doesn’t end in a conclusion
So in my opinion, push back is good and an unavoidable fact of life. Push back means that your team is engaged, and they are trying to provide feedback, but potentially in a way that isn’t effective. The key here is to identify the root cause of push back and to make sure that you continuously drive towards a decision being made. Sometimes, push back can be a symptom of a far nastier cause - a lack of conviction in what you are saying to begin with. Other times, push back is the natural course of getting feedback and discovering the best approach forward.
Typically, I think push back as a symptom of lack of conviction is diagnosed when you offer multiple options or workarounds, but continue to get push back. Typically what I’ll do is think through a problem together with the team, but if the solution we end up with is unsatisfactory to everyone and push back continues, I’ll actually choose to end the meeting and “re-visit” so that I can spend time thinking through how to solve the problem rather than continuing to discuss a problem that everyone disagrees on. The reason for this is that often the push back comes from a source that isn’t immediately obvious, so continuing to discuss things creates more friction and frustration. Often times, I’ll discover that the push back was merited and come up with a better solution. Other times, I’ll continue to believe that my solution is right, but the extra time I spent thinking about it allows me to return to the team with a more thought out solution.
Discovering a new communication style
When you discover that your communication style might be falling on deaf ears, how do you try something new? Some strategies I’ve tried before are:
Conducting post-mortems: We just did one this week where I had everyone on the team share what they thought was going well, what they thought we could improve, and how they thought we could improve it. In these broad team discussions, you’re able to get feedback on things your team wants to change. For me, some action items that came out of the post-mortem were to write more detailed tickets >.<
Ask for advice: After some particularly difficult meetings, I’ll actually Slack team members directly to get their “real talk”. How did that meeting going and what could be improved? It also gives me a chance to explain where I’m coming from and why certain things went down that way.
Throw stuff against the wall and see what sticks: I’ve tested a bunch of different meetings formats - sharing product specs before the meeting, having the team read through the product specs live, drawing out wireframes to map out the flows, etc etc. It’s really obvious when something isn’t working, because if you don’t get what you want out of a meeting, it didn’t work! Getting your communication style to work is a constant work in progress, and as the company grows or the team changes, you have to continue adjusting your communication style. It’s totally fine for things to not work the first couple times, as long as you constantly adjust things to make them better, and quickly identify when things are falling apart.
Some concrete examples of communication failures
Learning the difference between communicating requirements to front-end vs back-end teams
When I first started out in product management, I was focused on building an OSS database where much of the product work was influenced by engineering. Our persona was the developer, so the engineering team had an intimate understanding of the interface they would want to work with and how they would expect a database to behave. What that meant was, my main area of focus as a product manager was figuring out what customers and the market wanted in terms of features, prioritizing those, and fleshing out very high level requirements. The engineers would then run with the requirements and flesh them out further into actual tickets. This meant that literally all I had to do was write up a couple bullets about what I learned from customers and translate them into user facing requirements.
When I transitioned over to covering the front-end product as well, things got a lot more complicated because the front-end wasn’t built in as “waterfall” of a process. There were constantly questions about how different minutae of the product should work, and user flows became a lot more important. Needless to say, bullets simply weren’t enough. You could tell things weren’t working because we would have numerous meetings to talk about the same topic, and we’d continue to re-visit the drawing board. It was very stressful for the entire team!
On the front-end side, what we ended up doing was transitioning over to clear pods (which we hadn’t done before), and writing up specific user stories and going through the flows associated with them. We’d prioritize the different user stories and walk through designs together. We also started prototyping things faster, since many of the interactions were hard to spec out without having something to work off of. When I moved over to a different company where I similarly worked on the UI, I had a similar situation where I didn’t spec out a feature clearly enough and the entire development process was incredibly confusing. In that case, the team told me exactly what they needed from me, which was for me to draw out the user flows, and that made it possible to improve the process the next time around.
Identifying when what I think is good enough communication actually isn’t
Now that I’m at Correlated, in addition to communication, one of my biggest challenges is simply having enough time to do things! I typically don’t have enough time to flesh out features to the level of detail that I used to, and it’s always a balancing act on how much discovery you leave to the team and how much discovery you do yourself.
Recently, I noticed that I was actually pushing too much of the discovery to the team. Some symptoms of this that I observed were: direct feedback that tickets needed to be fleshed out more, lots of questions during the product and design kick-offs that I didn’t necessarily have well thought out answers for, and edge cases discovered later in the development cycle that could have resulted in complete revamps (if we weren’t careful to limit scope). In some cases, there were features where I knew I should have spent more time looking into it, but I didn’t.
The thing is that at any startup, prioritization is key, and to be frank, sometimes writing out the most amazing product spec simply isn’t the best use of time. However, if the team is having to fill in gaps in areas that I should have filled in, that’s when you know that good isn’t good enough.
I’ve also discovered that although product specs are a useful tool for communication, at the end of the day, you do have to meet to discuss particular areas of the product spec that are confusing or not fully scoped out yet. That’s why a new strategy we are going to try is to treat product and design kick-offs more as feedback sessions so that we can continue to iterate throughout the entire lifecycle of a feature.
Consistent communication principles that remain constant regardless of project / company size / team
Put in the time to do the prep work so that meetings run well
I’ve been incredibly guilty of not doing this recently as I almost never have time! But I do see in many meetings that I run how it could be run more effectively by just doing a bit more prep work to define the agenda and structure the conversation so that everyone in the meeting gets what they need out of the meeting.
Explain your thought process and the type of feedback you’re looking for
Context is king! Almost every conversation I have in which I just jump into the problem without explaining why results in push back. That’s because you’ve brought people to the end conclusion without walking them through how you got there in the first place.
Listen and ask questions!
Communication is obviously a two-way street, and without leaving people room to digest, think, and react, you’ll end up not actually communicating. I do think it’s important to listen and let people finish speaking and to ask questions to fully understand what they mean.
Know when to dig your heels in, and when to compromise
As product managers, we’re mostly trained to aim for compromise and consensus. However, as we grow in our roles, there comes a time when it’s important to also take ownership of decisions that are made in order to level up. In the past, I’d often strive for consensus between designers, engineers, and product - but the problem with that is that we would hit situations where there was something I was pretty sure about that I compromised on, and we ended up having to go back to adjust it. Now this is natural and happens all the time, but one thing I’m working more on is to identify when compromise actually hurts the end outcome. In certain cases, I do continue explaining my position a couple times in order to make sure people understand where I’m coming from. At the end of the day, I often also make the decision as long as no one vetos it.
However, it’s also important to know when to compromise. In fact, every time I dig my heels in, I find that I’m able to get to a solution that accounts for both my concerns as well as the concerns of the team. I do use a criteria to figure out whether or not to compromise:
What is the risk of this compromise?
How sure am I that the concerns I have are legitimate and should be addressed (it’s basically impossible for me to ever be at 100%)
Am I able to cover the majority of my concerns with this compromise?
I also try to communicate this criteria with the team as we discuss a feature. For example, I recently mentioned that we should allow users to delete things (vague feature explanation), but the team immediately brought up a bunch of implications that would make the feature incredibly complex. We discussed the use case for supporting it, the risk of not supporting it (we would essentially need to delete things ourselves), and whether or not my concerns were important enough to address now (I felt that this wouldn’t happen often). We ultimately decided not to do the feature at all and maintain status quo, but went through the exercise of determining whether or not the decision was the right one to make.
This strategy of discussing risk with the team is highly effective, because it gets people away from thinking about “right or wrong” and instead to start thinking about “taking bets.”