Getting to Effective Stakeholder Communication

Last week was the fourth session of First Round’s Product Program. The discussion was led by Melody Koh (former Head of Product at Blue Apron) and Alexandria Stried (Head of Product at Ellevest). The duo shared Dos and Don’ts for helping PMs learn to master communication and collaboration with the people they work with most often.

As product managers, we’re tasked with being multilingual. Not in the sense of speaking multiple languages, but in the know-and-be-able-to-translate-key-jargon-from-engineering-code-bases-to-synthesizing-legal-contracts-to-deciphering-marketing-a/b-test-results kind of speaking. This is the type of communication product managers must have as a core skill. It’s the kind of speaking that enables us to effectively corral, influence, and work across an organization to drive product enhancements.

The session focused on communicating and collaborating with the four main functions we interact with all the time: senior leadership, our own teams, key cross-functional stakeholders, and our customers. Read on to learn what we learned from these two awesome leaders in the space.

1. Communicating with Executives and Leadership

Typically at the point when senior management is involved, you’re working on something high-profile. So how do you bring an already time-deprived group up-to-speed on progress? How do you communicate that a launch won’t go as planned? How do you meet with an opinionated group to review designs in a productive (non-disruptive) way?

Do

• Send presentations, decks, and other materials before a meeting. Don’t assume anyone reviews the info before your chat, but it’s good to reference. Bonus: Try pre-printing materials and allow the group 5 minutes to silently review in the meeting.
• Know the facts and own your metrics. Be data driven. Validate decisions by including user testing videos or quotes. Show that you’ve thought through all possible outcomes.
• Be specific about meeting goals and dictate how you’d like their participation. Set limitations. E.g. “This is a go/no-go decision meeting for the functionality of feature X. We’ll be putting design suggestions in the ‘parking lot’ and saving them for future testing.”
• Take notes and close the loop. If someone asks for a follow-up, make sure you do it.
• Proactively send high level updates after the meeting. This can be as simple as status updates with red/yellow/green status, due dates, and blockers.

Don’t

• Provide your audience with too much detail. Make sure you prioritize what you need them to know to make key decisions. The C-Suite thinks about the business as a whole. When creating your presentation, focus on how your product fits into their business objectives.
• Surprise the audience with bad news. If you do, expect to be pummeled with questions. To avoid this, reach out to attendees 1:1 beforehand with the bad news and use the group meeting to come to a resolution.
• Waste their time by not being prepared. This should be self-explanatory. Never think you can just wing it.
• Ignore the dynamics in the room. Watch people’s reactions and adjust accordingly. If someone is confused or irritated, make sure you address that to bring clarity and defuse tension. If necessary, change your tone, speed up the presentation, or ask questions based on what you’re seeing.

2. Communicating with Your Team

As a PM you likely touch basis with your core team at least once a day. These are the people you sit next to, you each lunch with, and who you formally meet with at least once a week to share status and solve problems. However, things can still slip through the cracks. How do you hold the team accountable when mutually agreed upon requests aren’t met? How do you maintain your PM role and not go full throttle project manager?

Do

• Leverage effective/efficient stand-ups. This is nudging time. Enable everyone to project manage and call out outstanding action items. Invite non-engineers to do the same.
• Review strategy and roadmaps on a regular basis. Provide context on why changes happen and be sure to include new data points as the business pivots.
• Take responsibility for recording and sending notes on key decisions and action items. If you don’t, no one else will. This also fosters team alignment.
• Proactively facilitate communication among your team to remove blockers. E.g. If you ask “Why is this feature stalled?” and no one answers, become the facilitator. Sit everyone down to figure out dependencies and a path forward.
• Motivate team members by bringing them along. Invite teammates to meetings that demonstrate the impact of their work. Showcasing product performance or customer pain points will also help them understand why you’re building what you’re building.

Don’t

• Make product decisions in silos without engineering or design. Everyone in the product development cycle has ownership in the product. An autonomous decision can have a big ripple effect so constantly communicate all decisions that have been made.
• Send action items/requests through your project management tool without talking to the assignee first. Instead, send a quick direct message or give a heads up in standup to make requests personable and less rude.
• Treat engineers and designers as if they’re your subordinates. They are partners. You should ask their opinions and make sure their voice is heard because they often have good ideas and solutions to problems.
• Forget to update your team on changes to product specs/roadmap after meeting with stakeholders and leadership. Let the team know why changes are made. That context will help keep team alignment.

