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.

This is characteristically dry press release language, but the stats are interesting:

Deezer, the global music experiences platform, is now receiving almost 75,000 AI-generated tracks per day, representing roughly 44% of the daily uploads. This amounts to more than 2 Million AI-generated tracks uploaded per month. Thanks to Deezer’s industry unique measures, consumption of AI-generated music on the platform is still very low, between 1-3% of the total streams. In addition, a majority (85%) of these streams are detected as fraudulent and are demonetized by Deezer.

I’m simultaneously surprised (but not, because grifters) that the amount of uploads is that high, and surprised (but not, because music lovers) that it’s generally a very unsuccessful way to make money. My continuing refrain will be that let’s use AI for the things that it’s good at, and leave the really important stuff (like art) to humans.

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…

This post on org design really resonated.

Most companies today are using AI the way you’d use a faster horse — to make the existing structure run a little better. The companies that pull ahead will be the ones willing to ask a harder question: what would we build if we were designing this organization from scratch, today, knowing what AI can do?

We have to seriously rethink the SDLC, design it from scratch in the context of how our own organizations work. It’s not about a global “right” process any more. The question now becomes “How can the humans in our team, at our company, at this point in time, work best together to serve our customers?”

Oh, this is very good. On the classic take that the core characteristic of outstanding engineers is “laziness”:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones.

The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

This is exactly why I practice Fear-Driven Development, and why everything I do in code includes multiple versions of asking Claude Code “do we need this?” and “is this adding bloat?”