What Does a Product Manager Actually Do?
The PM is responsible for determining what to build and why. This definition is clear, widely accepted, and almost entirely useless.
I believed it once. Early in my career, I could recite the frameworks, draw the Venn diagram, explain how the PM sits at the intersection of business, technology, and user experience. Then I actually did the job. The definition stopped fitting around month three.
People ask me what I actually do for a living. I give them an answer. They nod confidently. All of them are wrong.
The role exists in every technology company. No two companies agree on what it means.
The Many Species of Product Manager
Observe the PM in its natural habitat and you will encounter remarkable variation. The taxonomy is extensive.
There is the Historian, who alone remembers why the login flow works the way it does and what happened to the team that tried to change it. Their value is institutional memory. Their calendar is full of meetings where they explain decisions made by people who left two years ago.
There is the Diplomat, who spends most of their time translating between engineering and sales. Engineering says the feature is impossible. Sales says they already promised it. The Diplomat finds language that allows both parties to leave the room believing they won.
There is the Therapist, who listens to stakeholders describe their anxieties about the product and responds with validation and a Jira ticket. The ticket may or may not be actioned. The validation is the point.
There is the Archaeologist, who excavates deprecated Confluence pages to decipher workflows that no one understands but everyone depends on. They inherit systems built by teams that no longer exist, documented in formats no one knows how to open.
There is the Air Traffic Controller, who exists primarily to prevent two teams from building the same thing. More commonly, they notice after both teams have already shipped.
And there is the Political Heat Shield, who attends leadership meetings so the engineers do not have to, absorbing questions about timelines and returning with answers that are technically accurate and practically meaningless.
I have been all of these. Sometimes in the same week. The role does not select for a type; it selects for people willing to become whatever the situation requires.
The Role That Changes Shape
Even within one organisation, the PM’s function is surprisingly unstable.
I once ran a discovery workshop where the VP opened by telling the room the goal was alignment. The engineering lead interrupted to say it was challenge. Halfway through, I realised I had no authority to steer either of them, and the best I could do was take notes and write a summary afterwards that described a consensus no one had actually reached. Everyone accepted the document. The project moved forward. I still do not know what the workshop was for.
Consider the roadmap review. The PM presents the plan. The CEO asks why Feature X is not included. The PM explains the prioritisation framework. The CEO nods thoughtfully and adds Feature X to the roadmap. The PM updates the document. The prioritisation framework remains in the deck for the next meeting, where it will be ignored again. I have been through this cycle enough times that I can now explain prioritisation with complete conviction while fully expecting it to be abandoned within a week.
I used to believe the PM owned the roadmap. Then I worked somewhere with a founder who changed it weekly based on whatever he had read that morning. I now believe the PM owns the document, not the direction.
Sometimes the PM discovers that the most important feature on the Q3 roadmap was added by accident. I inherited one of these once. No one remembered who requested it. No one remembered why. Everyone agreed it was critical, but no one could explain the use case. I spent three weeks trying to get it removed before accepting that building the feature would cost less political capital than deleting it. We shipped it. I do not know if anyone used it.
Responsibility Without Authority
The PM is theoretically accountable for outcomes. They control almost nothing that determines those outcomes.
They do not manage the engineers. They do not set the budget. They do not approve the marketing spend. They do not hire the designers. They cannot force sales to stop promising features. They cannot prevent the founder from reading an article about AI and arriving at the Monday meeting with a new strategic direction.
The job, if described honestly, is largely translation. Translate business goals into requirements. Translate technical constraints into timelines. Translate user feedback into something the roadmap can accommodate. Translate leadership’s changing priorities into a narrative that engineering will not find demoralising. Most of my job involves absorbing competing narratives and returning them to the team in a form that will not derail the sprint. I tell myself this is leadership. It might just be coping.
Most PM work is not decision-making. It is making decisions possible for other people while maintaining the illusion that a decision has already been made.
Even now, after years in this role, there are days where I have no idea what I am actually supposed to be doing. The job descriptions mention vision and strategy. The reality is more often confusion wrapped in confidence, held together by calendar invites and a tolerance for ambiguity. Impostor syndrome is not a phase you get past. It is part of the operating environment.
The Function That Remains
Strip away the frameworks, the certifications, the job descriptions. What persists?
Organisations are complex systems. Complex systems generate ambiguity. Someone has to hold the ambiguity so that others can pretend the world is simpler than it is. Someone has to remember the context, own the contradictions, and attend the meetings that have no clear purpose.
The PM is whoever ends up doing that. The title is a label applied after the fact.
I have stopped trying to define the role. The job is whatever keeps the system coherent for one more week. The contradictions do not resolve. You just get better at carrying them.