Is Product Management Stressful?

I counted once. On a random Tuesday I wrote down every time I switched topics. Not switched apps. Switched topics. The topic I was thinking about changed. By 4 PM I was at 23. Twenty-three different things I'd thought about in a single day. Sprint velocity. A customer's Marketo integration failing. Whether the mobile onboarding flow needs a tooltip or a full walkthrough. A Slack message from my manager, Priti, asking if I'd reviewed the competitive analysis from the analyst team. A 1:1 with one of my engineers, Cole, where he told me he was thinking about leaving and I had to figure out, in real time, whether this was a venting session or an actual flight risk that I needed to escalate to his manager.

And none of those 23 topics were bad on their own. Each one is a normal part of the job. The stress isn't any single context switch. It's that my brain never gets to go deep on anything before it gets yanked somewhere else. By the end of the day my brain feels like a browser with 40 tabs open and no memory left. My partner, Liz, she's a tax accountant. During busy season she works 55-hour weeks, which is hard, but she told me once that her stress is "too much of the same thing." Mine is the opposite. Too much of too many different things. She stays on one tax return for three hours. I haven't been on one topic for three hours since I started this job.

The worst part is that nobody else sees it. My engineers go deep on their code for hours. My designer Gio spends an entire afternoon on a single screen. They think I'm just "in meetings all day." They don't see that each of those meetings requires me to completely reload a different mental model. Going from a sprint retro to a customer escalation to a strategy review to a 1:1 with Cole is not four meetings. It's four different brains I have to wear, back to back, with a five-minute bathroom break in between.

Last quarter my team shipped a payments reconciliation feature that reduced manual matching time for finance teams by about 40%. That's a real, measurable improvement. It took 14 engineers, 3 designers, 2 data scientists, and me over seven months to get it out the door. When it launched, the VP of Engineering sent a company-wide Slack message congratulating the "Reconciliation squad" for an amazing job. My name was not in the message. The engineers were named. The tech lead, Marina, was named. The designer who did the final UI pass was named. I was not named. And that's fine. I'm not bitter about it. The team built it.

But here's the other side. Six months earlier, I'd made the decision to prioritize the reconciliation feature over a different project that our head of partnerships, a guy named Lloyd, had been pushing for. Lloyd wanted a partner API integration that he thought would bring in $3 million in new revenue. I looked at the data, talked to 12 existing customers, ran a revenue impact model, and concluded that the reconciliation feature would retain more revenue than the partner API would generate. I was right. Churn in the reconciliation user segment dropped 22% after launch. But nobody associates that churn reduction with my decision to prioritize it seven months earlier. The timeline between a PM decision and its outcome is so long that the causal chain becomes invisible.

The stress is this: I am accountable for outcomes I cannot directly produce, on timelines where my contribution is invisible. When things go right, it's the team. When things go wrong, it's "why did we prioritize this?" which is the PM question. I own the downside. The team owns the upside. My wife Natalia is a litigation attorney. She said it sounds like her job except she at least gets to stand in front of a judge and make her case directly. I make my case in a Google Doc and then wait seven months to find out if it was the right case.

I'm in a meeting with four engineers and they're talking about whether to refactor the authentication service to support passkeys. And one of them, Yuri, is drawing a diagram on the whiteboard showing the token exchange flow and another one, Deepa, is pushing back on the migration timeline because of a dependency on a third-party identity provider we use called Okta. And I'm sitting there nodding. Because I understand maybe 70% of what they're saying. The other 30% I'm Googling under the table. I once Googled "SAML assertion timeout" during a meeting and then two minutes later had to ask an intelligent question about it. Nobody noticed. I think.

The imposter syndrome in PM is specific. It's not that I don't know anything. It's that everyone around me knows more about their thing than I know about any one thing. Yuri knows the auth system better than I do. Deepa knows the infrastructure constraints. Our researcher, Jia-Wei, knows the user data. The sales engineer who joined the call from Dallas knows the customer's security requirements. My job is to synthesize all of that into a decision. But the synthesis only works if I understand enough of each person's domain to weigh their input correctly, and there are days where I'm not sure I do.

I talked to my older brother about this. He's a dentist. He said "at least you can Google under the table. I can't Google 'is this a cavity' while I'm looking at the X-ray with the patient sitting there." Which is a fair point. But his expertise is deep and narrow. Mine is supposed to be broad and connective. And when you're 28 and 18 months into your first PM role, "broad and connective" sometimes just feels like "shallow and anxious."

