Hello!
This is 🕹 prodmgmt.world | Becoming Top PMs Together
I was listening to this podcast.
George from 🕹prodmgmt.world@nurijanian
every PM who thinks AI will kill product should watch this video (61 mins) Kevin’s got the better take: PM isn’t dying. Everything’s just shifting left. It's pretty grounded and devoid of hype. I distilled the main lessons into ~10 actionable takeaways for IC PMs & PM people
5:01 PM · Aug 18, 2026 · 4.84K Views
1 Reply · 3 Reposts · 24 Likes
Kevin talked about how he was fixing bugs, and the engineer told him: “Hey, I don’t want you to be fixing bugs. I can orchestrate a system that will fix all these bugs. What I want you to do is think about the strategy of the next three years and how we meaningfully shift the direction of our product. That’s what I want you to be thinking about instead.”
If code writing is abstracted away, engineers move up into orchestration and feature definition.
If engineers occupy that ground, the work that defined the PM is no longer the PM’s - so the PM is pushed up into 100% serious executive work.
If you became a PM because you mostly were attracted to building without writing code, then the role was only ever the instrument for reaching that goal through an indirect proxy. If LLMs now let you build directly, what role is that, and which role does a builder want now?
We’re all shifting left imprecisely and at different speeds, causing odd shapes in our EPD orgs. Most likely, status quo and old incentives will prevail, and we’ll just do it the old way in new clothes for a while. PRDs - but with prototypes, signed off in a meeting, thrown over the fence to eng who then take their agents and point them at your PRD and prototype and extract the specs out. Like trying to drive an F1 race car wearing a Mickey Mouse suit.
The shift needs to happen across the whole EPD at once. The CPO should be CPTO and also run design to make that happen.
Think about it this way. If the expectation is that a PM needs to start thinking about the higher level abstraction, they still need to make sure the value is delivered and — for lack of a better word — features are developed, and at a high quality.
If other parts of the EPD are not ready, and their expectations haven’t changed, or if that group change hasn’t been officially agreed upon and linked across departments, then the PM cannot proceed, even if the expectation has already been set for them.
This has always been true. If the engineering organization isn’t mature enough to accept that project management responsibilities will be largely absorbed into the engineering manager or lead role, then who will do it?
The PM is going to do it.
Immature engineering organizations often operate under the assumption that the Product Manager should be responsible for keeping things on track. This leads to PMs running daily stand-ups, leaving them with insufficient time for deep work. This is an outdated approach, and I hope we never revert to it. If you’re still working this way, I’m sorry. Perhaps you prefer it, in which case, I wish you the best. However, in my opinion, AI should now handle a significant portion of the making the trains run on time.
But the point is you can’t just tell PMs, “Okay, now think far ahead, you’re all strategists, you’ve got to have more judgment now,” without also saying, “Hey, by the way, the engineers are now going to take over more of that role — they’re going to be grilling the requirements you set out more broadly, to say this is what we’re actually building.”
Ok, but let’s imagine that we’re past that, and the whole EPD shifted. Now what?
As a PM, you have to reason through and establish some deep ground truths for your product. Outsource your reasoning so it scales.
Engineers should not have to ask about the principles or thinking behind a feature when they start working on it. This information should be part of the team’s context that agents share.
That’s not happening today.
You might even roll your eyes at this idea - we’ve all seen this crap on so many slides, and at so many all hands. The language of these principles leaves a taste in the mouth like dry sand, and a pain in the back of your head because you know these words are empty & dead on arrival.
I know what you’re thinking.
And how presumptuous of me to hand down my principles from the mount, to a team that doesn’t even report to me.
Many product professionals struggle with low self-esteem, often undermining ourselves and believing we aren’t supposed to be the smartest person in the room. So we play kinda dumb sometimes. But we are smart!
The goal isn’t to be the smartest and present principles that impress everyone.
The thinking behind the product just needs to be carefully crafted. It’s possible for someone else to do the same thing, but they may not have the time or inclination to do it. You are the one who needs to do it.
This is exactly the point.
Many people do this poorly. They do a surface-level job and do not think deeply about principles and values. They do not test their values and principles for the future to see if they will hold up or work together.
So rejoice friends, you now have permission to be the “CEO of the product”. But you do not have the permission to be a shitty CEO.
That rarely happens at any leadership level by the way.
Leaders are mostly terrible at exposing their mental models to their people and sharing their principles.
We already know that we can talk to an LLM or an agent, and it can build code and features for us. That capability is established; we’re all prototyping and building features with it.
What is not figured out is the layer of abstraction above that. In building features, what’s the next layer of abstraction?
How do you engineer and orchestrate a system that doesn’t require each engineer to trigger an agent on their local machine to review specific PRs or features? How do we make it so this is orchestrated in the cloud and happening without as much human intervention — but with enough human intervention that it doesn’t spin out into some weird slop?
And on the product side, same thing.
How can we ensure Product Managers move beyond simply drafting PRDs and strategy decks with AI? How can they expand their thinking and, in turn, feed that amplified thinking back into the system to create scalability? And what is this shared system they are all now a part of?
That’s the open question that’s unanswered. Nobody has a good answer for it.
Up until 2026, we were spiritually in the 1940s and early 1950s, when computers literally had no operating systems. Each program had to include its own hardware specifications and device drivers to run correctly, and the machine was dedicated to one user at a time for a scheduled period.
Now we’re in the 1970s and 1980s, when personal computers emerged and the situation improved only slightly. The market exploded with incompatible systems, each with its own OS - or none at all.
People have ideas, and people have implementations (someone should make a mini market map.)
I certainly have one of those with my PM OS.
Until we have a player that wins through a combination of most or all of these, like Microsoft did back in the day, we will still have this fragmentation.
Price advantage
Product quality
Distribution lock-in
Installed base momentum
Network effects
Ecosystem lock-in
History doesn’t always repeat itself, but it does rhyme. In a new iteration of this, one of the players - perhaps Anthropic, OpenAI, or SpaceX - might establish the OS standard through a combination of a new GitHub (Origin), widespread enterprise adoption, and strategic acquisitions.
If you want to buy prodmgmt.world, that’ll be:
PM OS is an AI operating system for product managers — a library of PM workflows, from writing PRDs to running multi-perspective document reviews, that runs inside your AI assistant.
Two big things this release: PM OS now runs natively in Codex, and it can learn your company’s writing standards from documents you’ve already written.
PM OS now runs natively on OpenAI’s Codex AI coding agent. Codex is now fully supported, along with Claude Code and Cursor. The Codex version is not a port; it functions identically to other versions because they are all generated from the same source code. When PM OS is updated, all versions are updated simultaneously. Features and behaviors on Codex will be the same as on other platforms.
Native means Codex treats PM OS as its own. Skills show up the way Codex expects to find them, invoked by their natural names. The specialist agents — the review panel, the PM thinking partner — arrive as real Codex agents, each with sensible permissions (reviewers can read your documents but not change them). Session automations run through Codex’s own hooks, so PM OS greets you, keeps your workspace tidy, and surfaces your daily prompt without any setup on your part. The connections to outside tools, like research services, come pre-wired in Codex’s own configuration. You install one ZIP and start working.
Every company writes PRDs its own way — mandatory sections, standing sign-offs, house phrasing for acceptance criteria. Generic AI tools don’t know any of that, so you re-explain it every time. Now you can hand PM OS two or three PRDs your team has already written, and it proposes the standards it finds in them: recurring data sections, review gates that always appear, your conventions and terminology.
You review each proposal with its supporting evidence, including the source document and how it was used. You can approve, edit, or skip each proposal individually. Nothing is saved unless you approve it.
A pattern that appears in only one document will not be proposed. This is because a single occurrence reflects a choice within that specific document, not a company-wide standard.
Your documents are analyzed only for their rules. Product decisions, customer names, or metrics are not carried over. This process results in a clean standards file that you can share with your team.
Files that appear to be credentials or sensitive information are rejected without being read. Once you set standards, they are applied to all new PRDs. New PRDs will include your specified sections, gates, and terminology from the start. Reviews will add an additional check, your standards, alongside the existing seven expert reviews (e.g., engineering feasibility, legal risk). Any findings from this review will cite the specific standard it relates to. This applies to all PRDs, even those written by hand. Your standards are stored in your own files, separate from the main system, so they are not affected by PM OS updates.
If you have not set standards, PM OS will offer to help you learn them once after your work is completed, without interrupting your workflow. If you decline this offer, it will not ask again.
Today’s skills are:
Where Did We Land?: Reconstruct a meeting transcript into one self-contained HTML page: where every thread landed, with the quote that proves it.
Refactoring UI: 10 applied skills for Claude Code, Codex and Cursor that turn the principles of Refactoring UI into structured AI-assisted design reviews | not affiliated, big fan, get their book here: refactoringui.com/
Where Did We Land? My brain operates in ADHD mode, so standard meeting recaps are ineffective for me. To address this, I built a skill that reconstructs meetings, offering a mental model of the conversation from multiple perspectives. I had to use my favorite movie to illustrate:
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.