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.

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…

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.

I’ve covered “root cause” thinking in incident reviews before, and Lorin Hochstein takes aim at a related issue: AWS’s “Correction of Error” terminology:

I hate the term “Correction of Error” because it implies that incidents occur as a result of errors. As a consequence, it suggests that the function of a post-incident review process is to identify the errors that occurred and to fix them. I think this view of incidents is wrong, and dangerously so: It limits the benefits we can get out of an incident review process.

What makes his critique compelling is the observation that production systems are full of defects that never cause outages:

If your system is currently up (which I bet it is), and if your system currently has multiple undetected defects in it (which I also bet it does), then it cannot be the case that defects are a sufficient condition for incidents to occur. In other words, defects alone can’t explain incidents.

This applies to product work too. When users report problems, our instinct is to find “the bug” and fix it. But often the bug has been there for months—what changed is the context around it. A new user flow, a spike in traffic, a feature interaction we didn’t anticipate. If we stop at “fixed the bug,” we miss the chance to understand why the system let that failure through in the first place.

Jason Knight wrote about a fascinating disconnect between how B2B product leaders rate themselves and how their teams see them. The data from his survey is striking:

Across the board, B2B Product Leaders think they’re doing pretty well in all of these areas, but B2B IC PMs are not convinced. The difference is stark, and they can’t both be right.

The survey measured six core responsibilities—setting strategy, aligning teams, enabling prioritization, fostering ownership, removing blockers, and investing in people. In every category, leaders rated themselves significantly higher than their ICs rated them. Jason offers three possible explanations: leaders are doing poorly and don’t know it, leaders are doing well but not communicating it, or ICs have unreasonable expectations. He concludes:

Product Leaders need to do a much better job of setting expectations within their teams and communicating with them openly and well. IC Product Managers need to do a much better job of understanding the constraints of their business context and, indeed, the business they work for.

I keep coming back to the iceberg effect he mentions—where only some of the work someone does is visible. This cuts both ways. Leaders underestimate how opaque their work is to their teams, and ICs underestimate the constraints leaders are working within. The gap isn’t just about performance; it’s about mutual understanding.

Natalia Quintero wrote about what she’s learned from talking to more than 100 companies about AI implementation. This part about the problem with early adopters and isolated workflows stood out:

AI doesn’t spread like other software. Think about Asana. If one person decides to organize their team’s tasks there, everyone benefits automatically because the work is more organized, and someone on the team has taken responsibility for that organization. You don’t need to learn the tool to get value from your colleague using it. AI doesn’t work that way. If you develop workflows around how you work, that value doesn’t automatically translate to the rest of the company. Your prompts, your GPTs, your automations—they’re built around your context, your processes, and your way of thinking. They don’t transfer.

That’s the adoption problem in a nutshell. A power user’s AI setup is like their personal note-taking system—valuable for them but not portable. It explains why enterprise rollouts don’t work the way everyone expects.

The recruiting firm example is good: they trained 10 champions who built tools their peers wanted to use. One person automated scheduling coordination (saving 2–10 hours per task), and suddenly 30 others got curious. Peer-to-peer beats top-down mandates.

(If you’re curious about my setup, I wrote about it here)

Here’s Leah Tharin with a good reminder of what it means to ship, and how AI can (and cannot) help. In short, building is only one part of creating valuable products. Shipping involves:

• Ideation: There’s an idea
• Development: You build the idea
• Validation: You validate whether what you think the idea does is actually happening

Yes, vibe coding tools like Lovable et al. help you to ship things faster, but only as long as these ideas struggle with the “development” part and don’t need Ideation and Validation.

Source: AI’s “Just Ship it.” problem →

I think we’ve all seen the internal Shopify memo on requiring teams to use AI. This is a great article on what happened next. I especially love the internal tools Shopify built to make adoption easier:

Employees can use the LLM proxy to build the workflows they need. They can select from different models, which are updated with the latest versions as soon as they’re released. There’s a collection of MCPs, and all it takes is asking the proxy (or another tool like Cursor) to access them. There’s even a stable of agents already created by other people for anyone to use. It’s a one-stop shop for everything someone needs to use AI.

Source: From Memo to Movement: Shopify’s Cultural Adoption of AI →