Whiplash is what happens when change occurs without communication. The gap between what leadership knows and what everyone else knows is where most work whiplash gets manufactured. And the only thing that closes that gap is treating “who needs to know about this?” as a non-optional follow-up question every time a decision gets made or a priority shifts.
— Molly Graham, Work Whiplash
In a practical example of brain fry, Petra Wille recalls some of her personal experience during coaching:
The product leaders and CPOs I coach tell me their people are completely fried before lunch—after a morning of generating content and reviewing outputs in Claude, Gemini, and ChatGPT, they’re just done. Adapting to this new type of work doesn’t make them more productive because they’re out of energy and brainpower by noon.
So conversations about how we actually work—what a sustainable rhythm looks like for humans in this new setup—still needs to happen.
This has become a pretty common complaint/concern among people I talk to, and it gets me too. I’ve been sitting on posting this link because I wanted to include some kind of proposal but… I got nothing. Just agreement with Petra that we really really need to figure out how to work in this new world in a way that avoids mass burnout.
Yes, it’s a clickbaity title, but if you read this as an essay about what to care about at work, it has some good reminders like this:
“Care less” is directionally right, but let’s get more specific. The real shift is learning to place your care deliberately — to get good at telling the difference between what’s strategically important and what’s just noisy. A lot of what happens inside companies is frustrating without being important. Reacting to a messy call that you personally wouldn’t have made as if it’s a strategic risk is what drains you. So is holding on to every detail as if it’s existential. Not everything deserves to be treated with equal importance. A gut check that helps: Will this matter in a year? If not, it probably doesn’t deserve much energy now. What’s the worst-case scenario? Often, it’s not that bad.
Melissa Perri chimes in on how AI is changing the product role, and makes the case for measuring PMs by decisions changed and outcomes shipped, not by tickets written and docs generated:
If you are a PM, stop measuring your productivity by how many tickets you wrote, how many pages of documentation you spun up, or how fast you closed the loop on the last sprint. That work is going to keep getting easier.
Measure your productivity by how often you changed a decision that mattered, how often you saw around a corner, how often a senior leader walked out of a room thinking differently because of something you said. How often your shipped features translate into real customer outcomes is what matters.
Everything I read is saying the same thing right now: judgment, customer understanding, and the ability to change a senior leader’s mind in a room are the skills that AI can’t touch. I’m not disagreeing necessarily, but I do think that narrative is missing a big new skill that is needed. I wrote about this in What actually changed about being a PM:
I was talking to my wife the other day about what I’m doing, and she asked the obvious question: “Why are you automating your job away?” My answer: the people who automate their own jobs away are the ones who become more valuable, because the craft is now in orchestration — setting up the layers so the AI does the right thing.
I also continue to think about this quote from Org Design in the Age of AI and how the focus is shifting from “information movers” to builders:
The old PM spent most of their energy making ideas legible to other people. The new PM validates directly — prototyping, running data analyses, generating first-pass implementations. […] The managers who thrive will be the ones whose real contribution was always judgment, coaching, and navigating ambiguity — not routing information.
I’m a big fan of Now/Next/Later roadmaps, and I think it adapts particularly well to an AI-assisted world, so I was curious to read Teresa’s Take on different roadmap models. It’s a fun trip through different prioritization frameworks, and I do like her reframing of the Now/Next/Later approach:
Here’s what I’ve seen work best: Take the Now Next Later format, but instead of filling every column with features at different levels of detail, change the type of content as you move across columns. […]
Specifically, I list solutions in the Now column, opportunities in the Next column, and outcomes in the Later column.
The single biggest challenge for new managers — giving up the responsibility for the product… for the building. Learning how to give accountability for projects of significance to the team. It’s an essential set of complex skills involving trust, communication, and, most importantly, judgment. Failure to understand delegation is failing to be a leader. Senior or not.
— Michael Lopp, The Slide
There is no doubt that this post was at least 80% written by AI but I’m not even super mad about it because that is just the way of the world now, and the summary it generated from how Uber works is actually legit interesting:
A prototype without a PRD can drift away from the problem the team intends to solve. A PRD without a prototype can remain abstract, leaving room for inconsistent interpretations. […] If going from idea to prototype is now fast and cheap, the PRD can no longer be the primary place where ideas are defined. Its value increasingly lies in capturing intent, tradeoffs, success metrics, and decisions.
The PRD as an artifact is in the spotlight right now in a way that I think is really healthy. Should it remain but change its JTBD? Should it be an eval instead? Who knows. Let’s figure it out together…
I have decided that in this new AI era I will be practicing FDD. Fear-Driven Development. Every time I send a pull request, which happens a lot now, I'm terrified of an engineer sending it back to me and asking me to please stay in my lane and stop sending them slop. So I plan, write specs and implementation plans, test thoroughly, and I don't trust the agent's inevitable confidence.
I'll come back to that, but let me first frame what this post is about. The loudest take on PM work right now is that AI is collapsing the role — that we're one product cycle away from redundancy, or being reduced to prompt jockeys. That hasn't been my experience at all. The job got more hands-on, harder (brain fry is real), but also a lot more fun. What follows is what actually shifted for me over the last 5 months at Cloudflare, what didn't, and a couple of things I got wrong.
Braintrust makes a good case (apologies for the X.com link…) for rethinking how PMs work on AI products: the eval replaces the PRD.
An eval is a structured, repeatable test that answers one question. Does my AI system do the right thing? You define a set of inputs along with expected outputs, run them through your AI system, and score the results using algorithms or AI judges.
The eval becomes both the spec and the acceptance criteria. The directive to engineering:
“Here is the eval. Make this number go up.”
That’s very different to how most teams work today, but I can definitely see the industry moving this way. Product usage generates signals, observability captures them, and evals turn them into improvement targets. The PM’s job is to define what “good” looks like in code and curate the data that reveals what “bad” looks like.
The PM skills that transfer are the same ones that always mattered — discovering needs and opportunities, and making judgment calls about what to build for business value. The difference is that instead of a document that describes the intent, you have a test suite that encodes it.
Amol Avasare, Anthropic’s Head of Growth, said on Lenny’s Podcast that maybe PM jobs are not going to shrink as much as we may have thought…
Rather than immediately replacing PMs, AI is currently increasing engineering leverage the fastest, which creates new pressure on PMs and designers. In larger organizations, that may actually increase the value of PMs who can guide priorities, manage alignment, and sharpen decision-making—especially as engineers take on more “mini-PM” responsibilities.