Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.
Table of contents
LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns.
Communication is one of the product manager’s primary responsibilities. After all, a PM can’t do their job without effectively communicating risks, dependencies, and changes.
In small companies, communication is somewhat more intuitive and often easier to manage. The problems begin to appear when the company grows.
A bigger company means more teams, more stakeholders, more initiatives, and more of everything. Beyond scale-ups, communication often becomes either too chaotic or too infrequent.
In cases like that, having a robust communication plan can be a life saver. In this guide, we’ll demonstrate how to write a communication plan in six easy steps. You can also use our free communication plan template, which contains both a blank spreadsheet for you to fill out and a practical example to help you get started.
A communication plan is an inspectable artifact that describes what information must be communicated as well as to whom, by whom, when, where, and via what medium that information is to be communicated. In addition, a communication plan outlines how communications are tracked and analyzed.
A communication plan can take various forms. For example, it might take the form of a(n):
In general, a communication plan should be whatever works for you and your team, as long as it allows you to inspect and adapt your approach to communicating with others.
Investing time in creating and maintaining a communication plan brings many benefits. A communication plan serves as a(n):
Who hasn’t forgotten to inform some critical stakeholder about a recent change/discovery?
Product management is such a fast-paced and dynamic profession that it’s very easy to let small details slip. Unfortunately, it’s these small details that often matter the most.
A written communication plan serves as a checklist that ensures minute details don’t slip too often. Whenever something relevant happens, you can easily refer to your communication plan to double-check whether you’ve connected with everyone who needs to be in the loop.
A tangible communication plan allows product managers to slow down, inspect, and adapt their current processes.
Whenever there’s a communication mishap, they can review what led to it and adjust their approach to communication. A concrete plan makes a vague and sometimes intimidating term such as “communication” more tangible.
Learn more →
A communication plan, when done well, brings alignment and facilitates input from other stakeholders. It also lays out expectations of how communication is being handled and executed.
If stakeholders feel they aren’t getting all the relevant information, they can quickly check the communication plan to see what they are missing and what is lacking in the communication process that is causing them to miss that information. If they find the communication inadequate, they can share their feedback with the communication plan owner.
It’s easier to facilitate feedback and alignment when something is on paper.
As mentioned above, there are various ways to create a communication plan.
A simple way to write a communication plan is to answer six questions:
Start by reviewing what information you produce and process.
If you manage roadmaps, you probably produce a lot of information regarding roadmap changes, delays, and anything else that may relate to roadmaps.
If you manage releases, you also produce information regarding the release progress, stage, and anything else that related to releases.
To make it easier, start with the broader, more general concepts. And if you notice the need for more precision, split them into more detailed communication positions.
For a given type of information you produce or process, who should receive it? These are usually people who are:
Investing some time in defining the receipts has two main benefits.
First, it ensures you don’t miss a critical person in your communication flow, but it also helps you answer the question of who is not interested in certain information. Over-communication creates noise and should be avoided.
You should identify the frequency of updates being sent out depending on the information being shared and which stakeholders are included. Should it be daily, weekly, biweekly, monthly?
You probably won’t nail it at first, but that’s OK. What’s important is to search for a sweet spot between over-communication and under-communication.
Although it might seem excessive at first, finding the right balance will be increasingly important as the amount of and need for communication grows over time.
What medium is most suitable for a given type of information?
For example, it would be silly to inform someone about a mission-critical dependency in a comment under a Jira ticket. At the same time, you shouldn’t spam other people’s Slack with every minor change.
Before sending out an update, ask yourself:
The answers to these questions will help you find the best channel for the given information piece.
Many people fall into the concept trap that once you send out a message, your communication responsibility is over. This is not always the case.
If you send a company-wide FYI update, then yes, your job is probably completed when you press send, but what if you have roadmap changes that impact multiple teams. Shouldn’t you be making sure everyone on those teams are informed?
In cases like that, you can’t say you are done just because you’ve sent a message. You should chase all key stakeholders and ensure that they have read and understood your message to avoid any misconceptions.
Let’s face it: messages sometimes slip. Your job isn’t to send messages, but to ensure everyone is on the same page. It’s not the same thing.
I’m a fan of having a simple definition of done for communication items. Sometimes, it’ll just mean pushing an update. Other times, it might mean getting a signature of approval from another stakeholder.
Last but not least, if it’s everyone’s responsibility to make sure communication happens, then it’s no one’s responsibility.
Although the whole team should be responsible for ensuring effective communication, I believe in having a dedicated owner for a given communication stream. The owner can be permanent or rotate every sprint.
If you have communication owners in place, the chance of communication actually taking place increases dramatically.
Let’s take a look at an example of a communication plan created using the framework I just outlined:
This communication plan can now serve as an artifact for alignment, process improvement, and double-checking if everything is communicated as needed.
Since some of the items in the communication plan happen as needed, it’s imperative to review the artifact on a regular basis. Otherwise, details are bound to slip sooner or later.
To make it easy to get started with creating your own communication plan, we’ve created a communication plan template for you. Click File > Make a copy to customize the template.
When you start, ask yourself:
Although it may lack in the beginning, use it as an inspectable artifact to improve your communication approach every sprint. I promise you, it’ll make your job as a product manager significantly easier.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
