Is the Product Manager the CEO of the Product? - ProductFTW #91

Programming Note

The Totavi product and engineering team will be at Fintech Devcon next week. We hope to see some of you there, especially for Ellen's talk on instant payments. We'll be taking next week off due to travel and will be back the following week.

Product Manager Responsibilities and Accountability

A couple of weeks ago, Zach wrote From Product Tripod to Pogo Stick about how AI is changing the traditional relationship between product, design, and engineering. His argument was that AI is making each discipline more capable on its own, allowing individuals to do work that previously required another member of the team. I think he's largely right. Product managers can generate prototypes in minutes. Engineers can create UI mockups without opening a design tool. Designers can build working applications instead of static concepts. The lines between roles are becoming less rigid than they were even a few years ago.

That discussion got me thinking about another phrase that has been repeated for years: that the product manager is the "CEO of the product." I've worked as both a product manager and a CEO over the past twenty years, and I've never been particularly fond of the comparison. I talked about this a bit last year during our Product Talks series. The analogy sounds good, but it falls apart once you think about what CEOs are actually responsible for.

A CEO hires executives, raises capital, makes payroll, sets company strategy, approves budgets, manages a board, and ultimately carries responsibility for the success or failure of an entire business. Product managers don't have those responsibilities, nor do they have the authority that comes with them. Most PMs cannot hire or fire members of their team, decide how much engineering capacity they receive, or control the marketing budget. Only some organizations give product managers direct profit and loss responsibility. Calling a PM the CEO of the product makes for a catchy conference talk, but it isn't an accurate description of the job.

Where the comparison starts to become useful is accountability. While product managers don't have the authority of a CEO, they are often held accountable for whether a product succeeds. That accountability extends well beyond writing requirements or prioritizing a backlog. A product manager is responsible for understanding the customer, defining the problem, deciding what should be built, and making sure the organization stays focused on solving the right problem. None of those responsibilities have changed because AI became better at writing code.

I also don't believe AI changes the division of responsibilities between product and engineering. Product managers should continue to own the problem, not the implementation. Engineering leaders should continue to own architecture, technical design, scalability, and maintainability. AI can certainly generate architectural recommendations, but I'd still rather have an experienced engineering lead evaluate those recommendations than have a product manager pretend to be a software architect. Good product managers understand technology well enough to ask the right questions and recognize tradeoffs, but they don't need to become the best engineer in the room.

One area where I've consistently disagreed with many organizations is project management. Plenty of companies introduce project managers or scrum masters to keep everyone organized and moving in the same direction. I've worked with some outstanding people in both roles, but I've never been convinced that delivery should be separated from product management. Being a product manager is already a difficult job, but I don't think that difficulty is a good reason to split accountability across multiple people.

The reality is that product managers are delivery managers whether they want to be or not. They need to know whether engineering is on schedule, whether legal has reviewed the customer agreement, whether marketing is ready for launch, whether customer support has completed training, and whether operations can actually support the product that is about to ship. Even if someone else is responsible for tracking all of those workstreams, the product manager still has to understand them. They still need the information in order to make decisions. Adding another layer between the PM and the rest of the organization often means information arrives later, context gets filtered, and decisions take longer. The PM still owns the outcome, but now someone else owns the status updates.

Another area that often gets overlooked is financial understanding. Every meaningful product decision has an economic consequence, whether it's obvious or not. Pricing changes affect adoption. Reward structures affect profitability. Underwriting changes affect losses. Operational improvements reduce servicing costs. Feature prioritization determines where engineering resources are invested and, ultimately, where the business expects to generate returns. If a product manager doesn't understand those relationships, it's very difficult to make good trade-off decisions.

That doesn't mean every PM needs to become a finance expert or build three-statement financial models from scratch. Many organizations have excellent finance and FP&A teams that provide those capabilities. But product managers should absolutely understand how their product makes money, where it loses money, what assumptions drive profitability, and how individual decisions impact the economics of the business. Without that understanding, product prioritization becomes an exercise in opinions rather than informed decision-making.

Perhaps that's why the role has always felt so demanding. Product managers spend their days talking to customers, writing requirements, reviewing designs, answering engineering questions, coordinating launches, working with legal, discussing marketing plans, analyzing data, understanding financial performance, and making hundreds of small trade-off decisions that collectively determine whether a product succeeds. AI will make many of those individual activities faster, but it doesn't remove responsibility for making the right decisions. If anything, faster execution simply means those decisions come more quickly and with greater frequency.

Years ago, a product manager who worked for me looked up after another long day and simply said, "This is a hard job."

He was right then, and I think he's still right today.

About ProductFTW

ProductFTW is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.