At my second PM job, I prepared a 30-slide deck on our product strategy. Market analysis. User research. Prioritization framework. Competitive positioning. It took two weeks.
My CEO stopped me on slide 4. "Just tell me what we are building and when it will be ready."
I had the wrong deck for the wrong audience. The CEO did not need to understand my process. He needed to understand my conclusions and trust that the process behind them was sound. That lesson. That managing up is about translating your work into the language executives speak. Has been more valuable than any framework I have learned since. The Stakeholder Management Handbook covers this dynamic in depth across ten chapters, but the core principles below will get you started.
Why Is Managing Up So Hard?
Most executives did not come up through product management. They came through sales, engineering, finance, or operations. Each background creates a different mental model for how products should be built:
- Sales-background CEOs think in customer requests and deal sizes. They want features that close specific deals.
- Engineering-background CTOs think in architecture and elegance. They want to solve technical problems cleanly.
- Finance-background CFOs think in ROI and payback periods. They want every investment quantified.
- Operations-background COOs think in processes and efficiency. They want predictable timelines.
- Marketing-background CMOs think in narratives and positioning. They want features that tell a compelling story to the market.
None of these perspectives are wrong. But none of them are complete on their own. Your job is to bridge between the product management worldview (customer problems, outcomes, bets, iterations) and whatever worldview your executives operate in. The bridge is built with language, not authority.
Working with the Feature-Request CEO
The situation: Your CEO comes back from every customer dinner, conference, or board meeting with a list of features. "We need to build X. Customer Y said Z. Competitor A just launched B." They treat the roadmap as a feature list to be executed.
Why they do this: CEOs hear customer problems expressed as feature requests because that is how customers communicate. A customer says "I need a Gantt chart" when they mean "I need visibility into cross-team dependencies." The CEO takes the request at face value because they do not have time to unpack every request.
How to manage it:
Acknowledge the customer problem, redirect the solution. "I agree that dependency visibility is a real pain point for enterprise customers. I want to make sure we solve it the right way. Can I take two weeks to talk to five customers about this and come back with a recommendation?"
This validates the CEO's input while buying you time to do proper discovery. Most CEOs are fine with this if they trust you will actually follow through.
Create a lightweight intake process. Give the CEO a dedicated channel (a Slack channel, a shared doc, an email alias) for feature ideas. Review it weekly. Respond to every idea with a brief assessment: "Investigating," "Aligned with our Q2 plan," or "Doesn't fit our current strategy. Here's why." This prevents the CEO from feeling ignored while preventing ad hoc feature mandates.
Translate features into problems during roadmap reviews. Instead of presenting "Feature X: March delivery," present "Problem: Enterprise customers can't track cross-team dependencies. Proposed solution: Feature X. Validation: 8 of 12 interviewed customers confirmed this need. Expected impact: 15% reduction in enterprise churn." This trains the CEO to think in problems over time.
Working with the Revenue-Obsessed CFO
The situation: The CFO evaluates every product investment through a revenue lens. "What is the ROI? How many new customers will this bring? What is the payback period?" Product improvements that do not have direct revenue attribution get deprioritized.
Why they do this: CFOs are accountable to the board for financial performance. They are trained to quantify everything. Product improvements like "better onboarding" or "reduced technical debt" are hard to quantify, so they seem like poor investments compared to a feature that Sales says will close three specific deals.
How to manage it:
Learn to speak in financial terms. Do not say "we need to improve onboarding." Say "our activation rate is 28%. Industry median is 40%. Each percentage point of activation rate improvement is worth approximately $180K in annual revenue based on our current LTV. A 6-week onboarding investment with a projected 5-8 point activation lift has an estimated payback of 4 months."
You do not need these numbers to be precise. You need them to be in the right ballpark and expressed in the right units. CFOs respect back-of-envelope math presented honestly more than vague claims about "user experience."
Connect product metrics to financial outcomes. Build a simple model that links your core product metrics (activation rate, feature adoption, retention) to revenue. When you propose a product initiative, show which metric it moves and how that metric connects to the financial outcome the CFO cares about.
Use the "cost of doing nothing" frame. CFOs are loss-averse. "If we do not fix our onboarding, we will continue losing $180K per quarter in avoidable churn" is more persuasive than "If we fix onboarding, we might gain $180K." Same math, different frame.
One additional technique that works with finance-oriented executives: present your recommendations as experiments with defined budgets. "I want to invest 3 engineering weeks to test the hypothesis that simplifying onboarding will improve activation. If it does not move the metric by 5 points, we stop." This frames product work as a calculated investment, which is the language finance understands and respects.
Working with the Rewrite-Happy CTO
The situation: The CTO wants to rewrite the codebase, migrate to a new framework, or rebuild the architecture before adding any new features. They argue that technical debt is slowing the team down and that a rewrite will pay for itself in velocity.
Why they do this: They might be right. Or they might be attracted to the intellectual challenge of a clean-slate rebuild. Or they might be frustrated with the constraints of the current architecture and overestimating the cost of incremental improvement. It is your job to figure out which one.
How to manage it:
Ask for evidence, not opinions. "What specific development tasks are taking longer than they should because of the current architecture? How much longer? If we rewrote that specific component, how much time would we save per sprint?" This forces the conversation from "everything is terrible" to "here are the specific bottlenecks."
Propose the strangler fig pattern. Instead of a big-bang rewrite (which almost always takes longer than estimated and delivers less than promised), propose replacing components incrementally. "Let's identify the three modules that cause the most pain, rebuild those in the new architecture, and ship value along the way." This gives the CTO their architectural improvement while keeping the product moving.
Make the opportunity cost visible. "A 6-month rewrite means 6 months of no new features. Here is what competitors will ship in that time. Here are the deals we will lose. Here is the churn risk. Is the rewrite still worth it?" Sometimes it is. Sometimes the CTO has not thought about it in those terms.
Working with the Process-Oriented COO
The situation: The COO wants predictable delivery. They want to know exactly what will ship on exactly what date. They treat the product roadmap like a project plan with Gantt charts, milestones, and percent-complete tracking.
Why they do this: Operations leaders are trained to manage against plans. In manufacturing, logistics, and customer operations, predictability is the goal. They apply the same mindset to product development, where uncertainty is inherent and predictability is impossible to guarantee.
How to manage it:
Educate on certainty gradients. "For the next two weeks, I can give you high-confidence commitments. For the next quarter, I can give you a plan that is roughly 70% likely to hold. For the next year, I can give you themes and directions. Which level of detail do you need for your planning?"
Provide the predictability they need in the format they understand. Give them a simplified, time-based view for operational planning (capacity allocation, hiring, customer commitments) while keeping your team's working roadmap outcome-based. Two views of the same plan, adapted for different audiences.
Show them the cost of false precision. "The last three times we committed to a specific date, we missed by an average of three weeks. Each miss created customer disappointment and internal scramble. Would you rather have commitments we can actually keep or dates that look good in a spreadsheet?"
Universal Tactics for Managing Up
Regardless of executive background, these principles work:
Communicate in Their Cadence
Executives do not want to be surprised. Set up a regular update rhythm. Weekly for your direct manager, monthly for other executives. And stick to it. Include: what shipped last week, what is on track, what is at risk, what decisions you need from them.
The update should take them 3 minutes to read. If it takes longer, you are including too much detail.
Give Them Decisions, Not Updates
Executives are drowning in information. What they lack is not data. It is framed decisions. Instead of "here are three options," say "here are three options, here is my recommendation and why, here is what I need from you to proceed."
Manage up to the stakeholder management principles that apply to any audience: understand their goals, communicate in their language, and make it easy for them to say yes.
Build a Trust Account
Every accurate prediction, every honest status update, and every time you flag a risk before it becomes a crisis adds to your trust account. Every missed deadline, every surprise, and every time they hear about a problem from someone other than you makes a withdrawal.
The trust account is what lets you push back on bad ideas, take risks on uncertain bets, and ask for resources without a 40-slide business case. Build it deliberately.
Know When to Disagree and Commit
Sometimes, after you have made your case with data and logic, the executive still disagrees. At that point, you have a choice: escalate further, disagree and comply grudgingly, or disagree and commit fully.
The third option is usually right. Voice your disagreement clearly. Document it if needed. Then commit. As Amazon's leadership principles put it, "disagree and commit". To making the executive's decision succeed. Do not sandbag it. Do not say "I told you so" if it fails. If the decision turns out to be wrong, the evidence will make the case for you.
The Pre-Meeting Meeting
The most effective managing-up technique I have learned is simple: never let an executive be surprised in a group setting. Before any meeting where a decision will be made or a controversial topic will be discussed, brief the relevant executives individually. Share your recommendation. Hear their concerns. Address objections privately.
By the time the meeting happens, the decision is essentially made. The meeting becomes a ratification ceremony rather than a debate. This is not political maneuvering. It is ensuring that the people who need to make decisions have the context and preparation to make good ones.
The PMs who consistently get their recommendations approved are rarely the ones with the best slide decks. They are the ones who did the hallway conversations beforehand.
How Do You Know If You Are Managing Up Poorly?
A few signals that your executive relationships need attention:
- You are always surprised by executive decisions. This means you are out of the loop. Increase your communication frequency.
- Executives micromanage your product decisions. This means they do not trust your judgment. Rebuild trust by being more transparent about your process and more accurate in your predictions. Start by nailing three small commitments perfectly. That builds more trust than one big win.
- Your roadmap gets overridden regularly. This means you are not aligning early enough. Share your thinking earlier in the process, when it is still moldable. By the time a roadmap reaches a formal review, the decisions should already be pre-validated with key stakeholders.
- You hear about executive concerns secondhand. This means your communication channels are broken. Establish direct lines and use them proactively.
Each of these symptoms has the same root cause: insufficient communication. The fix is always more conversation, earlier, with better framing. Much of managing up comes down to writing. PRDs, stakeholder emails, strategy docs, and Slack messages that actually move things forward. If that is a weak spot, see the PM writing skills gap for practical techniques.
One more signal: if you find yourself complaining about executives to your peers more than communicating with executives directly, you have a managing-up problem. The energy you spend on frustration is better spent on building the relationship that would resolve the frustration.
The Long Game
Managing up is not a tactic. It is a relationship. The PMs who do it well invest in understanding their executives as people. Their fears, their incentives, their communication preferences, their decision-making patterns. Over time, this understanding lets you anticipate their reactions, pre-address their concerns, and influence their thinking before the meeting even starts.
The goal is not to manipulate. It is to translate. You are the bridge between the messy reality of product development and the clean narratives that executives need to do their jobs. The better you are at that translation, the more freedom you will have to do yours.
The PMs who master this skill are not the ones who complain about executives "not getting it." They are the ones who accept that translation is part of the job and invest in getting good at it. Product management sits at the intersection of every function in the company. Managing up. Managing across, really. Is not a distraction from the work. It is the work.
Start by understanding one executive better this week. Learn what they care about. Learn how they make decisions. Then translate your next product recommendation into their language. The difference in reception will be immediate and obvious.