What Does a Product Manager Actually Do?

"So what does a product manager actually... do?"

If you've been in product for more than a year, you've heard this question. From engineers. From salespeople. From your family. From other PMs.

And if you're honest, your answer changes every time. Because the truthful answer — "it depends on the company, the team, and the organizational structure" — sounds like you don't know what you do.

The problem isn't that product management is hard to define. It's that most organizations don't bother defining it — and then wonder why the function doesn't work.

The Myth of the Universal PM

The product management industry pretends the role is the same everywhere.

Job descriptions ask for "Technical PMs" and "Full-Stack PMs" — roles that don't actually exist in any standardized way. They're conference babble. A "Technical PM" at a startup means something different from a "Technical PM" at an enterprise company. A "Full-Stack PM" is whatever the hiring manager needed when they wrote the description.

These fake titles create a cold war between engineering and product. Engineers hear "Technical PM" and think "someone who's going to tell me how to code." Product people hear it and think "someone who can talk to engineers." Neither interpretation helps.

The role isn't universal. It shouldn't be. Trying to make it universal is the first mistake.

The Right Question

The question isn't "what does a product manager do?" It's "what does product management do at your company?"

Product management is a function, not a job description. What it does depends on context:

• At a 10-person startup, it might mean one person doing research, strategy, design, and project management simultaneously.
• At a 500-person company, it might mean specialized PMs with dedicated research, design, and program management support.
• At an enterprise company, it might mean navigating stakeholder politics, managing P&L, and aligning twelve teams toward coherent strategy.

None of these are wrong. They're different answers to: "What does this organization need the product function to do?"

Making Product Legible

The real challenge is making the function legible — understandable to everyone who works with it.

When cross-functional partners don't understand what Product does, they fill in the blanks. As I've written before, illegibility leads to: Engineering thinks you're project managers. Sales thinks you're the feature request inbox. Leadership thinks you're the bottleneck.

The fix isn't a better job description. It's a Product Story — a repeatable narrative that makes the function legible to everyone.

Three Things Every Product Function Should Define

• What decisions does Product own? "What to build" is too vague. Does Product own pricing? Go-to-market timing? Technical architecture decisions? The boundaries need to be explicit. When they're not, every decision becomes a turf war.
• What inputs does Product use? Customer research, sales feedback, analytics, competitive intelligence, technical feasibility. Which are primary? Which override others? If customer feedback always wins, that's one kind of function. If strategic analysis always wins, that's another. Make the hierarchy explicit.
• What outputs does Product produce? Not "features." Features are what engineering produces. Product produces decisions — what to build, what not to build, how to prioritize, when to stop. The output is a series of decisions that direct resources toward the problems that matter most.

When your team answers all three clearly — and cross-functional partners agree — product management stops being a mystery. It becomes a function people work with instead of work around.

Why This Matters Now

In a market where every B2B SaaS company is tightening budgets and questioning headcount, "what does Product do?" isn't abstract. It's existential.

Functions that can't articulate their value get cut. Functions that can't explain their decisions get overruled. Functions that can't define their boundaries get absorbed into engineering, marketing, or project management.

If your CEO, VP of Engineering, and head of Sales would all give different answers to "what does Product do?" — you have a legibility problem. And legibility problems become headcount problems fast.

Start Here

Ask three people outside of Product: "What does our product team do?"

If their answers match yours, your function is legible. If they surprise you — and they will — that's the gap to close.

Because teams that make clear strategic decisions, communicate them well, and articulate their value — those teams get more resources, more autonomy, and more impact.

The teams that can't explain what they do? They get managed.

Can your team explain what Product does?

In my Product Story workshop, B2B SaaS product teams build a clear, repeatable narrative that makes Product legible to the rest of the organization. We define what the function owns, what inputs it uses, and what outputs it produces.

Book a Clarity Call — 30 minutes, no pitch. Just clarity on whether your product function needs a clearer story.

Not ready for a call? Subscribe to The Adam Thomas for frameworks and honest takes on product leadership, delivered biweekly.