A lot of our time as PMs is spent communicating with other people in our organization. There’s high-level communication and discussion, and there’s low-level interaction with stakeholders about the day-to-day of the product’s development and operation. Since the majority of our communication time is typically spent on the tactical, let’s talk about that.
It seems that we’re endlessly providing (or seeking) answers about anything related to the product. This happens naturally, because our role is at the center of the process that figures out what to build, builds it, and then gets it to market. The cross-functional nature of what we do means that we have to align and inform everyone around us.
Most days, we’re answering questions like:
- “How’s that feature coming along?”
- “What’s going to be on our next release?”
- “Why are we working on this?”
- “Why is that taking so long?”
- “Is that thing fixed already?”
- “How long will we be down for?”
- “Did you know there’s a bug when people try to do ‘so and so’?”
- “How’s that KPI doing?”
Or perhaps we’re reaching out to other teams to ask questions like:
- “Which bugs have been reported this week?”
- “What are customers asking for in our support channels?”
- “What are the top objections we’re getting on sales calls?”
- “Which are the biggest problems in the product right now?”
Granted, this isn’t exactly the stuff of dreams nor the reason we went into Product, but it’s still critical to our success. Efficiency-minded as PMs are, most of us have tried at least one of these tactics to handle the need of getting everyone on the same page:
- Simply answering as we go along, in order to save time on meetings and status updates. But then we get asked the same thing multiple times, people don’t remember, or those that don’t ask (but should be informed) are kept out of the loop.
- Create internal dashboards, docs or wiki pages, only to realize that’s where information goes to die, because people can’t find it, don’t understand the tool or forget to go there.
- Send internal email blasts with updates, but people complain that there’s too much info in them, that they’re too frequent (or not enough), that they “haven’t read it yet,” or something along those lines.
- Send updates in Slack, but then people say that there’s too much going on there and they missed it, aren’t in the right channel or weren’t paying attention at the time.
- Set up sync meetings to get everyone aligned, but they take time to prepare and facilitate, they’re not always useful or relevant for everybody and it’s difficult to get everyone that needs the info to attend (either because they’re out of the office or have “other things on their plate”).
The end result is that we settle on something, spend a lot of time on it, knowing (or suspecting) that it’s not really effective. These are problems that we typically accept as inevitable, but shouldn’t.
If we stop to think a little bit about our internal communication strategy we can be both more effective in getting the message through, and reduce the amount of time we spend on this (having specialized communication tools for PMs would help even further).
The communication dimensions
There’s a simple exercise that brings a lot of clarity to how we can structure our communication about the product with stakeholders. It’s not rocket science, but I’ve found that most of us get so caught up in the action that we don’t really do it. It’s about breaking down each bit of information we need to transmit (or get) into 4 components: content, audience, timing and format. In other words:
- What are we saying (or asking)?
- To whom should we say it?
- When should we say it?
- How are we saying it?
Let’s go through each.
Content (What)
To start the exercise off, we need to write down the list of questions that we get asked by (or that we ask) stakeholders. The top of the article has a few of them, and you probably have some more like those. That’s the easy part.
Where I find there’s also a lot of value is in listing the questions that aren’t being asked, but should be. That is, information that if other people (or yourself) had on a regular basis, many questions, conversations and discussions at both a high- and low-level, would be avoided/simpler/faster.
Most of the example questions above are about the delivery side of product development, and they come naturally. However, it’s less common that teams have processes to periodically stay updated and aligned on what’s happening on the discovery side. You know, questions like:
- “What are we learning at the moment?”
- “What will be working on next (and why)?”
- “How are we doing with regards to our goals?”
- “What important events/milestones are coming up?”
- “What are customers telling us?”
- “What’s working well and what isn’t?”
Including this type of questions into our “catalog” of internal communications definitely makes aligning different teams across the organization easier.
Audience (Who)
Every question should have an audience, based on who’s asked you (or should know) about it. This also includes yourself: you can be the audience of topics that you’d like to know about from other teams (usually customer-facing ones), which can bring you valuable feedback about the work your team is shipping (or considering). Think about it as either inbound or outbound comms.
To make this easier, I prefer to start by identifying the team or group of people that should know about each topic. Then, to prevent the risk of sending info to people that don’t need it, I narrow it down to the key people in those groups (usually the ones that are most involved with the product). Finally, classify them over the level of interest in the subject (e.g. high, medium, low, or ++, +, -).
Timing (When)
There are two kinds of information when it comes to timing:
- What needs to be shared as soon as something happens
- What looks to a past or upcoming period of time to answer a question
Few things actually need to be shared right away with our stakeholders. The most obvious ones being new releases or some kind of critical bug or downtime. This means that the “When” variable for some of our questions might be “right away”, but we should always consider how often the event occurs and how much the audience cares about it. If the answer to those is “happens frequently” or “doesn’t care that much”, then it’s preferable to group these events and report on them over a period of time.
Most of what we need to inform or ask about is not immediate and is related to “what’s coming ahead” or “what’s happened” over a certain period of time. Which is good, since there’s a certain cadence to product development. Things happen within (somewhat) predictable frequencies: development cycles, planning, releases, strategy/goal setting, experiment results, etc. Stakeholders that are more invested in a particular topic should be kept updated at the frequency at which it changes; others can be updated less frequently.
Whatever timing you choose for each bit of information you transmit, be consistent. It’s important that you keep to a schedule, even when there aren’t changes in what you’re sharing. People need to trust your “system” and that they’ll reliably get the info they care about. When they don’t, they’ll resort back to asking you directly about it.
Format (How)
This is the trickiest variable to determine, because it depends a lot on the organization’s culture and ultimately, each individual stakeholder.
However, there’s a way to look at this that I’ve found useful. Think about your communication’s intent and granularity as two orthogonal dimensions. The Intent of the communication can range from information-passing to decision-making. Granularity ranges from low to high-level—that is, are you talking about execution or about top-level goals and plan? If you plot this, then which formats to use becomes more evident.
Although this post focuses on the information-passing side of things, it’s useful to consider the difference in formats as we go into a different type of communication like decision-making.
Let’s take meetings as an example. We’re on them all the time. There are literally thousands of books on the subject: why they suck, why they’re great, how to lead them successfully, etc. Regardless of how we feel about them, they’re the most accessible communication tool we have for discussions on topics that aren’t fully structured yet (e.g. decision-making)—that’s where they add the most value. On the other hand, if all we’re doing is regularly getting together to go around the table and share updates with everyone else, they don’t add much value, especially if we can automate the process (getting data out of some app or using a tool like Basecamp).
Putting it together
The exercise led us through these steps:
- List all the topics we’re asked, we ask others, or that we want people to know about
- List everyone who’s interested in each topic
- Find the right timing for each topic and audience based on how often it changes and the audience’s level of interest
- Figure out the most effective format for the content and audience to which we’re communicating
This is in itself valuable, because it leaves us with a map that shows:
- The scope of internal communication work that (ideally) needs to happen;
- How much we are communicating with each person or team.
However, the real value is that with this information in hand, we can:
- Prioritize what to say to each audience, so they’re not overloaded and get updated about what’s most relevant to them;
- Prioritize the use of our time based on the effort that each topic requires and the value it provides to its audience—some topics probably “aren’t worth it”;
- Control different variables to test what’s most effective in getting the message across;
- Be aware of the topics that are being communicated and those that aren’t, so that we’re prepared to handle those questions as they come up.
What’s next?
Over the next few posts, I’ll be sharing some tips and templates that can help you implement this in practice.