What a great product manager actually does

The PM job description is one of the most mis-specified roles in tech. Most JDs describe a coordinator with a roadmap and a Jira board. The best product managers do something that no job description I have ever read accurately captures: they create clarity in conditions where clarity cannot be derived from data alone, and they produce decisions that simply would not have happened without them in the room.

The job description is for a different job.

If you have read a dozen PM job descriptions, you have read one PM job description. They converge on the same template: own the roadmap, work cross-functionally, gather requirements, run sprints, communicate with stakeholders, measure outcomes. These are all real activities. They describe the surface-level mechanics of the role. They say almost nothing about what separates an exceptional PM from a mediocre one who does all of the same things.

The template PM job description is written by someone who managed a PM, not by someone who was one. It describes what is observable — the meetings attended, the documents produced, the processes maintained. What is not observable, and what is not in the job description, is the quality of judgement that determines whether any of those activities produce value. A poor PM can run a sprint. A poor PM can maintain a roadmap. A poor PM can communicate with stakeholders. They will do all of these things and still produce a product that doesn't work, a team that doesn't trust each other, and a backlog that is full of work that shouldn't be done.

The job of a great PM is better described by what they produce than what they do. They produce clarity. They produce decisions. They produce a shared picture of what the product is for that is specific enough that engineering, design, sales, and leadership can all operate from it independently without contradicting each other. This is much harder than running a sprint, and it requires a completely different set of capabilities.

Creating clarity in conditions of ambiguity.

The most common condition a PM operates in is: too many signals, insufficient data, competing legitimate priorities, and a deadline that requires a decision before certainty is available. This is not a pathological state. This is the permanent state of building products in markets that are not fully understood. The question is who can navigate it well.

The weak PM's response to ambiguity is to seek more data before making a decision. This is rational, but it is often wrong. More data takes time, and time costs more than most teams account for. By the time the data arrives, the market context has shifted, the engineering team has been in a holding pattern, and the decision is now being made under a different set of constraints than the original ones. The pursuit of certainty before deciding is itself a decision — to not decide — and it usually produces worse outcomes than a well-reasoned call made under uncertainty.

The strong PM's response to ambiguity is to name the specific nature of the uncertainty, propose a decision that is defensible under a defined set of assumptions, and identify the earliest signal that would indicate the assumption was wrong. "I am proposing we build the reporting feature for individual users first, not teams, based on the assumption that individual users are the primary decision-makers in our enterprise deals. The signal that this was wrong is if enterprise deal cycles don't shorten after the feature ships. We will know by the end of Q3." This is a clear decision with explicit assumptions and a defined falsification condition. It can be challenged, improved, or approved. A pile of data without a decision cannot.

Holding the space between engineering and business.

The PM role is often described as sitting "between" engineering and business, which makes it sound like a mediator position. It is not. It is a translation position with decision authority.

Engineering teams operate with a set of constraints that are real but often invisible to the rest of the organisation: technical debt that makes certain features disproportionately expensive, architectural decisions that foreclose certain product directions, the difference between a "simple" feature that is actually trivial and a "simple" feature that requires rewriting the authentication layer. A PM who cannot translate these constraints into business terms will consistently over-commit to stakeholders and under-deliver to engineering. They will be liked by neither.

Business teams operate with a set of pressures that are real but often invisible to engineering: customer commitments made by sales, competitive threats that change the calculus on feature timing, the difference between a feature that is nice-to-have and one that is blocking a renewal conversation with a large account. A PM who cannot translate these pressures into engineering terms — not as demands, but as context — will consistently produce engineering teams that feel like they're building in the dark.

The translation is not passive. It requires the PM to form their own view about what matters and why, to push back on both sides when the demand is unreasonable, and to make calls when the two sides cannot align on their own. A PM who facilitates conversations without making calls is a moderator, not a product manager. The value is in the call, not the conversation.

What it actually looks like day to day.

