When Product Managers Become the Organisational Catch-All

Product managers rarely become overloaded through one dramatic decision. The role expands one reasonable request at a time.

Take notes because nobody else did. Prepare the commercial update because you know the context. Chase a legal review, organise the launch, repair the dashboard, and mediate a staffing dispute.

Each request can look harmless in isolation. Together, they turn the person with the broadest context into the organisation’s default exception handler.

The problem is not that product managers should refuse anything outside a narrow job description. Product work crosses boundaries, and useful people step into gaps.

The problem begins when flexibility hides the gap, the temporary task has no expiry, and nobody sees which product decision was displaced.

A better response is to classify the work, price its opportunity cost, and agree an operating contract with the people who can change the system.

The catch-all role is an organisational symptom

Product managers are unusually attractive recipients for unowned work. They know the customer, the strategy, the team, and the current commitments. They can often make an ambiguous request legible.

That context creates a dangerous inference: because the PM can help, the PM should own the work.

Once repeated, the pattern changes the role. Product judgement becomes one responsibility among many, while coordination, administration, and missing specialist work compete for the same attention.

Tang and Vandenberghe define role overload as demands exceeding a person’s available time, energy, or capability.

Two cross-sectional studies paired employee surveys with manager ratings in Canadian customer-service departments.

In both, greater role overload was linked to greater strain, which in turn was linked to several performance measures.

A separate 99-person, two-wave panel found that overload preceded strain across four months. It did not test the full path to work performance.

The studies did not examine product managers, and the primary designs cannot establish causality. Nor do they show that the classification in this article improves performance.

They do support a restrained point: persistent overload is not merely a personal scheduling failure.

The UK Health and Safety Executive makes the organisational responsibility explicit. Its Management Standards say demands should be adequate and achievable, with local systems for responding to concerns.

That is official workplace guidance, not a controlled test of product operating models. Still, it challenges a common response to overloaded PMs: become more efficient at absorbing the same design defect.

Start with the work, not the job description

Job descriptions are too abstract for this conversation. “Drive strategy” and “work cross-functionally” can be stretched to cover almost anything.

Use the last two working weeks instead. Build an inventory from the calendar, messages, documents, tickets, and tasks that occupied real attention.

For each item, record:

• what triggered it;

• who needed the result;

• what decision or output it produced;

• the time and repeated follow-up it required;

• who would have owned it if the PM were absent;

• which planned product work moved, weakened, or disappeared.

Do not start by arguing that an item is beneath the role. First establish what the organisation is asking the role to carry.

The inventory should include small work. A short request that creates repeated follow-ups is larger than its first appearance. Micro-coordination is often where invisible ownership accumulates.

Classify every request into five types

The classification is not a hierarchy of important and unimportant work. It distinguishes why the work belongs where it currently sits and what should happen next.

Type	Diagnostic question	Default response
Core product decision work	Does it improve a material product choice or learning cycle?	Protect it
Temporary glue	Is the PM bridging a named gap for a limited period?	Add an owner and expiry
Delegated ownership	Has another authority deliberately transferred a decision?	Define authority and accountability
Missing capability	Is valuable specialist work landing here because no capability exists?	Name and resource the gap
Pure administration	Does it require coordination but little product judgement?	Simplify, rotate, automate, or reassign

Core product decision work

This work changes which customer problem to pursue, which evidence to trust, which option to fund, which trade-off to accept, or what to learn next.

It may involve research, strategy, sequencing, product economics, outcome review, or decision communication. The test is not the activity. It is the product judgement the activity enables.

Writing a brief can be core work if it frames a contested investment. Reformatting the same brief into four stakeholder templates is unlikely to be.

Temporary glue

Temporary glue keeps important work moving while the normal route is unavailable or unfinished.

A PM might coordinate customer communication during an incident, bridge a handover after a departure, or create the first version of a launch checklist for a new team.

This flexibility is useful when the gap is named, the risk of leaving it open is clear, and somebody owns the permanent answer.

Without an expiry, temporary glue becomes silent role expansion. The PM does not solve the organisational gap; they make it less visible.

Delegated ownership

Delegation is a deliberate transfer of a decision, not the arrival of an errand.

If a commercial leader delegates approval of a class of packaging changes, the PM needs the authority, evidence, constraints, and accountability required to decide.

If the PM only prepares the analysis, chases signatures, and carries the fallout while authority stays elsewhere, ownership has not been delegated. Coordination has.

Missing capability

Some work exists because the organisation needs a capability it has not built or bought.

Recurring research operations, product analytics, launch enablement, technical programme coordination, or compliance support may land with a PM because the need is real and the owner is not.

Do not disguise that gap as versatility. Record the demand, its consequence, and the decision needed: add capacity, reduce demand, teach a bounded capability, or accept that other work will not happen.

Pure administration

Administration is necessary. That does not mean the role with the most context should perform all of it.

Calendar negotiation, minutes, routine status collation, access requests, and manual ticket hygiene may require care but little product judgement.

Place the task near its source, rotate it fairly, simplify the process, or automate it. Keep it with the PM only when the alternative costs more and that trade-off is explicit.

Know when flexibility is healthy

Healthy flexibility has four properties:

1. A reason: an incident, transition, experiment, or genuine one-off creates the need.
2. A boundary: the PM knows what they may decide and which risks remain elsewhere.
3. An expiry: a date or condition ends the arrangement.
4. A destination: a person or team will own the work, remove it, or make the temporary arrangement permanent by an explicit decision.

