Mastering Effective Communication as a Product Manager

View Comments
good-communication-S10-1

Product managers spend much of their time communicating ideas, plans, designs, and tasks to their teams. This includes everything from emails communicating decisions, to presentations communicating product roadmaps, to specs communicating product designs, to bug tickets communicating errors in the product.

Mastering effective communication is known to be an accelerant to the dissemination of ideas, to team cohesion, and to even the motivation and inspiration of team members. Given this, it’s worth spending time as a product manager thinking about how you can improve the various communications you have with your team.

I wanted to share some of the best practices I’ve observed on effective communication around the three high level responsibilities of product managers: vision, design, and execution.

Communicating the vision
A compelling product vision communicates the audience you are targeting, the distinct problem you are solving, and the unique solution by which you’ll win the market.

It’s important to come up with a succinct version of your vision that is no more than a quick elevator pitch. In doing so, you’re forced to carefully consider each word you include to understand if it’s really tantamount to what you’re trying to accomplish. This vision statement can then be used anytime you are asked to describe the product. I tend to include it at the beginning of most of my written specifications as well as in most of my product decks as a brief introduction and reminder to everyone what exactly it is that we are trying to achieve. While it may seem repetitive to do so, it’s extremely important to be consistent and constantly remind all stakeholders of it to ensure everyone stays on the same page.

Beyond the elevator pitch, I find it helpful to also prepare a more detailed presentation that answers the three vision questions of target audience, problem, and solution in greater detail. When I first engage with new team members or partner teams, I walk them through this presentation so they can quickly understand what we’re trying to accomplish. I also refine and review this at least quarterly with my own team. This helps ensure that the entire team is constantly making day-to-day decisions with our overall vision in mind.

Communicating product design
Much of your time as a product manager is spent designing product interactions with your design team and then communicating that product design to your engineering team.

When working with your design team, speed of iteration is most important. I usually start at the wireframe level to explore various information architectures and interaction flows. I then move quickly to high fidelity mockups with real user data (as opposed to lorem ipsum filler text). With high fidelity mockups you can really communicate the actual product experience which is important when designing interactions. However, given the skills of your design team, sometimes staying at the wireframe level longer enables faster iteration, which could be a valuable trade-off.

When communicating finalized product designs to your engineering team, it’s important at that point to definitely have high fidelity mockups with real user data as well as design specs that provide details on the UI as well as interaction behavior.

The level of specificity you communicate within your design specs really depends on the engineering team you are working with. I’ve worked in organizations like Microsoft where it was typical to author 30 page specifications detailing all of the interactions and error cases for the developer to implement. I’ve also worked at startups where the design specs were nothing more than the high fidelity mockups with no details beyond that. I tend to prefer a level of specificity that’s somewhat in the middle, with a bias towards lighter weight specifications. The best model I’ve seen for this is the Eric Ries model of converting the spec writing process from push to pull. The idea here is to start with a lightweight design spec, present it to the engineering team, and see what questions they ask. Then quickly iterate with them and document the discussions that come out of the process.

Communicating day-to-day execution
The vast majority of your time as a product manager is spent in day-to-day execution. This is where I’ve found it most helpful to have a formal process to ensure no small task or bug gets forgotten and to ensure effective communication of the highest priority tasks to the team.

The best way to do this is simply to use a task management tool and enforce a process around it. My personal favorite tool is Asana, as I find it an extremely lightweight way to create, assign tasks, and add additional details as necessary. We currently use JIRA at LinkedIn, which is more appropriate for larger teams where the custom filters and dashboards become more helpful. Regardless of what tool you use, the most important part is ensuring the rest of the team understands that’s where they go to find out what they need to work on, to report bugs, and to understand the team’s progress.

Beyond this, I find it's sometimes helpful to also send out weekly or monthly status emails to provide a summary of progress and more importantly to communicate how that progress fits into the larger picture of overall execution against the roadmap.

These tips should arm you with ways that you can improve your communication across the core responsibilities of vision, design, and execution.

Related Posts