Effective Communications: A simple framework for Product Managers
Background
Raise your hand if you’ve seen “excellent written and verbal communication skills” on every job description you’ve ever seen? It’s such a basic expectation of all roles, that the importance of communications in the context of product management is a little lost. There’s a lot here, and this is probably one of my longest posts, but it’s really critical and there is A LOT to cover.
The role of product manager is a central linking point between many teams, and has the ability to impact the business in a large way. If a PM is anything less than an awesome communicator they will struggle in the role and struggle to move up. No one sat me down and explained this to me - just like an ML model it took a large training set of many years in different scenarios, companies, industries and roles for me to arrive at this framework. It will still take you quite a while to fine tune how to adapt it to your situation, but I hope you find it to be a helpful starting point.
Product Manager Communications Framework
The PM Communications Framework breaks down any potential communication you are going to make into five parts that should be considered and right-sized for the situation:
Why - what is the goal of the communication?
What - what is the content you are communicating?
Who - who is the target audience?
When - when / how often do you need to communicate?
How - what is the best format to communicate your message?
It seems straightforward and obvious enough, but like everything else in product management it’s more complicated than it looks. What I’ve typically seen is that many PMs are very comfortable with certain types of communication methods, audiences, and content, and in other settings they are a train wreck. To be good at this job you need to be able to mode switch between the possible settings for each point in the framework, literally from minute to minute as you go through your day. Over the course of the rest of the article we’ll get into each of these steps in more depth for some common scenarios
Start with “Why?”
The most important step in improving your communications ability is being very thoughtful and deliberate about why you are going to communicate something. Because there is not a lot of formalized training a lot of PMs do pattern matching and emulate what they see other PMs and colleagues doing in various settings and apply it to whatever they are doing. Every time you write and email or start talking in front of a group, you need to tailor the communication to the specific situation.
Understanding why something needs to be communicated has a lot to do with understanding dependencies within your business. This is why attention to detail is so critical for product managers. If you have a superficial understanding of how your business operates and don’t understand how all of the pieces outside of your product fit together, you’ll miss the “trigger” conditions for when you should communicate something.
Once you are able to identify trigger conditions, you’ll notice that most of the high-stakes and communications fit into these buckets:
I need permission to proceed
I need someone else to do something for my goals to be achieved
Other people need to know to do their jobs well and not disrupt the business
Something is going wrong and we need to keep everyone aware of real-time changes to “normal” as we address the problem
If you take a moment to figure out why you need to communicate something, it will help you make the appropriate choices in the framework for all of the other elements. As an example, if you are asking for an agreement or decision on something big, that probably makes sense to do in a small audience live on video call or in person. If you are communicating the actual decision and resulting next steps, that is probably fine as an email or link to a write up sent to a much wider group of people.
Also, don’t forget to ask “why you?” Nine times out of ten, people are fine to let someone else communicate something (and take all the questions), however you should pause and ensure that it is truly appropriate for you to be the one sending this message. Should the engineering manager, or marketing, or legal be the one to send this? Take a beat, and think about it before you send, and maybe check with the person who you think would or should send it if not you. Selfishly you may avoid extra work responding to something that is not yours to drive, and more importantly you will avoid having someone get their feathers ruffled for no reason. In the end effective communication is more important than people’s egos (sorry), so you should ensure the message gets to the right people even if that does piss someone off, but check first.
Driving a Decision
Goals
This section is called “driving a decision” and not “asking for a decision” intentionally. Effective product managers have a well-informed opinion about the right course of action, and while they may not have the authority to move forward on their own, they know what they want to do. Probably the worst thing you can do as a PM is show up to a meeting with your boss or senior leadership without a strong view on what you should be doing and instead asking them for the answer. This job is about decisiveness and if you ask them to do that part for you, then it’s fair for them to question whether you are right for the role. You are communicating what the company should do and why. You are asking for support for that idea, not asking for permission or for new ideas. The key here is to have a strong, clear recommendation that is data-backed, with obvious and clear benefit to at least the business, the customer, and ideally both. To actually arrive at a well made recommendation, you can read this article about improving decision quality.
This one is also tricky as there is a fine balance to maintain between not giving up your authority and autonomy by asking people to sanity check every decision you make and ensuring that large impactful decisions have buy-in from senior management. This is why it’s critical for you to have a conversation with your manager about what types of decisions they expect you to make on your own, which types they want to be a part of, and which decisions require the involvement of senior leadership. Usually you can sense this without asking directly after some time at a company, but it really varies a lot from company to company. Either way, invest in clarifying what types of decisions need to involve other people.
Content
A prerequisite to making any big decisions when you need to involve others is ensuring they have the appropriate context. In terms of specific content to provide context it should probably be pretty dense. Lots of data ideally, appropriate visuals, etc. You are trying to make the case ahead of time so that when you discuss it later people are just asking clarifying questions. If someone is trying to build enough context in the moment to make a decision odds are things are going to go off the rails. Give people a clear summary of what matters with the ability to see all the background reasoning if they care.
The biggest mistake I see junior PMs make is to show up to some meeting with senior leaders assuming everyone knows why they are asking about this, why it matters, and that they are aware of all relevant background. They’ve done no prep, and sent no pre-reads and expect things to go well. Senior leaders by definition have a lot on their plate, and it’s very likely they have no idea that this was even going to be a topic before they joined the meeting. Assume everyone you need to make a decision knows nothing about the topic. Work backwards from that as you answer the remaining questions in the framework - what do they need to know, how much time do I need to give them to absorb it, what do they likely care about as a result of how this impacts them?
Audience
Decisions should be kept to the smallest group possible. This is especially true in large companies, but is true at organizations of any size. You only want to include people who are required to make the decision, not everyone who wants to be included. It’s tempting to piggyback on existing meetings that have the hard-to-reach people you need already in one place at one time, but be careful if that forum also includes a bunch of other folks you don’t need. If you are going to do this, make sure your pre-read content makes it to everyone who will be there so you don’t half-informed people slowing things down in the meeting.
Regardless of a person’s level of role, the most important thing is to translate in your head between what you care about and why you want to talk to them and what they care about what you are asking of them. Empathy is not just for customers, it’s for your peers as well. I’ve seen more PMs get unexpectedly lit up by a manager or exec for failing to understand how a change they were making impacted their group. Sometimes it’s an honest mistake with a group that you have an otherwise great relationship with. When it gets ugly is when the PM has not invested in understanding how everyone else does their job enough to understand what may cause an impact. They are seen as disconnected and irresponsible and it’s very hard to build back trust after that.
The last 10% of knowing your audience is the individual specific presences you just need to learn as part of your own ML model over time. Some people just need things written down, some people need to see something five times, some CEOs want you to “put away the slides and just talk to me.” If you are on top of the details and have a good understanding of what drives the person, you’ll still do fine and you can tweak the personal preferences over time. The one caution here is that you should not sacrifice the integrity of the communication and the choices you make in this framework to solve for the preferences of one person. It’s very rare that one person matters more than everyone else, even when it’s the CEO - it just might require you to do something custom for that one person, then do what you would have done for everyone else.
Timing & Format
In my experience the format that works best for driving decisions is sending a written pre-read with a recommendation and context in advance, having an in-person or video meeting to discuss any questions, and then sending a written summary of exactly what was decided or approved. You can scale this up or down and you may need more lead time based on how big the decision is and how many people need to be involved, but it works in almost all cases.
For particularly high stakes decisions or if you have a very large company with lots of management layers and lots of people that get to “weigh in” it may be good for you to find time with key people ahead of the meeting to answer any questions before the big show. It may feel dumb and political, but the job is getting the right thing done regardless of the annoying steps required. Depending on your company you may need to have a brief chat with all of the primary decision makers before they are in a meeting together on the topic if that’s what ensures everyone has high confidence in the plan. There can be a weird dynamic where people who were onboard start to change their position if someone is very vocally against the proposal in the moment. The best way to avoid bad surprises is just to get everyone’s pulse between the pre-read going out and the meeting to discuss.
The timing should be such that no one feels particularly rushed and you leave some room for a go-around if necessary. In general you should leave AT LEAST two full business days between the pre-read going out and the meeting. I’ve seen so many PMs spend a bunch of time writing something and send it out the night before the meeting. Not surprisingly no one has had a chance to read it before the meeting and things go poorly. If you aren’t going to leave a reasonable amount of time to let people absorb and ask questions, then you should just not spend the time coming up with the materials. Aim for 4-5 business days as a rule, and you can scale up or down as necessary for the situation.
The good news about doing pre-reads well is that the actual meeting can be relatively short. I’ve seen lots of places schedule these 2 hour strategy meetings to make big decisions and they are usually not very effective because they are trying to deliver all the context, get all the questions answered, and make the call in the time. Some questions may take a day or two to run down and turn out to be nothing, but if you let that happen in the meeting you may be blocked and required to come back around. If you’ve sent pre-reads, people have asked questions ahead of time, and you’ve spoken with a few of them, make the decision meeting 30 min. There really shouldn’t be that much to discuss.
In the meeting itself, if you’ve done everything else right, you can keep the presentation pretty light - do a one slide summary of what, why, when, how much, etc and run through that again quickly then jump to the questions that people raised out of the pre-reads. That’s new content and it shows you did your homework. Assuming there were no red flags from the pre-reads, jump to a next steps slide that states “assuming we get a yes, we will do X, Y, and Z at these times.” Make it clear what the decisions means and when following the meeting. Immediately after the meeting send around a written summary of what was decided and any caveats or notes to the people in the meeting. Do this while everyone’s memory is fresh and don’t skip. I had people’s recollections of what they agreed to change, or my understanding was off - either way, make sure you have a record of what was agreed to.
Finally, you have to remember to tell everyone else! If this has been something you’ve been working on for a long time you may be very excited to go jump in and start working on what it unblocks, but be sure to do an information broadcast to a wide audience informing them of the decision that was made. To the extent you can and there are no sensitive materials, share as much of the background context as you can with everyone. People are more likely to rally around something they understand versus what they are told to follow “because.”
Getting Help From Other Teams
Goals
Oftentimes you will need to secure the help of one or more other teams in your company to ensure your product team is able to achieve your goals. This could be getting other product teams (e.g. API teams) to do work to support something you want to build, or marketing, customer support, etc. The keys here are that A) you have no formal authority over them and B) you need them to do something specific to support you. This is where a lot of the infamous “influence without authority” comes from in the PM context.
Content
The most important thing when trying to get the help of others is to be very clear about what you need from them and to set clear expectations about timing. These are the basics but they are worth discussing. Product teams are used to talking about “requirements” or stories or whatever so it’s more formalized. With other internal teams you may need to come up with a different artifact that allows you to appropriately communicate in detail what you need by when.
It’s also critical to cover why this is important for the business. A lot of PMs skip this step and try to brute force what they need into other teams. Everyone has a full list of things to work on every day before you show up with your needs. The art of influencing without authority is to tell a truthful, compelling story about why this is important, and is potentially more important than other things they had planned to do first.
There is an important side note here related to company culture and org structure. Securing the help of other teams and effectively influencing is A LOT easier when the company has a clearly communicated strategy, goals, and everyone is on the same page. Trying to get multiple teams to do what you need at the right time is still possible but requires a ton more effort when they are all operating against loosely joined plans solving for different goals. If you are finding it really hard to get people onboard even when you think the case is pretty compelling it may be worth investing in trying to manage up a bit and try to sort out why different teams have different goals.
Audience
This one is fairly straightforward as 90% of the time you are making a direct ask of the peer IC or manager that can get the thing done that you need. The only two callouts I’d make here are to not accidentally assign work to people in another team in the place of their manager, and be mindful of when you should give a heads up to more senior people. If someone has a team of 3-4 people who could help you with a project, make sure you let the manager have a say in who gets assigned. You may prefer one, and you can ask “may I work with X?” but don’t just go straight to the IC unless you know they are permanently assigned to your project. Managers get really tweaked when “pushy PMs” start making assignments within their team.
In some situations if you are making a big ask in terms of time or resource you may want to give the person some air cover by notifying people in their management chain that they will be helping, why it’s so important, and that you are very appreciative. If people are going to have an issue, it’s better to find it early and make it clear you’re trying to work well with everyone, not ram things though.
Timing & Format
If you need something from someone else, in general I’d ask in person with that either being in-person or on a video call. As you get to know people you’ll figure out what you can ask them over chat vs what still needs a meeting, but in general assume that if you are asking something of someone you should be able to see their face. The face to face meeting does not need to be particularly long, but I feel like it’s very important to give the person a chance to react, and explain what else is going on in their area. This way they have a chance to agree to take something on before you send along a detailed request.
I feel like most PMs are pretty good at this, but sending a very detailed request over to someone else completely cold via email or chat generally does not go over well. Unless you have a very strong working relationship, it can very easily rub the person the wrong way, especially if they are already at capacity. In effect you are saying you just expect them to do this without investing in the relationship to understand their situation. Build some empathy and see if there is perhaps a way you can help take some of the other stuff off of their plate so they can help you.
Give people as much notice as you can, but make sure you are only asking when you are sure what you need and when you need it. Don’t get a reputation for getting other people spun up on things that never go anywhere. Eventually your credibility will be shot and it will be hard to get people to jump for real when you need them to. Respect other people’s time and only ask them to engage when you know it’s going somewhere.
Broadcasting Information to Others
Goals
In terms of volume, if you’re doing the job well and your company is well managed, then 90% of your communications will be low risk, low urgency “FYI” communications. They are still important, but the stakes are often less as long as you keep them up. Don’t tune these out as “easy.” Getting the right level of details and timing correct for these messages still matters a lot for your perceived effectiveness as well as the general happiness of you and your manager.
One of the primary roles of a product manager is to keep people informed of what is going on. As someone driving a lot of (hopefully positive) change in the organization, it’s your responsibility to keep everyone informed about what the changes are, when they are coming, and what if anything they need to do about it.
I’ve seen many times where people outside of product and engineering refer to the product development org as “a black box.” We don’t know what’s coming, when it’s coming, or how you arrived at this as being the most important things to do? In most cases when people are saying these types of things, there is no basic outbound broadcast information coming from PM to the rest of the business. This is where the “overcommunicate” saying comes in for most PMs. When people don’t know what you’re up to or don’t understand what you are doing, bad things start to happen and trust starts to erode. Your best defense against hostility from others within your company is to keep them so informed they are bored with you.
Another key nuance here is to not incorrectly categorize something as Broadcasting that should be Getting Help from Other Teams. One of the quickest ways to lose friends as a PM is to inform another team that something you are doing will require them to do a bunch of work and they are finding out for the first time via a blast email. Less likely, but also important is trying to sneak a decision beyond your authority into a broadcast communication. If you are a bit of an introvert, you may prefer broadcasts because they are typically async written communications, however they cannot replace the appropriate format of Decision and Getting Help formats that often require some face to face work upfront. If you do the legwork to appropriately get a decision or request help, then you can fall back to broadcasts going forward, just don’t start there.
Content
A typical artifact for this type of communication is a product roadmap. Entire books have been written on that topic, which I’m not going to go into in much depth here. I’d only say if you are going to send a roadmap, do it safely and follow a format roughly close to Gibson Biddle’s “Now, Next, Later” and for more detail read Roadmaps Relaunched.
The key thing here is to avoid getting fixated on the date and the name of the feature or solution itself as often happens. This is why roadmaps get a bad reputation. They overemphasize something that is often uncertain (the date) and the solution, but don’t spell out why you are doing it, who you are doing it for, what the expected benefit is, and how you intend to measure success. If you are communicating new things that are coming, just be sure regardless of format to touch on all of those elements equally. Everyone will be able to do their jobs better the more context your provide beyond what and when.
Audience
Knowing your audience and adapting your communications style appropriately is what lifts successful PMs to senior roles and it is also the spike pit filled with the remains of PMs who sent a long email to CEO explaining an agile process detail instead of the business value of what they were doing. This part is so critical and a lot of people get years into being a product manager before they start making real progress to improve. You’re already ahead of the game!
As the name implies, broadcast communications are meant to go to a wide audience and typically include senior leadership, middle management, and ICs. Electronic communications are cheap and it pays to keep more people informed than not. Junior PMs, especially at larger companies with many management layers can be a little shy about sending communications to a wide audience. Senior folks can always just ignore you if they are overloaded, but better to err on the side of caution. Dealing with “please stop sending me these” is much better then “why wasn’t I notified?” Make it clear in whatever you are sending who has “to-dos” so that everyone else knows that they aren't being asked for anything. Similar to decision driving communications, send a summary that’s easy to scan with links to the details. Assume everyone is overloaded and does not want to start with a 9 page write up.
Format & Timing
If you are broadcasting non-urgent information a written format is better. This is where all of the “this meeting could have been an email” memes come from. If no one is discussing anything and there are no decisions to be made, it does not need to be a meeting. People can ask questions over chat or email. It’s extremely inefficient and expensive to have 20 people in a meeting just to read off status for the benefit of one or two senior leaders that actually are responsible for everything in the meeting. Everyone else owns their one thing and spends 99% of the meeting wasting time (or multi-tasking). The basics of written communications still apply - put a “so what” at the top or in the chat / email with a link to pages of detail if people care.
Communicate as soon as it is responsible to do so. Oftentimes it will make sense to hold off for some period of time to verify something or do a quick analysis before passing along a message to the affected parties. The key is not to hold on to something for too long. Whether you intended to or not, best case people will think you are poor communicator and worst case that you were holding back for some reason. Operate under the basic principle that you should be trying to pass along relevant information as soon as you are sure that it’s responsible to share it.
If you are communicating a medium or large change, a launch, or something that may impact a wide audience in the future, it’s best to start notifying people as soon as you have confidence in the timelines. Don’t end up with date slip fatigue by saying something is coming in six months for three years in a row. However, when you’re a month out and have line of sight to the end, you can start telling people early to give them the max time possible.
For smaller changes or releases where little impact is expected you can collapse to a week or as little as “tomorrow” depending on the relationship you have with other internal teams. If you’re launching an A/B test and have a solid relationship with customer support and other relevant teams, just giving them 24hours heads up to notify agents to be aware something may look a little different is fine. In general it’s safer to start out with more notice and then work your way down to less as you figure out how the company and other teams work.
The key here is not to treat communications as a CYA exercise to prove that, in the event of a major f-up, you had notified everyone. See the article on ownership and come back. If a key player has not responded to your communications, even though you’ve tried several times, it’s on you to go track them down and get a clear “we are ready message.” Don’t proceed and assume everyone will forgive you proceeding when that team wasn’t ready. Own the outcome.
Crisis Communications
Goals
Occasionally things go sideways and you have to deal with a real-time crisis. There’s an infrastructure outage, or a nasty bug gets deployed, or some PR issue flares up. Whatever is going on, the goals are typically the same:
Provide as much air cover as possible to the team trying to fix the problem by…
Keeping everyone else as informed as possible about what is going on and what’s being done about it so that…
People don’t start to panic in a void of communications, start to act on bad information, and potentially slow down the recovery
As I said up front in the “Why” section, the key piece here is to ask whether or not you should be the point person. You will be largely consumed by this while it’s going on and unless you are really heavily involved it may be better for the engineering manager, or marketing or whoever to run point. If you sense it probably should be another team but are not super confident the person being nominated is up to it, perhaps offer to help. Certainly you can set the expectations with that person to help them be successful in the role.
Content
First things first you need to focus on providing a very clear and concise description of the impact of what is going on. No flowery language, no humor. Facts, data, timelines, etc. It’s critical that there be one source of truth during a crisis so be sure you establish that with the best possible details you can find.
Beyond that, when things are going wrong, the best way to calm everyone down is to build trust that the appropriate people are aware, that the best people are “on it,” and that you understand the importance of keeping everyone up to date. In every message you send, reiterate who is aware (if not obvious), which team(s) are doing what in response and when you plan to send the next update.
Audience
These are in theory very similar to a broadcast communication and likely will have a similar mix of senior leaders, middle managers, and ICs. In general, wider communication is better because you are trying to create a single source of truth and prevent people from wasting unnecessary cycles. The only call out here is to be mindful that there may be some sensitive information that does not need to go out to the entire company (and would not normally).
Format & Timing
The key here is hitting the right frequency and in many cases telling people when the next update will come. Setting expectations is always important but when everyone is on edge it’s even more critical. If you are dealing with a full or partial outage then communications should be as real time as you can get without being disruptive to the team solving the issue. If it’s going to take awhile to resolve then say “next update will be in 30min” or whatever. If the acceptable time scale for resolving something is a week, then maybe it’s daily updates. You need to tune it to the situation, but in general the worse it is, the more often you should be sending out updates.
Frankly the format matters a little less than clarity and timing. If it’s a complex issue and you need a large group to weigh in on a menu of crap options, then do that as a call and follow up with written communications to share what you decided. If the solution is straightforward but will just take time, then go with short, clear, and frequent written communications to provide updates to impact and progress.
My business ethics professor boiled the entire class down to one question “would you feel comfortable explaining what you are doing to your mother?” If the answer was no, then you were probably doing something shady and unethical. As product managers we try to stay on the right side of what Mom would approve, but there are times when there are no good alternatives and a decision still needs to be made. Oftentimes is a crisis you will have several unattractive options to pick from that may cause more immediate pain in the hopes of resolving the bigger issue quickly. Lucky you, that often falls to the PM to pick the least worst option, however in those situations you have a duty to let others raise additional red flags or concerns that may change your approach. The key here is the framing - focus on what you are optimizing for and how that led you to the option you are suggesting. Come in prepared, but again in these situations I’d suggest a quick call among key parties before proceeding. Effectively you have to compress the “pre-read to meeting” part of the decision driving process to 15 minutes.
Summary
Learning to master all of the necessary communication styles and formats of a product manager can take several years, even if you are pointed in the right direction. Hopefully this framework provides you with the guidance to avoid some typical junior PM pitfalls and accelerate your mastery of this critical element to being an effective product manager.
