As a tenure PM of 4 years, I have learned that there is one skillset above all others that makes the biggest difference in one’s job. Its one that I could do better at always, and often times fall short of the high standard set in my mind. That skill is communication.
I’m not just talking about being a good talker, I’m talking about communication on all levels. These levels include the squad level, the department level, the team level, internal communication, external communication, written and verbal, and slack.
As I write that all down, it’s overwhelming to me, trying to digest how we communicate our plans, visions, new features, bug fixes, enhancements, and the like to everyone in the organization, to customers, and to the public.
At Weave, product managers owned the entire communication pipeline. We operated entirely on our own to communicate the message to everyone and anyone who needed to know. This included new features, release plans, releases, bugs, bug fixes, marketing both external and internal, etc. It was a challenge and still is.
Weave is a rapidly growing company adding over thirty heads a month. Scaling communication has been a mission the product team is focused on to make sure the right messages are delivered and understood.
In one exercise in a Friday “Edge Hour” meeting, where we discuss tactics, skills, case studies, etc. to hone our skills as PMs, we listed all the mediums that we communicate with our Weave support team.
The problem we were brainstorming for was how we can better communicate with our support team, so that they can communicate bug fixes, and more embarrassingly new features.
The task was to list out all the channels of communication we used to communicate with support. we slapped a sticky note on a pillow or box to give a visual representation of each channel. After a few minutes of yelling out new methods of communication, there were so many pillows and boxes that I was literally blocked from view. Over 20 different mediums were listed out, some of them overlapped in purpose, and some were used exclusively by the support team, but either way it was overwhelming for them, for us, and immediately allowed us to visualize the problem.
We showed this to support, training, and a few other departments, each department person had a similar reaction, feeling the burden of the problem we were trying to solve and understanding we needed to address this ASAP.
In the example above, were only trying to solve for one other department we needed to communicate with, we didn’t even scratch the surface of sales, training, onboarding, marketing, etc.
Below, is a list of things we learned from the exercise in Edge Hour.
No News is Bad News
After the exercise exhibited above, we came to the conclusion that, we definitely have a communication problem, but more than that most people just want to know whats going on even if the answer is, “I don’t have any updates for you.”
Most of the support personnel we interviewed during the activity just didn’t want to be left in the dark, and wanted to at least know we’ve seen or read their inquiry about a particular issue.
We then brainstormed some ways that we can be proactive in communicating to support, our first experiment, about updates to bugs, and if necessary, though rare, outages.
Supports main concern was we just need to know something so that we can tell the customer. It doesn’t even have to be the solution, but something is better than nothing at all.
Even if you don’t have good news, no news is bad news.
Simplify the Message
I get it, it’s complex and hard to simplify a complex release, or gather all the necessary information to give an accurate time on when a feature will be released or bug will be fixed. Deciding what technical language to leave in or out, how detailed you want to make a brief, memo, email, or release note.
I have struggled with getting this right multiple times, failing to communicate could be worse than a complicated message, finding the right balance will take practice and will need to be adjusted as your organization grows and scales. You want to avoid the telephone game, where the real message gets lost, but also not lose trust by going dark on people who rely on your communication.
Simple, scalable communications is hard. Simple in theory but everyone who hears the message wants to know how it applies to what they are doing.
Know Your Audience
Different audiences need to know different things, some apply, some don’t. Whether you’re communicating with engineers, executives from other teams, sales, support, training, customers, or prospects you have to be able to cater your message and language to the appropriate angle to get your message across.
While communicating to engineers, technical language, data, metrics, and purpose are all important. Not looking like an idiot requires that you’ve done your due diligence and understand the engineering culture well enough to navigate tough questions, and even some playful ridicule. They’ll most likely want to know what they are building is going to provide enough value to the company, or customer to spend their time building it.
Starting with the why, will help them and you understand the purpose of what you are doing. Communicating the why in a clear manor will set the stage to ask for whatever it is you need them to build.
On the other hand, Sales, needs to know why this product will make their job easier to do. Competitive data, statistics around the product helps them to get your product into the hands of new users faster, thus adding to the adoption metrics you can show off in your next 1 on 1.
Conclusion
Finding the balance of communication and perfecting the art is a goal i strive for each day. To help me I set reminders on my calendar to send out communication about upcoming events, build timelines to create clarity on release timelines, and kept email chains alive for far too long to help keep a clear and concise message. I hope the tips above help better your communication and Id love to hear some feedback on what you’ve done to maintain and scale good communication in your organizations.