Flexibility is especially reasonable in a young team, during a short staffing gap, or when unfamiliar work must be understood before a stable boundary can be designed.

It becomes a system defect when the work is predictable, recurring, ownerless, and accepted only because the PM keeps rescuing it.

Other warning signs are revealing: the work vanishes from plans but not from calendars; absence stops the flow; several functions can request it but none can prioritise it; “just this time” has no recorded end.

For structural problems across several teams, Product Org Design for Clear Ownership examines decision boundaries and coordination interfaces.

The catch-all problem is narrower. It asks what the organisation has concentrated in one role before deciding whether a wider redesign is necessary.

Calculate the opportunity cost in displaced decisions

Hours reveal load. They do not reveal cost.

The opportunity cost of catch-all work is the most valuable product decision, learning cycle, or risk treatment that could not receive the same attention.

For each non-core item, name the displaced work. Avoid vague entries such as “strategy time.” Write the actual loss:

• renewal evidence was not synthesised before the roadmap review;

• two product options were not compared before engineering committed;

• onboarding behaviour was not reviewed after release;

• a pricing assumption reached approval without customer evidence;

• a known accessibility risk remained untested.

Then describe the consequence without manufacturing precision. A delay may reduce the options still available. A rushed review may leave uncertainty unresolved. An unexamined result may cause the team to repeat a weak bet.

Do not invent a revenue figure to make the case sound serious. A traceable decision and its lost evidence are more credible than speculative money.

Use the inventory to produce a short trade-off statement:

This cycle, recurring launch coordination used the capacity planned for the renewal evidence review.
If launch coordination remains with product, the review moves to the next decision window.
The choice is not whether both tasks matter. It is which consequence we are accepting and who may change the ownership.

This turns a complaint about busyness into an operating decision.

Negotiate an operating contract

An operating contract describes how the team will handle these work types. It is not a permanent constitution or a defence against helping colleagues.

Draft it with the manager and affected functional owners:

Core product decisions we protect:
Temporary glue we accept, with owner and expiry:
Decisions delegated to product, with authority and constraints:
Missing capabilities, with demand owner and next decision:
Administrative work, with route or rotation:
Trade-offs that require explicit approval:
Escalation conditions:
Review date:

The conversation should begin with evidence, not “that is not my job.”

Describe the repeated pattern, acknowledge why the work matters, show what it displaced, classify it, and propose a route. Ask the person with authority to choose the trade-off.

Two hypothetical formulations show the difference:

I coordinated the last four launch approvals because no owner was named. That delayed the renewal analysis before two roadmap decisions. I can bridge the next launch if Operations owns the checklist by 30 August.

Or:

If product is expected to approve commercial exceptions, I need a declared decision boundary and access to margin and contractual risk. Otherwise I can provide product evidence, but the commercial owner should decide.

When the disagreement concerns outcomes, confidence, or commitments, use the system in Managing Stakeholder Expectations.

When the PM has become the sole route between functions, Cross-Functional Collaboration in Product Management addresses the team-level failure behind the handoffs.

A hypothetical week under review

Consider a fictional PM in a B2B software company. The example is invented and claims no result.

Their week contains a pricing recommendation, incident updates, approval of a launch exception, repair of a recurring adoption report, and scheduling plus notes for three cross-team meetings.

The pricing recommendation is core product decision work. It needs customer evidence, economic constraints, credible options, and a recommendation.

Incident updates are temporary glue because the communications owner is on leave. The arrangement has a substitute owner and ends on that person’s return.

The launch exception is delegated ownership only if the PM has authority inside explicit legal, commercial, and operational limits. If an executive still approves silently, the PM is coordinating approval.

The adoption report exposes a missing analytics capability. Repairing it once may clarify the requirement. Repairing it every week hides the unowned service.

Meeting logistics are administration. The group can reduce the meetings, rotate the work, or assign support. Keeping the work with the PM remains an option, but it must compete visibly with product analysis.

The inventory shows that renewal research was postponed. The PM does not claim that every non-core task should disappear.

They propose an operating contract: cover incident communication until a named date, return launch authority to the commercial owner, fund an analytics decision, and rotate meeting administration.

The manager can reject parts of that proposal. What they cannot do honestly is preserve every demand while pretending no product work is being traded away.

Review whether the system changed

Revisit the contract after two or three working cycles. Do not score success by a cleaner calendar alone.

Ask:

• Did core product decisions receive the evidence and attention they required?

• Did temporary work expire or acquire a real owner?

• Did delegated decisions gain usable authority?

• Did a missing capability receive a decision rather than another workaround?

• Did administration become smaller, fairer, or easier to route?

• Would the work continue if the PM were absent?

A senior product manager may reasonably carry broader decisions than a less experienced colleague. Breadth is not the defect. Unbounded demand without matching authority, capacity, or trade-offs is.

The strongest boundary is not “product managers never do this.” It is “we know why this work sits here, what it displaces, and when that choice will be reviewed.”

That keeps flexibility available without turning competence into an invitation to own every unresolved problem.

Sources

• Tang and Vandenberghe: Role Overload and Work Performance (two cross-sectional employee-manager studies, reported as N = 212 and N = 191 in the abstract, plus a two-wave panel of 99; not product-management research, and it does not test this article’s classification or operating contract)

• UK Health and Safety Executive: Management Standards — Demands (official guidance on workload and achievable job demands; not evidence that a particular product operating model causes better outcomes)

Read next

• Product Org Design: Build the Decision System, Not the Chart

• Managing Stakeholder Expectations: A Practical System for Product Teams

• Cross-Functional Collaboration in Product Management