This is the second summer in a row that I’m handing you a clip show. Last August I pulled together the best 14 product management resources from this blog, a list of the canvases, templates and frameworks that had accumulated here over 15 years of writing, and enough of you told me it was useful that I’m doing a version of it again. This year the list covers the posts themselves, specifically the ten you read most over the past twelve months. I’m out of the country for the first half of August, so rather than force out something half-formed from wherever I happen to be, it felt like a better use of the week to look back at what actually landed with you.

A pattern jumped out at me while I was putting this together. Almost every post on the list is about AI, which I expected, but the ones that did the best are the practical ones, the posts that answer a question a product person is trying to answer this week, rather than the ones where I take a position on where the industry is heading. I feel like that says something about where most of you are right now, which is somewhere between “we’ve bought the tools” and “we have no idea how to change the work around them,” and I suspect I’ll keep writing about that for a while.

Here they are, roughly in the order you read them.

1. Storytelling: an AI-era survival skill for product managers

This one was the runaway winner of the year. Once AI can generate the spec, the research summary and the competitive analysis, the artifact stops being the proof of your expertise, and the ability to tell a stakeholder why the work matters, in language that particular stakeholder cares about, becomes the thing that separates you. The practical part is tailoring the same insight for different rooms, leading with user friction for designers and with revenue risk for the CFO as an example.

2. Karpathy said vibe coding is obsolete. What he described instead is product management.

When Andrej Karpathy described “agentic engineering” and listed the seven activities that make it work, I read the list and recognized it immediately, because it’s product management with different words. The post walks through those activities and asks you to audit yourself against each one, which is uncomfortable in the useful way. The question I’d start with is whether you write specs that frame a problem worth solving or specs that describe a feature somebody already decided on.

3. How to write OKRs for an AI product

The most common mistake I see on AI teams is measuring the model instead of the human, so this post makes the case that a key result has to be a measure of human behavior, and then gives you three you can use right away. There’s an outcome KR for what people do with the AI’s output, a calibration KR for how often they feel the need to check its work, and a trust KR for how often they override it entirely. “95% accuracy” tells you nothing about whether anybody’s job got better, which is ultimately the only thing your executives will remember.

4. What “done” means when you’re shipping AI features

Traditional acceptance criteria assume the same input produces the same output, and that assumption quietly breaks the moment you ship something probabilistic. The post suggests writing acceptance criteria as distributions (“80% of inputs meet quality bar Y”) rather than as binary assertions, building the failure triage playbook before launch instead of after the first bad week, and rehearsing your rollback rather than documenting it and hoping. Teams tell me this is the one they forwarded to their engineering leads.

5. Training your PMs on AI tools is the easy part

Buying licenses and running a workshop is the cheap half of the problem, and this post is about the expensive half, which is giving people permission and protected time to use what they’ve learned on something other than the backlog. The teams that get real value are the ones where somebody explicitly said “spend the time you just got back exploring a customer problem we haven’t solved, and a failed experiment counts as a win.” That permission has to come from leadership not your training budget.

6. SAFe was bad for agility. For AI, it’s catastrophic.

I’ve been writing about my favorite punching bag, SAFe, for years (my 2021 post on it is still one of the most-read things on this site), and this sequel makes the case that quarterly planning cycles and synchronized release trains are structurally incompatible with software that behaves differently in production than it did in testing. The diagnostic question I’d put to your leadership team is when your teams last changed direction because of something a model did with real users, not in a test environment.

7. You can quantify cost. Here are four ways to measure judgment.

Once execution gets cheap, judgment becomes the differentiator, and the usual objection is that judgment can’t be measured, which this post argues is a not true actually. There’s a four-dimension rubric in there, scored across customer evidence, business impact, competitive context and organizational alignment, that you can bring into a prioritization meeting to make the reasoning behind a decision visible and arguable. It’s also, in many ways, the most useful coaching tool I’ve published in a while, because it gives you something concrete to point at with a PM who is struggling.

8. AI made execution cheap. That changes what “good work” looks like.

This one is the argument underneath most of the rest of the list. When the constraint moves off engineering capacity, the bottleneck becomes product clarity, and the risk stops being buggy code and starts being the very efficient and amplified production of things nobody needed. The implication for most organizations is unglamorous, which is that discovery gets more important exactly when everyone’s instinct is to celebrate how much faster they can ship.

9. How to prioritize your backlog when effort is no longer the constraint

RICE and weighted shortest job first both lean on an effort estimate, and this post suggests replacing that column with two others, asking what the work will teach you and how hard it would be to undo. Sort the results into a simple two by two, build the high-learning and easily reversible items now, prototype the high-learning items that are hard to undo, and leave the low-learning and irreversible corner alone.

10. How to collect product feedback when your AI gives every user a different answer

Your feedback mechanisms assume consistency, and as this post points out, the same user gets a different output on different days and different users get different outputs on the same day, which quietly invalidates most of what you’re collecting. The suggestions are to watch what people do after they get the output rather than asking them how they liked it, to review thirty to fifty real outputs a week against a three-question rubric with your attention on the worst ten percent, and to capture the input context and the user’s intent instead of reproduction steps.

What I’d add if the list were longer

A few that didn’t quite make the cut but that I’d still point people to: three habits that beat AI tool fluency, how product management can fix your AI integration problems, and AI made relationships, not features, the last defensible advantage.

I’ll be back to the regular Monday cadence in September. If one of these is worth a second read while things are slow where you are, I’d like to know which one actually changed something in how your team works, and which one you think I got wrong, since that tends to shape what ends up here next.