The great PM's calendar looks less like a series of meetings and more like a series of decisions being moved toward closure. Each conversation they have is either gathering information toward a specific decision that needs to be made, communicating a decision that has been made, or identifying a decision that should have been made already and hasn't been.

On Monday morning, a great PM knows exactly what decision needs to be made by the end of the week, who needs to be involved in making it, what information is missing, and what the default call is if the missing information doesn't arrive. They are not waiting for the next planning cycle. They are not managing a backlog. They are driving a specific decision to closure.

The user research they do is not broad discovery — it is targeted investigation into a specific question that is blocking a specific decision. "I need to understand whether users prefer list or card view for the dashboard, because the engineering cost of card view is three weeks and I need to know if that is worth it before the sprint planning on Thursday." That is the right kind of user research conversation. "Let's do a round of discovery interviews to understand our users better" is a research programme, not a decision-driving activity.

The stakeholder conversations they have are not status updates. They are decision conversations. "I want to brief you on the trade-off I am about to make, because it affects your team's Q3 commitments and I want you to challenge it before I finalise it." This is a fundamentally different kind of stakeholder engagement than the PM who shows up at the quarterly business review with a roadmap slide.

The decisions that wouldn't have happened without them.

This is the real test of a PM and the hardest one to evaluate in an interview. The question is not whether they can run a process — almost anyone can be trained to run a process. The question is whether they produce decisions that the organisation would not have reached on its own, in the timeframe it needed them.

Organisations without a great PM — or with a mediocre one — make product decisions one of two ways: either the founder makes all of them (which doesn't scale), or they emerge from a slow, friction-filled process of consensus-building between engineering, design, and business (which is slow and often produces the average of everyone's preferences rather than the right call). Neither of these mechanisms produces the quality or speed of decisions a growing product company needs.

A great PM provides a third option: a person who has earned sufficient trust across the organisation to propose a decision, absorb the challenge, and commit to a course of action in a time frame that allows execution. They are not a dictator — the decision is legitimated by the quality of the reasoning and the openness of the process. But they are the person who closes the loop, and closing the loop is what allows the organisation to move.

The difference between organisations with and without this person is easy to see. In their absence, the backlog fills with items that are "blocked pending decision." Engineering velocity drops because the team is constantly asking what to build next. Stakeholder frustration rises because requests go in and nothing seems to come out. In their presence, the machine moves. Not because everything is correct — some decisions will be wrong — but because wrong decisions that are made and corrected are faster than correct decisions that are never made at all.

The five marks of a great PM.

• 01
  They produce decisions, not processes. A great PM leaves every meeting having either made a decision, moved one forward, or identified a missing decision that needs to be made. They are not the person who runs the meeting — they are the person who ensures the meeting produces something. The process is in service of the decision, not the other way around.
• 02
  They name the assumptions behind every call. Great PMs do not present recommendations as facts. They present them as the best available decision given a set of named assumptions, with a clear signal that would indicate the assumption was wrong. This makes the decision checkable, which builds trust even when the decision turns out to be incorrect.
• 03
  They push back on both sides with equal willingness. A PM who can challenge engineering but not sales is a liability. A PM who can challenge leadership but not customers is a liability. The willingness to push back on the person with the most authority in the room — respectfully, with reasoning — is the mark of a PM who has actually internalised the product perspective rather than inherited the priorities of whoever they last spoke to.
• 04
  They make their reasoning legible. The best PMs I have worked with consistently document their decision-making. Not every decision — the small ones are made verbally and forgotten correctly. But the significant calls: what they built, what they didn't build, why, and what they expected to happen. This creates an institutional record that makes it possible to learn from decisions and to trust the person making them.
• 05
  They measure impact, not activity. A poor PM measures their own performance in terms of features shipped, sprints run, and stakeholders managed. A great PM measures it in terms of outcomes: did the metric we were targeting move, and was the movement attributable to the work we did? If the answer is consistently no, a great PM changes what they are building, not how efficiently they are building it.

Frequently asked questions.