How to Overcommunicate: A Guide for Product Leaders

When working in person, there are plenty of subtle cues that we give or observe about our colleagues without even trying. From brief interactions in the elevator and common areas, you start to get a sense of whether someone is an early bird or a night owl and if they are more productive when they collaborate or work alone. You even begin to perceive whether someone has a high-risk tolerance, moving fast and iterating, or is low-risk and methodical, preferring to get it right the first time.

Working remotely, we don’t always get organic opportunities to intuit working styles. And when working in person, what if you’re not great at reading people’s signals? The answer is to go the extra mile to overcommunicate, best done by using tools that keep your team accountable and get those subtle cues down on paper. Here are four techniques that I find invaluable to set up product teams to do their best work.

#1 Define the product objectives

First, communicate the product vision so that everyone on your team knows what the product’s and the team’s goals are. They need to be SMART goals (specific, measurable, achievable, relevant, time-bound) and related to each person’s role. Setting the product objectives can be as simple as running through the five W’s (and one How) with your team:

What exactly do we want to achieve?
Why do we want to do this? What is at stake if we fail or if we succeed?
When do we want to achieve this?
Who is this product for?
Where do we want to make an impact?
How might we do that?

There will inevitably be differences of opinion. Conflicts at this stage are an absolute blessing. It allows the team to identify differences and resolve them early on. You’d be surprised how many product managers skip this critical step, moving past the purpose of the work as if it were obvious. If you haven’t had this foundational conversation with your team, then you haven’t over-communicated.

#2 Define your team’s way of working

When forming a team, we often forget to ask: How and when do you like to work? Everyone’s rhythms and circumstances are different. For example, sometimes my brain doesn’t turn on until 10am. I have a fairly productive mid-day, a late afternoon slump, and then a burst of energy from 5pm-8pm where I feel I do my best work. Some people have childcare in the afternoons and evenings, hop back online after dinner, and work until late in the night. You never know what people prefer until you ask.

At the beginning of a project, I make time in 1-1s or in a group session to ask every team member the following questions:

Working hours: What are your preferred working hours? What is your preferred schedule for meetings?
Communication platforms: What is the best way to reach you? Do you like email, Slack, or texts? Does this change at different times of the day? How quickly should we expect you to respond?
Time off: Do you have any time off coming up?
Obligations: Do you have any personal, family, or other commitments you’d like us to know about?
Video or no video?: This question can split the room, but some people get burned out fast seeing themselves on a screen, while others may be energized by seeing each other’s faces.

Then, we discuss regular and occasional meetings. It’s important to know whether your team prefers to have time to breathe between meetings or stack them, so they get longer blocks of time to themselves. I never schedule recurring meetings without understanding what the team’s preferences are. I try my best to accommodate everyone’s needs and give people reasons when I am unable to honor their requests.

Making sure that meetings work for the group creates greater buy-in, attendance, and participation. Once the meetings are set, people won’t think very much about making time to connect — it will just happen.

#3 Create a RACI or a DRACI analysis

This analysis is about uncovering hidden stakeholders and making roles and relationships clearer. Often the team intuits this context, but making these relationships explicit from the outset leaves no question about whom team members should include in what work. RACI is an acronym that stands for:

Responsible: Person(s) responsible for completing specific tasks. Any work assigned to the team must have at least one primary owner.
Accountable: An accountable team member may oversee or delegate work. They must ensure the completion of specific tasks.
Consulted: These stakeholders must be consulted when working on or completing a task. They may be an expert in the field or a higher-level manager who issues approvals.
Informed: These team members should be informed about general progress, but they do not need to be involved in daily work.

Make a list of stakeholders and the tasks to be done. Then, create a matrix that is specific and accessible to the team and update it as necessary. Here is a simple example RACI analysis for a lean software team:

If you need even more clarity, add one more dynamic to turn your RACI analysis into a DRACI analysis by adding the 5th role of “Decider.” This stakeholder has the ultimate decision-making power. Others may be responsible for planning and completing work, but the Decider has the final say in what is acceptable.

It is advisable to only have one Decider for each track of work. The Decider may choose to solicit feedback from the group in their decisions, but ultimately what they say goes. In the case of working with a non-technical client, our DRACI structure often looks like this:

Adding the Decider role often allows the team to move forward much faster. It makes explicit to the client, for example, that they have to remain engaged enough to make important decisions but also delineates where domain experts should drive other steps in the process.

#4 Align on sources of truth

Finally, it’s important to get on the same page about how to store documentation (see what I did there?) and where everyone can find their “sources of truth” in a fast-moving project.

Plans for digital products can evolve quickly. In addition, product teams store different tracks of work in varying formats and applications. For example:

Product Requirements Document: The source of truth for the up-to-date product roadmap is often referred to as the “PRD.” This document captures the requirements and scope of a product, often in a place where it can be updated live such as in Google Docs or a word document in Dropbox.
Design Prototypes: The source of truth for up-to-date product designs will often be a special design file stored in a program like Figma, Sketch, or Invision or images stored in a designated folder.
Stories or Tickets: The source of truth for current development tasks will often be the stories or tickets on a project tracking board such as Shortcut or JIRA.
Meeting Minutes: The source of truth for up-to-date decisions may be in the most recent meeting minutes. Make sure these are emailed out or stored somewhere that everyone can access them, and name any action items and their owners following meetings to keep everyone accountable to their deliverables to the team.

No matter where your documentation lives, make sure that everyone knows where to find them and the difference between the “work in progress” versions of documentation and the agreed-upon “sources of truth” as the project evolves. Doing so reduces confusion and helps with communication outside of the team, especially when Consulting with and Informing stakeholders around the organization, per your RACI analysis.

Embrace the overkill

Making use of these techniques can feel like overkill until they become the norm. Overcoming the awkwardness of asking people for their preferences at the early stages of a team will save countless hours of confusion and frustration later in the project. Treating everyone as an individual will boost the team’s morale, and helps you meet people where they are rather than relying on assumptions.

No one system or framework is a silver bullet, but I believe the above structures foster communicative, collaborative teams and set the stage for higher quality work outside of meetings. Make sure to check in occasionally to see if current systems are working for everyone, and give yourself the creative freedom to adjust course when necessary. Good luck overcommunicating!

Sarah Cassidy (she/her) is a Product Manager at Postlight. Interested in working on your product? Get in touch.

Work for Postlight! Love making exceptional digital products? We’re hiring engineers, PMs, designers, and strategists. Let’s grow together. See openings.