Stop calling product managers “CEOs of the product”

Saying “CEO of the product” sounds a lot sexier than “product manager,” doesn’t it? For better or for worse, this is the most popular (and most damaging) metaphor in product management.

A real CEO has budgetary power, a deep network, and years of cross-functional experience. They decide when and who to hire and fire. When a CEO says “we’re not doing that,” it stops. When a PM says it, they get a calendar invite from a senior stakeholder three days later.

So, why do so many PMs convince themselves they’re the CEO of the product? On the surface, it makes sense. You own the vision. You align cross-functional teams. You make hard trade-offs between what customers want, what the business needs, and what engineering can actually build.

However, more often than not, it creates unrealistic expectations and dysfunction that leads to burnout. The “CEO of the product” title sets you up to be blamed for outcomes you don’t control, while giving you none of the tools to actually control them. And it quietly lets everyone else in the organization off the hook.

To be clear, I’m not throwing shade on product managers. My beef is with this metaphor, which doesn’t just misrepresent the role — it actively undermines the people in it. Let’s examine why.

Where the “CEO of the Product” idea came from

Roughly a century ago, before digital products were conceived, Neil H. McElroy at Procter & Gamble (P&G) advocated for a “brand man” responsible for individual product success, including sales, advertising, and improvements, which led to the creation of business units aligned to brands at P&G, each with their own leaders responsible for profit and loss (P/L). This was the dawn of “product management.”

When Ben Horowitz and David Weiden wrote the “Good Product Manager / Bad Product Manager” post in 1998, they had the right intentions: elevate the function, build accountability into the role, and push PMs to think like founders. They defined PMs as the “CEO of the product,” fully accountable for success.

The concept spread, because it sounded like a promotion. It signaled that product management matters, that PMs weren’t just glorified project managers taking meeting minutes or “gophers” for engineering. Framing PMs in the lens of a CEO gave the function status at a time when it desperately needed it.

Even today, I get the appeal. I recently wrote an article about how I believe product management is the most misunderstood job function in modern history. With so much ambiguity around the role, it’s easy to inflate your importance because, after all, you’re trying to prove yourself and what it means to be a PM to everyone around you who has no real idea.

It’s equally easy to allow yourself to soften your boundaries so much you become the dumping ground for everyone else’s excuses. Unfortunately, this leads to burnout, and it’s all preventable if we reassess why the “CEO of the product” may have worked then (in the dot-com era, when small, scrappy teams consisted of founders who were also the PMs), but not now in the enterprise or scale-up environments where most PMs work today.

Why the metaphor breaks down in practice

Now, let’s get into why the metaphor has lost some of its staying power by examining some of its key shortcomings.

PMs have accountability without authority

Let’s be precise about what a CEO actually has: formal authority. The power to hire, fire, reallocate budget, and restructure teams. The organizational right to make a final call.

---

---

What do most PMs have? A Jira board, a roadmap that gets second-guessed in every quarterly planning cycle, and the power of persuasion.

The gap between those two things is where the metaphor falls apart. CEOs command. PMs influence.

That’s not a knock on PMs. Influence is a legitimate and powerful form of leadership, but calling it “CEO authority” doesn’t make it so, and more importantly, it sets up a false equivalence that almost always hurts the PM.

You can’t hold someone accountable to outcomes they can’t structurally control, and setting them up for failure is a quick way to find yourself with unusually high turnover.

The CEO framing inflates PM accountability

When you position yourself as the CEO of the product, you inherit an unspoken agreement: if something goes wrong, it’s yours to own.

Missed adoption targets? Product’s fault. Feature shipped late? Product dropped the ball. Engineering decided to rebuild the authentication layer mid-sprint and the timeline blew up? Somehow, it’s still the product’s problem.

What I’ve seen (and lived) is that the “CEO” framing turns the PM into an organizational escalation sponge. Everyone’s dysfunction lands on your desk, labeled as a product problem, and you’re expected to absorb it without pushing back.

Saying, “this is a resourcing decision, not a prioritization one” feels like shirking responsibility, or you get called defensive or told to be creative with less resources. So instead, you try to solve the unsolvable, take one for the team, and you burn out in the process.

The damage spreads across the whole product team

The dysfunction doesn’t stop with the PM. When the product absorbs all accountability, it quietly demotivates everyone else.

Engineers stop owning delivery outcomes because “the product will handle it.” Designers get sidelined from strategic conversations because they’re seen as executors, not decision-makers. Stakeholders learn to request features instead of defining outcomes because the PM is supposed to orchestrate the rest.

The whole team becomes less capable because one person is doing what a CEO would do: trying to be the single source of answers, decisions, and blame. It’s a single point of failure with a compelling job title.

A better product management metaphor: The chief context officer

Instead of slowly bleeding to death with a vanity title and no real authority, how about a different concept: The chief context officer (CCO)?

Your job isn’t to have all the answers or to command the room. It’s to create shared understanding so that engineers, designers, and stakeholders can make better decisions themselves without you becoming a bottleneck.

You’re already a natural collaborator. Bring people together, share insights, then foster shared accountability among the team.

