Everyone has a different answer to this question. The LinkedIn version is inspirational but vague. The cynical version is "a lot of meetings and not much else." The real answer is somewhere specific in between — and understanding it will tell you whether this is the right career for you.
What PMs do NOT do
Let us start with what the job is not, because the myths are persistent. PMs do not write code. They are not engineers and are not expected to be. PMs do not design the user interface — that is a designer's job, even though PMs have opinions about it. PMs do not manage people. They have no direct reports on the engineering or design team; those people have their own managers. And despite the title, PMs are not the CEO of the product — they cannot unilaterally decide anything. They influence outcomes through clarity, relationships, and evidence.
What PMs actually do
The real job breaks into four activities that cycle continuously.
First, discover user problems. This means running user interviews, reading support tickets, reviewing NPS responses, digging into analytics to see where users drop off, and synthesizing all of that into a clear picture of what is broken and what is worth fixing. No one else owns this — the PM is responsible for the team understanding what users actually need.
Second, decide what to build next. Given limited engineering time and a backlog that is always longer than capacity, the PM has to prioritize ruthlessly. This means roadmapping, running prioritization frameworks, negotiating with stakeholders, and making explicit tradeoffs — and being willing to defend those decisions with data.
Third, write specs so engineers know what to build. Product requirements documents, user stories, acceptance criteria — the PM is responsible for making the requirement clear enough that engineering does not have to guess. Ambiguous specs produce the wrong product.
Fourth, coordinate across the team. Design, engineering, data, legal, marketing, and sales all have stakes in what gets shipped. The PM holds those threads together — making sure design is unblocked, that legal has reviewed the right things, that marketing knows what is launching and when.
After launch: measure and learn. Did it work? Did users actually use the feature? Did the metric move? The PM reviews the analytics, runs follow-up research if needed, and feeds the learning back into the next cycle.
The honest day
If you tracked a PM's calendar for a week, roughly 70% of their time would be in meetings — sprint planning, design reviews, stakeholder syncs, user interviews, cross-functional updates. The other 30% is writing: PRDs, one-pagers, Slack messages that need to be precise, analysis summaries. The creative, blue-sky strategy work that PM content on the internet implies is a constant activity is real, but it happens in the margins.
The thing no one says
PMs have a lot of responsibility and very little authority. You are accountable for whether the product succeeds — but you cannot tell an engineer how to build something, override a designer's judgment, or compel a legal team to move faster. Everything you achieve happens through influence, not authority. That is either deeply motivating or deeply frustrating depending on how you are wired. That is the job.