3. Communicating with Stakeholders

I view each stakeholder I work with as a spoke in the wheel of the product development lifecycle. Stakeholders can include internal teams like finance, legal, etc., or external parties like brand partners. Each is necessary in their own way, but some of them often have changing needs. It’s the product manager’s responsibility to assess these changes and establish a path forward. When change requests happen, how do you manage discussions to negotiate and minimize the change? How do you take this info back to engineering?

Do

• Exhibit you have a basic understanding of their work and domain and be able to empathize. This is part of being able to “speak” various languages.
• Apply the right format at the right time with the right audience. Anticipate varying discussion dynamics and potential tensions and adjust meetings accordingly. This is leadership management.
• Leverage your teammates when the time is right. Bring your engineering lead to meetings to discuss consequences of a change.
• Constantly educate stakeholders. Stakeholders often don’t know the consequences of their actions, so make them aware. Let them know why interrupting a sprint is bad.
• Build relationships outside of work meetings. Meet 1:1 regularly to build rapport.
• Create transparency. Don’t assume communication channels are fluid across the organization. Make all product updates and roadmaps available to the whole company to reduce friction.

Don’t

• Forget to loop in critical stakeholders at the right stage. Ask yourself who is invested in what part of the product and make a list of specific teams to reach out to before major work is started. E.g. If you’re shipping goods to a new state, you could trigger sales tax, so finance should be involved.
• Make stakeholders feel like you’ve ignored their concerns/opinions and forget to explain your next steps. Even if you decide to disregard their feedback or go another way, be sure to follow up with them once the decision is made with a detailed explanation.
• Forget stakeholders don’t know how roadmap decisions are made and priorities determined. Don’t assume knowledge. Always err on the side of over-communication and over-education.
• Allow people to walk out of a meeting with different understandings of decisions and next steps. At the end of meetings, state the primary conclusions and action items that you recorded and make sure everyone is in agreement with your same list.
• Forget to educate stakeholders on timelines and tradeoffs. Don’t wait for them to ask for it, proactively provide this information. Whenever changes are made to a timeline, make sure it’s communicated to all stakeholders.

4. Communicating with Customers

Last, but not least, as a PM you should master speaking to customers and those who champion them and their needs at your company (Customer Success, Sales, etc). Thinking critically about and looking for gaps in the customer experience is key for a PM. Customers’ ultimate needs and wants represent the North Star, so as a PM, how do you make sure the product you’re building makes the most impact?

Do

• Always start with the user problem and think about the ‘why’. Don’t just observe that the pain point exists. Know the user journey and all of the context around it that creates or supports the problem.
• Research and learn which benefits are most important to the customer. Rely on user studies and learnings and reiterate them to marketing and other teams involved.
• Treat email copy as part of the product experience. It’s usually the first touchpoint into your product for most customers, so it’s super important.
• Empathize with your customers. Read through user feedback. Attend user studies. Shadow the Customer Success or Sales team. Test the ins and outs of the product yourself. This will help you understand user needs and user behaviors.

Don’t

• Leave determining product communications/messaging until right before launch. Defining messaging can be as hard as defining the product itself. Start with this, don’t end with it.
• Assume marketing will figure out how to position the product to users themselves. Marketing is responsible for solidifying and amplifying the message, but as a PM you are to pass the learnings from testing and prototyping. You have to be actively involved in this process.
• Leave the Customer Success team in the dark when a launch is happening. They are on the front lines and need to understand the product before they can address users.
• Think there’s no need for a rollout strategy because it’s an internal product. Internal users are real users. Don’t assume you can release software and they’ll know how to use it. Invest in the relationship by training them.

Long story short: Product managers need to be prepared…in every way. Well versed, emotionally intelligent, proactive, meticulous, unassuming, able to translate… the list go on.

During our session, Melody pointed out that when communicating with executive teams, we as PMs need to have done our diligence, thought through all possible solutions, and have our decision making framework down pat to showcase our process and to explain progress (or lack thereof). But in my experience, this applies to all stakeholders. If you’re able to thoroughly communicate and reason with your CEO, then that same diligence applies to your team, cross-functional stakeholders, customers and their advocates.

You can learn more about the First Round Product Program here. Stay tuned for more posts.