At my level, PM is about 60% politics and 40% product. I manage four PMs. Each of them has a roadmap. Each roadmap has items that compete with other roadmaps for engineering time. Last month, our CEO, a guy named Harlan, decided that AI-generated lesson plans were the company's top strategic priority. Fine. Except that declaration meant one of my PMs, a woman named Iris, had her entire Q2 roadmap deprioritized. She'd been working on a parent communication portal for three months. Teachers were asking for it. She had seven customer interviews documented. And now it's shelved because Harlan watched a demo of ChatGPT at a conference and came back with "we need AI in everything."

I had to tell Iris. She took it professionally, but you could see the energy leave the room. Three months of work, seven customer interviews, a 14-page spec, all moved to "future consideration," which we both know means "probably never." And the thing that stresses me is that I agree with Iris. The parent portal was the right call. But Harlan controls the budget. The VP of Engineering, a guy named Cliff, controls the headcount. And Cliff already reallocated two of Iris's engineers to the AI workstream. So even if I fight for the parent portal, the people who would build it are gone.

I didn't sign up to be a politician. I signed up to build products. But at the director level, "building products" means navigating org charts, managing competing priorities between VPs, presenting to a board that wants AI buzzwords in every quarterly update, and making sure my team doesn't burn out while I absorb the political pressure they don't see. My wife Claudia says I come home from work looking like I've been in an argument. I haven't been in an argument. I've been in seven very polite disagreements where everyone smiled and nobody got what they wanted. That's worse, somehow.

I keep a spreadsheet. I log every feature request that comes in, who requested it, when, and what I said. In the last twelve months, I've received 247 feature requests. I shipped 31. That means 216 times this year, someone, a customer, a sales rep, an engineer with a pet idea, a support agent relaying feedback, heard some version of "no" from me. Sometimes I say "not now." Sometimes I say "we're evaluating." Sometimes I say "it's on the backlog," which we all know is PM for "it's in the place where ideas go to die quietly."

And each individual "no" is fine. I can explain the prioritization logic. I can show them the framework, the impact-effort matrix, the customer interview data. People nod. They accept it. But the problem is that it accumulates. By the time you've said no 216 times, there are 216 people in the organization who remember that you rejected their idea. Some of them are gracious about it. Some of them bring it up months later as evidence that product "doesn't listen." My sales lead, a woman named Taryn, sent me a Slack message last week that said "the customer asked about bulk export again, I know you said no in June but they're asking again." She didn't mean it passive-aggressively. But it felt like it. Because every feature request I say no to is a tiny withdrawal from a relationship, and after 216 withdrawals, some of those accounts are running low.

My therapist, I see a therapist every two weeks, she asked me if I have trouble saying no in my personal life. I said no. She said "interesting that the thing that drains you at work is the thing you're fine with at home." She's right. At home, saying no costs nothing. At work, every no has a face attached to it. Taryn's face. My engineer Kamal's face when I moved his side project out of the sprint. The customer in Portland who asked me directly on a Zoom call and I had to say it to their face. It's not guilt exactly. It's something closer to erosion.

Sunday nights. That's my answer. The stress of PM is Sunday nights. Because I know what Monday looks like. Monday is sprint planning at 9, a stakeholder review at 10:30, a customer escalation that came in Friday afternoon that I haven't looked at yet, three back-to-back 1:1s starting at 1, and then at 3:30 there's a "quarterly planning sync" that was supposed to be 30 minutes but always runs to an hour because our VP of Growth, a woman named Francine, uses every meeting to relitigate previous decisions.

The thing that stresses me isn't any single one of those. It's that there's no margin. There's no 45-minute block on Monday where I can think. Not react, not respond, not present, just think. About whether the checkout redesign is the right priority. About whether the mobile conversion number we're tracking is even the right number. About whether the reason our retention is flat is something we can fix with a feature or whether it's a market problem that no feature will solve. That kind of thinking requires space, and my Monday has zero space. By the time I get to the quarterly planning sync at 3:30, I've been in "response mode" for six and a half hours and I have nothing left. Francine asks me what I think about the Q3 retention strategy and I give a version of the answer I gave last quarter because I haven't had time to develop a new one.

My brother-in-law Terrence is an electrician. He works hard. Physical work, early mornings, real fatigue. But on Sunday night he doesn't dread Monday because Monday is concrete. He knows what he's doing: he's wiring a house. The scope is defined. The work has edges. My Monday has no edges. It's amorphous. It could go in any direction depending on what blows up first. And the anxiety of the amorphous, the not knowing whether Monday will be manageable or a five-alarm fire, that's what sits on my chest on Sunday night. Not the work itself. The possibility of the work.