The short answer is: make decisions with incomplete information, then help other people make the same decision without starting the meeting again.

The longer answer is less cinematic. A product manager’s day is usually a collage of customer calls, product analytics, awkward trade-offs, roadmap questions, design critiques, engineering constraints, and messages that begin with “quick question” and end with a new project.

The job is not a list of ceremonies

The job is often described through its visible outputs: roadmaps, requirements, launches, dashboards. Those are the receipts. The work is the reasoning that produced them.

A PM keeps asking:

  • What problem are we actually solving?
  • For whom is it painful enough to matter?
  • What would we need to learn before committing?
  • What are we choosing not to do?
  • How will we know whether the choice helped?

That sounds tidy written down. In real life, each question arrives with a different person, deadline, incentive, and definition of “obvious.”

The invisible work

There is a lot of translation. Customers describe symptoms; teams need a problem. Executives describe a bet; teams need a decision. Engineers describe constraints; everyone needs to understand the trade-off. Designers describe a behaviour; the organisation needs to decide whether that behaviour is worth building.

There is also a lot of subtraction. A useful PM is not a feature vending machine. They help a team remove the things that are interesting, politically convenient, or merely loud enough to survive another meeting.

The roadmap is where prioritisation becomes public. The real prioritisation happened in all the conversations before it.

A more useful definition

Product management is the practice of creating the conditions for a team to make good product decisions repeatedly.

Not perfect decisions. Not decisions everyone loves. Good decisions: clear enough to act on, reversible when possible, and connected to a customer or business outcome rather than the emotional weather of the room.

That is why the work can feel invisible. When it is done well, the team simply moves with less fog.

The four kinds of knowledge behind the calendar

Marty Cagan’s description of the product manager contribution emphasises deep knowledge of customers, data, the business and the industry. That makes the crowded PM calendar easier to interpret. The meetings are not the job; they are one way of gathering, testing and distributing those four kinds of knowledge.

A customer conversation without business context may produce a compassionate but unviable idea. A revenue discussion without customer context may produce a commercially neat solution nobody chooses. Data without industry context can explain yesterday while missing a shift already changing tomorrow.

The product manager does not need to be the smartest person in all four domains. They need enough depth to connect specialists, notice contradictions and recognise when the team is making a consequential assumption.

What good PM work leaves behind

The work should leave decision infrastructure, not dependency on one heroic person.

After a useful discovery cycle, the team should understand the opportunity and the riskiest assumptions. After prioritisation, people should know what was rejected and why. After a launch, they should know what outcome to watch and who decides what happens next. After a stakeholder conversation, the reasoning should survive beyond the meeting.

This is why a PM who personally answers every question can be less effective than one who makes the context easy to access. Speed that depends on one person’s memory is borrowed speed.

The public Intercom product manager expectations ladder is useful because it makes progression broader than producing bigger specifications. It includes customer focus, analytics, strategy, execution and leadership at increasing scope. The job changes as the decisions become more ambiguous and the system around them becomes larger.

A day viewed through decisions

Instead of classifying time as meetings versus “real work,” classify it by the decision being improved.

  • A customer call may improve whether a problem deserves attention.
  • A design critique may improve whether a solution communicates the right behaviour.
  • An engineering discussion may improve scope, sequencing or feasibility.
  • A commercial review may expose viability constraints.
  • Quiet writing may make the reasoning inspectable for everyone who was not there.

Then ask whether each activity changed the evidence, options, trade-off or shared understanding. If it did none of those, it may be status theatre.

What product managers should not absorb

Because the role sits between functions, it attracts abandoned work. Project coordination, meeting notes, quality assurance, sales enablement, operational reporting and team administration can all drift toward the PM. Some of that work is necessary and sometimes the PM is the sensible person to do it. The danger is allowing connective work to consume the contribution only product management is positioned to make.

If the PM spends the week moving tickets while nobody is investigating value and viability, the team has excellent coordination around an unanswered product question.

A useful weekly review is: what decision required product judgment, and did I create enough space to improve it? If the answer is repeatedly no, the problem may be role design rather than personal productivity.

Questions to take back to your team

  • Which important decision became clearer because of your PM work this week?
  • How much of the product context lives only in one person’s head or calendar?
  • Which recurring meeting changes evidence, options or trade-offs—and which merely reports weather?
  • Is your PM spending time on value and viability, or absorbing every abandoned coordination task?
  • If the PM took a week off, would the team lose momentum or simply lose a human search engine?

Look at tomorrow’s calendar and write the decision each meeting is supposed to improve. If you cannot name one, what would happen if the meeting became a written update—or disappeared?

My take

If your calendar is full of meetings, the question is not whether you are “doing product.” The question is whether those meetings are increasing the quality of decisions.

If not, you may not need a better ceremony. You may need a clearer problem, a smaller decision, or permission to say what everyone is already avoiding.