What is a product manager? A search for a definition.

Recently, I was at a playground with my family and my wife when I met another couple with a kid. We started talking, and my wife tried to explain what I do professionally, and her explanation amused me. I didn't have too much time to think about it, and the next day I was asked to define "product manager".

It is a fun experiment when I started thinking about it. I don't think I ever heard 1 person talking about their job as a product manager or owner, where they had a single list of responsibilities. Rarely could I hear a common version of the requirements for the job role. Even now, while I'm job hunting, wherever I go for an interview, a product manager would be required to do regular tasks, but everyone has a different variant of it. It actually varies by the size of the company, the experience of the team and its members, and how the company divides the product.

All of a sudden, this became an interesting experiment in my head, and I started researching.

How do others define a product manager?

The variety of definitions out there is staggering. Marty Cagan, one of the most respected voices in product management, describes product managers as responsible for evaluating opportunities and determining what gets built and delivered to customers. He emphasizes discovery work and empowered teams over feature factories.

Ben Horowitz famously wrote that a product manager is the "CEO of the product," though this phrase has been debated and dissected endlessly. Some love it for capturing the strategic ownership aspect, while others hate it for implying authority that most PMs don't actually have.

Melissa Perri takes a different angle, defining product managers through their focus on outcomes over outputs. In her view, PMs exist to solve customer problems in ways that meet business objectives, not to build feature lists.

On LinkedIn and in job descriptions, you'll find even more variations. Some companies want PMs who are mini-project managers, tracking timelines and coordinating releases. Others want strategic thinkers who set vision and work three quarters ahead. Still others want data analysts who can dig through metrics and run experiments.

The tech industry adds its own flavor. At Google, PMs are expected to be highly technical and data-driven. At design-led companies like Airbnb, the PM role intertwines closely with design thinking. At startups, PMs often wear every hat imaginable, from customer support to growth marketing.

What became clear in my research is that there's no single source of truth. The role has evolved organically across different companies and contexts, and each organization has shaped it to fit their needs.

Is there a difference between a product manager and a product owner? Why?

This question trips up even experienced practitioners. The short answer is yes, there's a difference, but it's muddier than you'd think.

Product Owner is a formal role within the Scrum framework. According to the Scrum Guide, the Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team. They manage the product backlog, clearly express backlog items, order them, and ensure the team understands them. The Product Owner is accountable to stakeholders but operates within a single Scrum team.

Product Manager, on the other hand, isn't tied to any specific methodology. It's a broader role that typically includes strategy, market research, customer discovery, roadmapping, and cross-functional leadership. A PM might work with multiple teams, influence company strategy, and own the entire product vision.

In practice, many organizations use the terms interchangeably, especially smaller companies. I've seen job postings that say "Product Manager/Owner" as if they're synonyms. But in larger organizations, particularly those that follow Scrum religiously, you might find Product Owners working under Product Managers. The PM sets strategy and vision, while the PO focuses on execution with the development team.

Some companies have gone the other way. They've eliminated the PM title entirely in favor of Product Owner, believing it creates clearer accountability within their agile teams. Spotify did something different altogether, creating a model where Product Owners existed within squads, while Product Managers (or Product Leads) worked at a higher level across tribes.

The reason for this confusion is historical. Product management as a discipline predates agile, but when Scrum emerged and defined the Product Owner role, it created overlap. Organizations have spent the last two decades figuring out how these roles coexist, and they've all landed in different places.

Why are there so many differences in defining the job role?

This question kept me up at night during my research. Why can't we just agree on what a product manager does?

The first reason is that product management emerged differently across industries. At companies like Procter & Gamble and HP, product management started as brand management and technical product marketing. These PMs focused on positioning, pricing, and go-to-market strategy. In software companies, especially with the rise of agile, the role shifted toward working closely with engineering teams on what to build. The DNA of the role depends on where it came from.

Company size creates massive variation. At a five-person startup, the PM does everything from customer interviews to writing copy to analyzing funnels to managing the cap table. At a Fortune 500 company, the PM might specialize in one narrow aspect of a massive product suite, supported by researchers, analysts, designers, and program managers. The job title might be the same, but the day-to-day reality is completely different.

Product complexity matters too. Managing a developer API requires different skills than managing a consumer mobile app. B2B enterprise software demands different approaches than B2C marketplaces. Medical devices operate under different constraints than SaaS tools. Each product type shapes what the PM needs to focus on.

Organizational maturity plays a huge role. Companies early in their product journey often need PMs who can establish basic processes, educate the organization about customer-centricity, and build roadmaps from scratch. Mature product organizations need PMs who can optimize, experiment, and navigate complex stakeholder landscapes. You're solving different problems at different stages.

Then there's the reality that many companies still don't fully understand what product management is. They create PM roles because they've heard they should have them, but they define the role based on their immediate pain points. If engineering keeps building the wrong things, they make the PM a requirements gatherer. If stakeholders can't align, they make the PM a project manager. If the CEO wants a mini-me, they make the PM a strategist. The role morphs to fill organizational gaps.

Finally, product management is still relatively young compared to disciplines like engineering, design, or marketing. We're still figuring it out as an industry. Every few years, new frameworks emerge, new thought leaders rise, and new best practices spread. The role continues to evolve, which means the definition continues to shift.

The final thoughts

After all this research, playground conversations, and interview experiences, here's what I've landed on.

A product manager is someone who holds responsibility for whether a product creates value for both users and the business. They don't necessarily have authority over everyone involved, but they're accountable for the outcome.

The "how" of that responsibility varies wildly based on context. But the core remains the same: you're the person who loses sleep over whether the product is solving real problems, whether customers care about it, whether the business model works, and whether the team is building the right things.

You're part strategist, part communicator, part analyst, part psychologist. You spend your days in the gap between what customers need, what the business requires, what technology enables, and what stakeholders want. Your job is to navigate that gap and find solutions that satisfy enough of those constraints to move forward.

You don't need to be the CEO of anything. You don't need formal authority. You need influence, curiosity, judgment, and the ability to make decisions with incomplete information. You need to understand customers deeply, communicate clearly, and build trust with teams.

The day you stop learning about your users is the day you stop being effective. The day you stop questioning assumptions is the day you become a feature factory. The day you stop caring about outcomes is the day you're just managing a backlog.

Product management isn't about the title or the exact list of responsibilities. It's about the mindset. It's about waking up every day and asking: are we building something people actually want? Is it creating value? How do we know? What should we do next?

That's what a product manager is, if you ask me. Everything else is just context.