Product Management Productivity: Improve the Flow of Decisions

A product manager can clear messages, update tickets, attend every meeting, and leave the important decisions exactly where they were on Monday.

The activity is real. So is the exhaustion. Neither proves that the product moved.

Productivity in product management is the responsible flow of decisions from an unresolved question to a usable commitment, rejection, escalation, or learning step.

Speed alone is unsafe. A quick decision can ignore evidence or transfer risk. The unit is not a task completed; it is a decision that can now change what people do.

That shift exposes a different set of constraints: queues, too much work in progress, unavailable authority, fragmented evidence, coordination load, and interruptions that quietly rewrite the week.

Separate selection from flow

Prioritisation decides which work deserves scarce capacity and what will be sacrificed.

Productivity begins after that choice. It asks whether the selected decisions can move through evidence, consultation, authority, and follow-through without becoming a permanent waiting room.

How to Prioritise covers the upstream trade-off. A ranked list cannot answer why the first item has waited ten days for one approver or why five teams are preparing the same decision differently.

Define a decision as narrowly as the next commitment requires.

“Improve onboarding” is work. “Choose whether identity setup remains mandatory before a first project can be created” is a decision.

The second form names a choice that can be framed, evidenced, owned, and closed.

Make the decision queue visible

Create a ledger for consequential decisions, not every task.

Decision to be made
Why it matters now
Current owner
Evidence or consultation required
Current state
Waiting since
Next commitment after closure
Reopen trigger

Use four states:

• candidate: relevant, but not yet admitted to active work;

• active: receiving meaningful attention or evidence now;

• waiting: blocked on a named input, authority, or event;

• closed: committed, rejected, escalated, or converted into an explicit next learning step.

“In progress” is too generous. A decision untouched for a week because six others entered the system is waiting, even if its document remains open.

Do not compare age across unlike classes without context. A reversible interface choice and a regulatory risk acceptance should not share one service target merely because both appear in the ledger.

Diagnose where the time goes

For each waiting decision, identify the dominant delay.

Evidence delay

The owner cannot choose responsibly because the required observation, analysis, technical fact, or customer input is missing.

The response is not “do more discovery”. Name the evidence, the decision it controls, and the smallest credible way to obtain it.

Authority delay

The recommendation exists, but nobody can state who may commit it or accept the consequence.

More analysis will not repair absent authority. Escalate the ownership question with the options and risk already visible.

Coordination delay

Several people hold parts of the answer, but no interface joins their inputs into one decision.

Cataldo and colleagues used archival data from a large software project to model who needed to coordinate because of task dependencies.[1]

They found that coordination requirements changed over time and extended beyond formal team boundaries. Greater congruence between required and actual coordination was associated with shorter development time.

This was one software project, and the relationship was observational. It does not show that adding meetings will improve product decision flow.

The useful question is narrower: are the people coordinating because the work requires it, or because the organisation has no clearer decision interface?

Rework delay

The decision repeatedly returns because its boundary, evidence standard, or consequences were never agreed.

Record why it reopened. New evidence is healthy. A late approver, an unstated constraint, or a changed question indicates a broken decision design.

Attention delay

The owner has authority and evidence but cannot protect enough continuous attention to frame and close the choice.

This may be personal, but repeated attention delay across a team is usually a demand-system problem.

Treat work in progress as elapsed time

Little’s 1961 queueing theorem relates the average number of units in a system, their average arrival rate, and their average time in the system as (L = λW).[2]

The proof assumes finite means, strict stationarity, and a metrically transitive arrival process with nonzero mean.

Product decisions are not identical queue units, and product work is rarely stationary. The theorem does not prove that one WIP limit will increase a team’s output.

It does make a useful relationship hard to ignore. In a stable system with unchanged throughput, more average work in the system corresponds to more average elapsed time.

Starting another decision can create the feeling of responsiveness while increasing the time every active choice spends waiting.

Set an explicit active-decision limit at the level where attention is genuinely shared. That may be one PM, a product trio, a team, or a leadership forum.

When the limit is full, a new decision must replace an active one, use an urgent path, or remain a candidate. The policy matters more than the number.

Saying No in Product Management explains how to expose the commitment displaced by a new request.

Route interruptions by consequence

An interruption is not automatically waste. An active incident, material customer harm, or invalidated assumption may deserve to change the week.

The problem is accepting every arrival through the same channel.

González and Mark observed analysts, software developers, and managers and reported highly fragmented work.[3]

In their coding, people averaged about three minutes on a task and a little over two minutes with a tool or document before switching.

The study reflects early-2000s information work and its own observation scheme. It does not estimate the switching cost of a modern product manager or prove a universal attention span.

Mark, Gudith, and Klocke later ran a laboratory experiment with 48 participants performing a simulated email task.[4]