Great news: You already have all the skillsets needed to shine as a chief context officer. It requires the following capabilities:

• Synthesizing customer insight — You don’t own the customer relationship exclusively, but you do synthesize what you know about user behavior, pain points, and unmet needs into a form the team can act on. Not just “here’s what customers want,” but “here’s what the data tells us and what that implies for our trade-offs”
• Translating business constraints — You help the team understand the business context. You translate revenue targets, competitive pressure, regulatory requirements, technical debt, client politics, demands, and more from executive-speak into information that shapes daily decisions
• Clarifying trade-offs — Instead of declaring what the product will do, your job is to make the options and their trade-offs visible and explicit. Presenting options with corresponding pros/cons supports an eventual recommendation with a paper trail. It’s about giving the team what they need to align, then backing them up
• Facilitating decision clarity — You aren’t the decision-maker in every room. You’re often the person making sure a decision actually gets made by the right people, with the right information, at the right time

These capabilities involve highly operational work that determines whether a team moves with confidence or spins in circles.

How to act like a chief context officer

Making the shift from CEO of the product to chief context officer starts with reframing your daily work:

Start with the problem, not the requested solution

Stakeholders often come to PMs with solutions, not problems. It’s almost always “we need a button here” or “can we add a filter to this table?” The CCO’s job is to rewind from solution to problem. Do this every time, without apology.

Here’s what that sounds like in practice:

Stakeholder: “We need a new dashboard for the sales team.”

PM response:

• “What decision is the sales team trying to make that they currently can’t? Where do current tools fall short?”
• “What would they do differently if they had this dashboard?”
• “What data do we have that this is the actual blocker?”

You’re not rejecting the request. You’re redirecting it upstream before the solution gets baked in, so that whatever gets built actually solves something.

Need more on this? See the 5 Whys methodology.

Another example:

Stakeholder: “Can we add a notification when users haven’t logged in for 30 days?”

PM response:

• “What behavior are we trying to change with this?”
• “Do we know why users disengage? Is it a habit problem, a value problem, or a technical friction point?”
• “What does re-engagement look like for us, and what’s driven it in the past?”

To the wrong observer, this might sound like defensive questioning, but it’s exactly the CCO’s job to gather this context and justify the work before engineering writes a line of code.

Make trade-offs visible before making recommendations

Every time you say “yes” to something, you’re inherently saying “no” to something else, assuming you have limited resources: time, money, or people.

Before presenting a recommendation, present options along with pros and cons. This creates a paper trail, demonstrates your thought process, and allows others to consider the options asynchronously, which is how some people work best.

In a product requirements document (PRD) or brief, that might look like:

• Option A: Build the full feature set in Q3. Pros: Covers 80 percent of user needs. Cons: Delays two roadmap items by six weeks
• Option B: Ship a lightweight version in Q3 and iterate in Q4. Pros: Faster learning, less roadmap disruption. Cons: Partial coverage may not move the adoption metric.

This framing shifts the conversation from “what does Product think we should do?” to “here’s what we know. What does the team want to optimize for?” That’s the chief context officer at work.

---

---

Set boundaries without losing trust

The hardest part of dropping the CEO myth isn’t the reframe to CCO, it’s that people will still try to hand you problems that aren’t yours to solve. The key is naming that clearly, without abandoning ownership of what actually is yours.

Here’s the language I use:

• When a problem is really a resourcing decision — “This is a staffing constraint that needs an executive call, not a prioritization call on my end. I can document the trade-offs and frame the options, but the decision needs to happen above my pay grade”
• When alignment hasn’t happened upstream — “Before Product can move forward on this, we need agreement between legal and finance on the approach. I can facilitate that conversation, but we shouldn’t start building until we have it”

Instead of refusing responsibility, you’re naming who actually owns what, and making sure the right people are in the room to take ownership and drive the decision forward.

What changes when PMs stop acting like CEOs

When PMs stop positioning themselves as CEOs, something shifts across the whole team. Engineers start taking ownership of delivery outcomes because there’s no single PM superhero absorbing every risk. Designers get pulled into strategy conversations earlier because the PM isn’t the sole gatekeeper of context.

Stakeholders learn to bring problems instead of features because they’ve been patiently and repeatedly redirected to think that way. Decisions get made faster because there’s a clear shared understanding of who decides what.

The PM also gets to breathe. Not because the job gets easier, but because the scope becomes honest. You’re no longer responsible for outcomes you can’t control. You’re responsible for the clarity that makes good outcomes possible.

That’s a meaningful distinction, and it matters for long-term sustainability in a role that, frankly, burns people out at alarming rates.

Influence beats authority

What great CPOs and PMs actually do is synthesize customer data, business goals, and technical constraints so engineers, designers, stakeholders, and leadership can make better decisions.

The best PMs I’ve worked with act like the most well-informed person in the room, but don’t act like CEOs. They use that information to make everyone around them sharper. They design decision environments.

This creates a more accurate, more sustainable, and ultimately more powerful role for you. The sooner we retire the CEO metaphor, the sooner we can build product teams that don’t depend on a single person pretending to have authority they don’t have and burning out trying to live up to it.

Featured image source: IconScout