Ask five people what a Product Manager does and you will get five different answers. Some will say PMs are 'mini CEOs'. Others will say they write tickets for engineers. Job descriptions do not help either - they tend to list everything from market research to stakeholder management to data analysis, which tells you very little about what the role feels like day to day.
Here is a more honest answer: a Product Manager is responsible for making sure the team builds the right thing. Not for building it - that is engineering. Not for making it usable - that is design. For deciding, out of everything the team could build, what is actually worth building, and in what order.
The three questions PMs answer every day
Strip away the meetings and the tools, and most PM work comes down to answering three questions over and over again, at different levels of detail:
- What problem are we solving, and for whom? Every feature request, stakeholder demand, and clever idea has to pass through this filter. If you cannot name the user and the problem, you are not ready to build.
- Why this, why now? There are always more problems than capacity. Prioritisation is not a quarterly exercise - it is a daily discipline of saying 'not yet' to good ideas so the best ones can ship.
- How will we know it worked? Before anything ships, a PM should be able to say what success looks like - a metric moving, a behaviour changing, a complaint disappearing.
What a typical week actually looks like
The honest answer is that no week is typical, but there are recurring rhythms. You will spend real time in discovery: talking to users, reading support tickets, digging through analytics to understand how people actually behave rather than how you hoped they would. You will spend time with your engineers and designer - refining upcoming work, unblocking decisions, and answering the dozens of small 'should it do X or Y?' questions that come up during a build.
You will also spend time communicating outward: updating stakeholders, aligning with other teams, and explaining - sometimes repeatedly - why the roadmap looks the way it does. This part surprises people who come into the role expecting it to be mostly about ideas. A large portion of the job is writing clearly, presenting decisions, and building trust so that when you say 'this is the priority', people believe you have done the work behind it.
What PMs do not do
- PMs do not manage the engineers. The team does not report to you - you lead through context and clarity, not authority.
- PMs do not just write requirements. If your team only ever hears from you through tickets, something has gone wrong.
- PMs do not need to code. Technical fluency helps you ask better questions, but engineers do not need another engineer - they need someone who deeply understands the user and the business.
- PMs are not the 'idea person'. Ideas are cheap and everyone has them. Your job is evidence, prioritisation, and follow-through.
The skill that ties it all together
If there is one meta-skill under all of this, it is judgement under uncertainty. You will rarely have complete data. Users will tell you contradictory things. Stakeholders will want everything at once. The job is to gather just enough evidence, make a reasoned call, communicate it clearly, and then own the outcome - including being wrong sometimes and adjusting quickly.
That is also why Product Management is learnable. Judgement is built through reps: framing problems, making prioritisation calls, defending trade-offs, and reviewing what happened. You do not need a specific degree or a technical background - you need structured practice and honest feedback. That is exactly the gap good mentorship closes.