What does a Product Manager actually do?

Ask ten people what a Product Manager does and you will get ten lists. Writes the PRD. Owns the roadmap. Runs the standup. Grooms the backlog. Talks to customers. Ships.

Every one of those is a tool. None of them is the job.

The best one-line answer I have found comes from Jeff Gothelf: product managers are navigators of uncertainty. Their job, in his words, is to help their team navigate that uncertainty as smoothly as possible.

I keep coming back to that article, because it survives contact with real teams. The artifact answer does not.

Why the artifact answer fails

Here is the test. Take anything on that list, imagine doing it perfectly, and check whether the product can still fail.

It can. You can write a flawless spec for the wrong feature. You can run the tidiest standup in the company on a team building something nobody wants. You can hit every date on the roadmap and watch usage stay flat. Every artifact on the list is fully compatible with failure, which means none of them is the thing you are accountable for.

This is also why the artifacts keep getting replaced and the job does not. The spec was never the point, alignment was, which is why the best PMs now make PRDs invisible rather than make them better. Swap the tool, keep the job.

What the uncertainty actually is

"Uncertainty" sounds abstract until you write down what you do not know about the thing your team starts building on Monday.

Is the problem real, or did three customers mention it in the same week? Does this solution actually solve it, or does it only look like it should? Will people manage it without a walkthrough? Can we build it in the time we said? Does it still work for the business once you count the support load?

Those are the four product risks in plain language, and a Product Trio exists precisely so all of them get assessed at the same time instead of in sequence. I have written about how that structure works, so I will not repeat it here. The point for this post is narrower: that list is your actual workload. Everything else is administration.

What navigating uncertainty looks like in practice

Gothelf gives four practices. They read like values on a careers page until you write down what each one looks like when it is fake and when it is real, so here is my version of that.

Customer centricity. Fake: a quarterly survey and a Slack channel called #voice-of-customer. Real: you can describe in specifics what your customer was doing the last time they hit the problem, because you asked about that time rather than about what they want. That is the whole difference between research and requirement collection, and it is why the Product Death Cycle catches teams who sincerely believe they are listening.

Agility. Fake: two-week sprints. Real: changing direction when the evidence says so, out loud, with the roadmap slide still on the screen. Agility is not a cadence. It is the willingness to be wrong on Thursday about something you announced on Monday.

Evidence-based decisions. Fake: a dashboard nobody opens. Real: you can name the assumption your current bet rests on, and the cheapest test that would break it. Sometimes that means carrying a result into a room where a senior person has already said what they hope to hear. That is not politics, that is the job. If you want the mechanics of getting from an outcome to a validated bet, build on evidence, not a hunch covers it.

Continuous learning. Fake: a retro where everyone agrees communication could be better. Real: killing something you already built. Almost no team has a ritual for that, which is how dead features accumulate. Around 80% of features in a typical product are rarely or never used, and every one of them was somebody's confident Tuesday.

Why this definition is uncomfortable

Because it is much harder to report on.

"We shipped four things" is a sentence any status meeting accepts. "We found out our second-biggest assumption was wrong and cancelled a quarter of planned work" is a better week and a worse slide. Until leadership can hear the second sentence as a win, PMs will keep optimising for the first one, and you get a team that is extremely efficient at producing things nobody needs.

It is uncomfortable for a second reason. It removes the excuse. If the job is producing artifacts, a failed product belongs to someone else: the market, sales, the estimates. If the job is navigating uncertainty, the failure is the navigation.

That is not the same as saying the PM decides everything. The role carries no formal authority over the people doing the work, which is exactly why Product Managers are not mini-CEOs. Navigator, not captain. You are accountable for whether the crew knows where the rocks are.

The two-question test

If you want to know whether you are doing this job or the artifact version of it, answer these without opening a document.

1. What is the biggest thing you do not know about your current bet?
2. What are you doing this week to find out?

If the first answer takes more than ten seconds, you are not navigating, you are administering. If the second answer is "we will see after launch", the uncertainty has not gone anywhere. You have only agreed to pay full price for the answer.

How much of the week should go to that second question depends on your stage and your risk, and it moves a lot. That is its own argument, and I have written the version I give clients: how to balance discovery and delivery.

Most of the PMs I work with already know all of this. What they are missing is the air cover to act on it, and that tends to be the real work in product advisory engagements. Not teaching the practice. Making it safe to run.