Not what the job description says. What the function is supposed to deliver when it is set up with any real authority.
The reason I ask is that the gap between those two things is expensive in a way that takes a while to show up. Not obviously expensive like a bad hire or a failed launch. The kind that accumulates quietly until someone looks back at two years of roadmap and realizes the team shipped a lot of things that did not matter.
In some organizations, the product manager role is technically distinct on paper while functionally hollowed out in practice. The person has the title but spends most of their time coordinating timelines, writing status updates, and translating between engineering and commercial teams. The "should we build this" question gets answered upstream, often informally, by whoever has the most organizational gravity that week.
That situation is hard to spot from the outside because delivery is still happening. Metrics get reported. Sprints close. The absence of real product judgment only becomes visible when you zoom out and ask whether the work actually moved the product forward or just moved.
Some organizations do not misuse the product manager deliberately. They genuinely believe the function is covered, because different parts of it are handled by different people.
Technical leads talk directly to customers and feed insight back into architecture decisions. Commercial leaders connect revenue pressure to roadmap priority. The CEO holds the product vision. Everyone is contributing, and from the inside it can feel like the bases are covered.
But product management, in its most effective form, is not a collection of informed perspectives on what to build. It is the function that integrates those perspectives into one coherent product direction and holds that direction under competing pressures. Someone has to own the synthesis. If nobody does, the roadmap ends up reflecting whoever made the strongest case most recently, not what the product actually needs to become.
There is a version of this problem that is harder to excuse.
Some companies argue that early-stage speed does not leave room for formal product thinking, and there is some truth to that. Founder instinct and tight feedback loops can substitute for process when the problem space is still narrow and the customer base is still small.
But that argument only holds when the company has not yet hired a product manager. The moment you bring one in, you have already made the decision that you need the function. Constraining them to project management after that fact is not stage-appropriate pragmatism. It is organizational confusion with a salary attached.
What you end up with is the worst of both models. The PM is present, so nobody feels the absence of strategic product thinking. The questions that should be asked are not asked, because presumably someone is handling it. But that person is chasing meeting notes and status updates. The function exists on the org chart and nowhere else.
So what does the role actually require when it is set up with real scope?
Not timeline management. Not stakeholder relations. Not a seat between engineering and sales.
The product manager, in a well-structured organization, owns a specific and difficult question: are we solving the right problem? They keep that question alive through prioritization debates, roadmap planning, commercial pressure, and customer conversations. They are the person who can articulate, with actual reasoning rather than instinct, why one bet matters more than another right now.
That requires enough understanding of customers to challenge commercial assumptions, enough technical fluency to have credible conversations with engineering, and enough business clarity to translate both into decisions that make strategic sense. The integration is the job. Not any one of those domains in isolation.
When companies understand that, they use product managers well. When they do not, they get someone very expensive running a very organized to-do list.