When the Product Manager’s Plate Is Too Full

0:00Is the problem switching, or too much work?

Is the problem that you keep switching—or that there is simply too much work?

Picture a product manager working on several AI features at once. One thread is an evaluation question. Another is a customer request. A third is waiting on engineering. There are sales questions, compliance questions, and a model that needs checking again because the answer changed. The work may be asynchronous. That doesn’t mean it’s mentally quiet. Fiona Fung describes a high load from checking many ongoing workstreams and remembering the state of each one. As she puts it, “with routines and everything being more async, I think there is starting to be a high load on our context switching.”

And the new AI tools can add another layer. Lenny Rachitsky imagines having twenty agents running at once. That could mean repeatedly checking progress and reconstructing what you were doing in each place. “There’s endless checking in and reviewing,” he says. Fung’s response is telling. She blocks time just to catch up with the asynchronous work she has already started. The agents didn’t eliminate the need for focus time; they left her with more asynchronous work to gather back together.

What I take from this is that the first question isn’t, “Which productivity system am I missing?” It’s, “What kind of overload is this?” If interruptions are the main problem, a little protected time may help. If there are too many active initiatives, better focus may simply let you carry an impossible load more efficiently. And if ownership is unclear, you may keep getting pulled back into decisions that nobody else has made.

Here’s a low-bandwidth way to find out. For the next one or two weeks, don’t build a dashboard. Once a day, write down six things: the initiatives currently active, the number of meaningful interruptions, meeting hours, after-hours work, whether you recovered outside work, and one signal of delivery quality. That quality signal might be a missed decision, a rework loop, a late customer response, or a piece of discovery you had to skip. Pick one and use it consistently. The point isn’t to optimize your life by spreadsheet. It’s to see whether the pattern changes when you create a small amount of protection around your attention.

At the end, ask three simple questions. Did interruptions fall? Did the number of active commitments stay the same? Did quality or recovery improve? If interruptions fall and the work feels clearer, keep the protection. If interruptions fall but the same number of commitments still collide, the problem is probably scope or capacity. If the commitments are hard to name because every request is “temporary,” you may be looking at unclear ownership rather than a personal focus problem.

John Cutler describes one version of that structural problem: someone has a primary job, then keeps getting pulled into disparate ad hoc requests. He calls that “a good sign something is off.” In another example, organizations spread engineers and designers across many efforts as if people were interchangeable. A PM can experience a similar setup from the middle: every team needs a little attention, so every initiative stays alive. A focus block can protect an hour. It cannot stop shared people from being assigned across many projects. It cannot resolve two deadlines that require the same specialist. And it cannot turn a request with no owner into a decision with an owner.

There’s an important counterexample, though. Switching isn’t always a failure. Ezinne Udezue notes that startup PMs may move among product, execution, and other functions several times in a day. Shreyas Doshi makes a similar point about role boundaries: a PM may need to go deeper into technical execution when the team lacks an engineering manager or when the PM has unusual technical strength. Ravi Mehta describes a setup where one PM can support many engineers because product work is genuinely shared. The founder sets strategy. Designers stay close to customers. Engineers help define the product. Researchers surface unmet needs. Marketers understand the route to market. In that environment, the PM isn’t carrying every product responsibility alone.

So the useful test may not be whether you switch at all. If I were in your shoes, I’d try one protected catch-up block and one visible list of active initiatives, then watch what happens. Do requests wait until the block ends? Does someone help remove an item? Or does the list keep growing while you work earlier and later to keep up?

A two-week experiment can tell you whether attention is leaking. It can’t decide what the organization should stop doing.

5:16Make the trade-off someone else can see

Once you can see the competing work, the next problem is making the trade-offs visible. Otherwise, several requests can feel like one overloaded list.

David Pereira describes a moment like this. Several stakeholders each brought him something they said was highly important. His response was unusually direct: “I cannot say what is more important, because each one of you come to me saying that is highly important.” So he brought the stakeholders together. He said the concern wasn’t just coordination. It was a shared question about the business result. In his words, “what we need to do is to move from coordination to collaboration.” Once the overload was visible, two stakeholders parked their requests. Then the group discussed what to pursue.

That gives you a useful move when you don’t control the roadmap. Don’t silently rank requests in your own head. Put them in one short view: the outcome, the request, the evidence, the effort or dependency, and what gets delayed if it moves up. Then ask for a decision from the people who can make it. You’re not saying, “I refuse to do this.” You’re saying, “Here are the choices. Which trade-off do we want?”

The message can be simple. “We currently have A, B, and C in flight. A protects the customer commitment. B addresses the sales request. C is the AI evaluation work we need before we can safely expand. With the current capacity, we can’t do all three at the same level. My recommendation is A plus the smallest useful slice of C. If B is more important, what should we pause, and who should confirm that decision?” Jina Yoon’s version of this kind of communication starts with the problem and impact, explains what has been investigated, presents an alternative, and names the trade-offs. The point is to make a recommendation, not just forward the conflict.

Deadlines need the same treatment. If a date is real, Nan Yu’s advice is blunt: protect the people doing the work and cut scope. “The engineer is working on it. They don't get to work on anything else. ... As a PM, your job is to just cut as much scope as possible.” That doesn’t mean every date should automatically receive this treatment. First ask whether it is a real deadline. The team should know what the date requires and what work must move out to protect it.

A practical script is: “We can keep the date, or we can keep this scope, but we can’t guarantee both with the current capacity. My recommendation is to ship the decision-ready version on the date and move these items out. If those items must stay, I need an explicit decision to move the date or add capacity.” And don’t wait until the miss is obvious. Wes Kao’s rule is, “Speak up at the first sign that you might miss a deadline.” Early notice gives a manager information to help triage.

There’s another trade-off hiding in this plan: your future career. It’s easy to turn career preparation into one more project, with courses at night and a portfolio on the weekend. That can recreate the overload you’re trying to fix.

A lower-bandwidth approach is to make the current work more legible. Tom Verrilli encourages product people to “Start doing IC work in the role you're in would be my push.” That means doing practical product work in the role you already have, rather than collecting more abstract advice. Leah describes a related model: “Build ‘modular expertise’ – deep in one area, conversational in others.” For an AI PM, the deep area might be evaluation, workflow design, or a particular customer problem. The surrounding skill is translation across technical, business, sales, and compliance perspectives.

Try a tiny career loop inside work you already have. Pick one area to understand more deeply. After an important decision, save five lines: the problem, the evidence, the options, the decision, and what happened afterward. Once a month, turn one of those records into a short case study for yourself. That gives you evidence for a future move without creating a second full-time job. It also improves the work in front of you, because writing down the decision forces the trade-off to become clear.

And treat your health as a decision signal, not another metric to optimize. Sherry Walling describes burnout as a continuum with three clusters: exhaustion, cynicism or detachment, and reduced effectiveness. Jason Fried argues that intense periods need recovery, and says managers should act when they see repeated early, late, or weekend work. If those patterns are becoming normal, managers should intervene rather than treating the problem as an individual time-management choice.

For the next week or two, bring one visible trade-off to the people who can decide. Protect one real deadline by naming what will not fit. Capture one decision record from work you already do. Then look at what changed. If the system responds, keep the loop. If every “no” becomes another “yes,” or your recovery keeps shrinking, stop compensating for the system and escalate the conditions themselves. The question is no longer how to fit more into the role. It’s what the role can responsibly contain.