Nobody Gets Fired for Bad Roadmaps
They get fired for bad communication. The PM who ships a mediocre feature but keeps stakeholders aligned, informed, and trusting survives. The PM who ships a brilliant feature while blindsiding the sales team, surprising the CEO, and frustrating engineering does not. As Rich Mironov puts it, product management is mostly a communication job that occasionally involves product decisions.
Stakeholder management shows up in every PM job description. But the actual skill of communicating with people who have different incentives, different context levels, and different definitions of success? That gets learned the hard way, through painful meetings and awkward Slack threads.
Here is what works. Organized by direction: communicating up to executives, across to peers, and down to your reports.
Communicating Up: Executives and Leadership
What executives actually want
Executives want three things from their PMs:
- Confidence that the team is working on the right things. Not a feature list. A clear connection between the work and the business outcomes they care about.
- Early warning when things go wrong. Not when things have already gone wrong. When you see a risk forming.
- Decisions, not options. They want your recommendation. "Here are three options, what do you think?" is the fastest way to lose credibility with a VP. "I recommend option B, here's why, here's the risk" earns trust.
The status update that works
Most status updates are useless. They list tasks completed and tasks planned. Nobody reads these. Here is the format that actually gets read:
One sentence summary. What is the headline? "On track for March 15 launch" or "Blocked: API partner delayed by 2 weeks, need to discuss Plan B."
Three bullets max. What progressed? What is at risk? What do you need from them?
No surprises. If the executive will hear about a problem from someone else before they hear it from you, you have failed. The worst version of this: a customer escalation reaches the CEO, who turns to the VP, who turns to you, and you say "yeah, I knew about that."
Saying no to your boss's pet feature
Every PM eventually faces the CEO or VP who has a feature idea they love. Here is how to handle it without career damage.
Acknowledge the insight, not the solution. "That is an interesting observation about our enterprise users struggling with onboarding. Let me look at the data and come back with options." You are validating their observation (they probably saw something real) without committing to their specific solution.
Bring data, not opinions. "I looked into this. Here are the top 5 onboarding issues by support ticket volume. Your suggestion addresses issue 4. I think we should tackle issue 1 first because it affects 3x more users. Here is my proposed approach." You are not saying no. You are redirecting with evidence. Use the RICE calculator to score both their suggestion and your alternative side by side. Numbers are harder to argue with than opinions.
Give them a timeline, not a rejection. "I agree this matters. Based on our current priorities, the earliest we could start this is Q3. If you want it sooner, here is what we would need to deprioritize." This puts the trade-off decision back on them, which is where it belongs.
Communicating Across: Peers in Engineering, Design, and Sales
Engineering
The biggest communication failure between PMs and engineers is not about features or requirements. It is about trust. Engineers want to know: does this PM respect my expertise? Or do they see me as a code-producing resource?
Stop saying "just." "Can we just add a toggle for that?" "Can we just cache this response?" The word "just" implies simplicity, and it tells the engineer you have not thought about the implementation complexity. Intercom's product team identified this word as one of the fastest ways to erode PM-engineering trust. Replace "just" with "I'm not sure about the effort here. What would it take to..."
Share the "why" before the "what." Engineers who understand the user problem make better implementation decisions than engineers who are given a feature specification. Start with the problem. Let them propose the solution. The Technical PM Handbook covers this dynamic in depth: how to collaborate with engineering without overstepping.
Protect their time. If you are pulling engineers into meetings they do not need to attend, they will stop trusting your judgment about what is important. Be ruthless about meeting invitations. The general rule: engineers should attend planning and review meetings. They should not attend stakeholder updates, sales calls, or "alignment" meetings unless they specifically need to be there.
Design
Designers and PMs share a boundary that is perpetually fuzzy. Where does product strategy end and UX design begin? The answer depends on the team, but the communication principle is constant: the PM owns the problem and the constraints. The designer owns the solution within those constraints.
Write a clear creative brief. Before kicking off design work, write a one-page brief: the user problem, the success metrics, the technical constraints, and any non-negotiable business requirements. This is not a PRD. It is a framing document that gives the designer enough context to explore solutions without going in a direction that is technically infeasible or strategically misaligned.
Critique designs on problem-fit, not aesthetics. "I'm not sure users will find the save button in that location" is useful feedback. "I don't like the blue" is not. If you find yourself giving aesthetic feedback, ask yourself whether you are crossing into the designer's expertise.
Sales
The PM-Sales relationship is the most misunderstood in the organization. Sales teams have urgent customer requests. PMs have a roadmap. These two things are perpetually in tension.
Create a simple intake process. Give sales a form or a Slack channel where they can submit feature requests with context: which customer, how much revenue at stake, what the customer said verbatim (not the sales rep's interpretation). Without an intake process, requests come via DM, email, hallway conversations, and escalations to your boss.
Communicate what you heard, not just what you decided. When you review sales requests and prioritize against the roadmap, close the loop. "I reviewed the 12 requests from last month. Three are already on the roadmap for Q2. Four are out of scope for now, here's why. Five need more customer validation before we commit." Sales teams that feel heard are far more cooperative than sales teams that feel ignored.
Communicating Down: Your Reports and Your Team
If you manage other PMs or lead a product team, your communication shifts from "keeping people informed" to "creating clarity so people can make their own decisions."
The one-on-one that is not a status update
One-on-ones are not for status updates. That is what standup and Slack are for. One-on-ones are for the things people do not say in group settings: concerns about team dynamics, career frustrations, confusion about strategy, or ideas that are not fully formed enough to share publicly.
Ask better questions. "How's it going?" produces "fine." Try: "What is the hardest decision you are facing this week?" or "Where are you spending time that feels wasted?" or "What would you do differently if you were in my role?" Use a structured one-on-one template if you find your conversations drifting into task management.
State your reasoning, not just your conclusions. When you make a decision that affects your team, explain your reasoning. "We are deprioritizing feature X" is a conclusion. "We are deprioritizing feature X because our churn analysis shows that the users who leave are not asking for X. They are leaving because of reliability issues, which is why we are investing in stability this quarter." The reasoning gives your team the mental model to make aligned decisions when you are not in the room.
The RACI trap
RACI matrices (Responsible, Accountable, Consulted, Informed) are popular in larger organizations. They solve a real problem: unclear ownership causes dropped balls. But they create a new problem: rigidity.
When every decision needs to be routed through a RACI chart, speed drops. People check the chart instead of using judgment. The edge cases (the decisions that do not fit neatly into any row of the matrix) pile up because nobody is "Responsible" for them.
A better approach: define the 5-10 most important recurring decisions for your team. For each one, name one person who makes the call and one person who can veto. Everything else, default to the person closest to the problem. Document this in a single page, not a giant matrix.
Async vs. Sync: Choosing the Right Channel
The rise of remote and hybrid work has made channel selection a communication skill in its own right. The wrong channel ruins the right message.
| Communication type | Best channel | Worst channel |
|---|---|---|
| Status updates | Written async (Slack, email, doc) | Meetings |
| Bad news or conflict | Live conversation (video or in-person) | Slack DMs |
| Complex trade-off decisions | Live meeting with pre-read doc | Email thread |
| FYIs and announcements | Written async with explicit "no response needed" | Meetings |
| Design reviews | Live meeting with shared screen | Async comments |
The pre-read principle. For any decision-making meeting, send the relevant document 24 hours in advance. Label it "pre-read." If people show up without reading it, spend the first 5 minutes in silent reading (Amazon's "study hall" approach works). Do not waste 30 minutes of meeting time presenting information that could have been read in 5 minutes.
When to write a doc vs. schedule a meeting
Write a doc when:
- The information does not require real-time discussion
- You need people to absorb details before responding
- The stakeholders are in different time zones
- You want a written record of decisions
Schedule a meeting when:
- There is genuine disagreement that needs resolution
- The topic requires back-and-forth negotiation
- Emotional tone matters (delivering bad news, resolving conflict)
- You need to build alignment across teams that do not often interact
The Product Strategy Handbook covers how to structure strategic communication with executives who need to approve or fund your initiatives. If you are presenting roadmap decisions to leadership, that handbook has specific frameworks for structuring those conversations.
Managing Conflicting Priorities
The hardest communication challenge for PMs is not saying no. It is managing the situation where three stakeholders each believe their priority is the most important, and they are all partially right.
Make the trade-off visible. Create a simple two-column table: "If we do X, we get [benefit] but we delay [other thing]." Share this table with all three stakeholders simultaneously. Do not have separate conversations where each person hears a different version.
Escalate early, escalate clearly. If you cannot resolve a priority conflict at your level, escalate. But escalate well. "Sarah (VP Sales) wants us to build enterprise SSO by March. James (VP Eng) says the infrastructure work needs to happen first and SSO is June at the earliest. I recommend we follow James's timeline because the infrastructure work unblocks three other teams. I need you (CPO) to make the call and communicate it to Sarah."
Do not try to make everyone happy. You will fail, and the attempt will make you less credible. Make the best decision you can, explain your reasoning, and accept that someone will be disappointed. The PM who tries to please everyone pleases no one.