Interrupted participants completed the primary task faster without a measured quality difference, but reported more stress, frustration, time pressure, and effort.

Most participants were university students, and the task was simulated. The study does not show that interruptions improve PM output or quantify a workplace productivity loss.

Together, the findings argue against a simple story that every interruption merely adds minutes. People may compensate by changing pace and effort, while the strain remains invisible in a completion metric.

Use three routes:

• interrupt now: current harm, external deadline, or evidence that makes active work unsafe;

• review at the next checkpoint: relevant input that may change a live decision but does not require immediate response;

• admit through the queue: a new request or question that needs an owner and trade-off before it becomes active.

Publish the routes. A private focus technique cannot protect work when colleagues reasonably believe every message requires immediate product attention.

Run a weekly decision operating system

The following routine is an editorial operating model, not a validated productivity method. Adapt its cadence to the product’s risk and decision tempo.

Open the week with flow, not status

Review the decision ledger with the people who share authority or critical evidence.

Close stale candidates, identify waiting decisions, and choose which active items can receive meaningful movement this week.

For every active decision, name one next change of state: obtain evidence, complete consultation, make the commitment, escalate authority, or stop the work.

Protect decision-making work

Put the work required for closure on calendars before filling the week with reporting.

This may be analysis, writing the frame, speaking with affected users, reviewing a technical constraint, or preparing the decision forum.

A protected block is not “focus time” in the abstract. It is attached to a named decision and expected state change.

Batch predictable coordination

Create a reliable checkpoint for recurring consultation with data, design, engineering, commercial, legal, security, or operations partners.

Do not wait for the meeting when delay creates harm. The checkpoint exists to keep ordinary dependencies from generating ad hoc interruptions all week.

Replan only on a declared trigger

Change the active set when evidence invalidates the frame, a real obligation enters, authority changes, or another decision becomes materially more consequential.

Do not rebuild the week because a new request is visible or a sponsor asks for an update.

End by closing loops

Review what changed state. Record decisions, owners, consequences, and reopen triggers.

For anything still active, state whether it is progressing or waiting. If it is waiting, name the missing input and the person who can supply it.

The weekly review should reduce memory work. It should not become another presentation about activity.

A fictional week with too much motion

Consider a fictional senior PM working on an enterprise administration product. The example is invented and claims no result.

The active list contains an access-policy change, a pricing exception, a renewal-risk request, a research synthesis, an analytics discrepancy, and an integration commitment.

The PM has tasks for all six and meetings for five. Only the access-policy change has a declared decision owner.

The flow review reveals different delays. The pricing exception needs commercial authority. The analytics discrepancy needs a data definition. The integration promise has two conflicting owners.

The PM does not create a better personal to-do list.

The pricing choice is escalated with its trade-off. The data question becomes a bounded evidence request. The integration commitment leaves active work until authority is resolved.

The example asserts no faster delivery or better decision. It shows how a crowded week can contain several system problems disguised as personal workload.

Know when the constraint is organisational

Personal practice can improve an unclear note, a neglected follow-up, or an overfull calendar. It cannot repair a system that continually produces unowned work.

Treat the problem as organisational when:

• leaders introduce work without naming what leaves;

• several roles can reopen a decision but none can close it;

• critical evidence is controlled by a queue with no service boundary;

• one shared specialist integrates otherwise independent teams;

• the PM is accountable for an outcome but cannot commit relevant resources;

• urgent requests have no entry policy;

• conflicting goals remain active because no authority will choose;

• reporting demand consumes the attention needed to make the decisions being reported.

Bring evidence about the system: decision age, waiting reason, reopen events, active WIP, interruption source, and recurring dependencies.

Do not diagnose personal resilience when authority and demand are structurally inconsistent.

Product Portfolio Optimization covers allocation across investments. Decision Frameworks covers one contested choice.

Productivity connects them at the operating layer: selected decisions should move without hiding waiting, strain, or missing authority.

Sources

1. Cataldo et al.: Identification of Coordination Requirements (archival analysis of one large software project; observed coordination congruence does not establish causality or transfer to product teams)

2. Little: A Proof for the Queuing Formula (queueing theorem under stated mathematical conditions; not a product-work forecast or proof of a universal WIP policy)

3. González and Mark: Constant, Constant, Multi-tasking Craziness (field observation of 14 people at one investment-management technology team; 15.81% of events were unclassified, and the study is not a modern PM productivity estimate)

4. Mark, Gudith, and Klocke: The Cost of Interrupted Work (laboratory email-task experiment with 48 participants, 81% of them German university students; not a product-management field study)

Read next

• How to Prioritise: Make Trade-offs, Not Just Rankings

• Saying No in Product Management: Make the Trade-off Explicit

• Product Portfolio Optimization: Fund the Next Decision

• Decision Frameworks for Product Leaders: Make Conflict Decidable