3 AI PM Archetypes + 1 - Itamar Gilad Skip to content

There’s no shortage of AI hype at the moment and that includes the the future (or lack there of) of product management.<br>In this article I’ll review three PM predictions that are circulating in the product-sphere, and discuss whether they are real or hype.  I’ll then discuss a fourth archetype that is rarely mentioned but should be on your radar.<br>The AI PM<br>The AI PM is the product manager AI companies are hiring. It’s a person with deep knowledge of all things AI: LLM training, inference, fine-tuning, RAG, evals, skills, and any other terms that will surely be added over time. Some claim that this type of PM will become the norm, and will eventually displace regular PMs. I feel that’s mostly hype (sometimes propagated by people who sell courses). An analysis of open tech positions carried out by TrueUp and shared on Lenny’s newsletter shows that 1-in-7 open PM positions require such AI skills. This is the fastest growing category (+465% since 2023), but that makes sense as this type of role hardly existed before.<br>But there’s no indication that all PM roles will require deep AI knowledge and skills. More likely AI will become a speciality, like security, networking, or fintech. If you’ll work in the field you should be an experts on the technology, but the rest of us can do with a basic understanding of the concepts. Over time more layers of abstraction will be added, so we won’t all have to know all the ins and outs of the technology. Our expertise should first and foremost lie with our market and users.<br>The Developer PM<br>This is a person who’s working somewhat like a developer. There are various flavors to choose from.<br>A PM who is using coding agents to do her work<br>This person, although not coding, uses dev environments like Claude Code, Codex, or Cursor to do product work. There are many good reasons to do this:<br>Coding agents are good at remembering context and building knowledge across sessions<br>Coding agents are good at searching and retrieving data across many files<br>Coding agents are aimed at helping you with your projects<br>Coding agents have unique skills such as spawning sub-agents<br>For this reason I recommend working this way even if you don’t code. Still, this may be a stop-gap solution until environments designed for information workers emerge. Claude CoWork is perhaps the first example.<br>Coding Prototypes<br>This is a popular rational for why PMs should learn to vibe code. Two reasons are often mentioned:<br>Prototypes for idea validation (experiments) — This is indeed a helpful skill, however prototypes are only necessary in certain mid-stage tests. Early validation typically doesn’t require working prototypes, while late stage validation rely on real code. Still it’s a very valid reason to learn to vibe-code.<br>Prototypes as a way to communicate requirements — I’m not a big fan of this one. Over the years I realized that the design, functionality, and characteristics of the product are best defined through discussion with your team. Requirements — PRDs, stories, etc — are best thought of as conversion starters. A working prototype already provides too many answers and can derail the discussion by locking it into a specific implementation.<br>Submitting Production Code<br>Some people argue that future PMs will actually be part-time coders, because… why not. I’m unconvinced. With the exception of early-stage startups where everyone does everything, product management is a full-time job, and an important one at that. PMs are there to ensure the right features and products are built. We work upstream from development and making them coders is often just a weird flex.<br>No PM<br>Some people argue that the PM role is becoming obsolete altogether. My impression is that these are the sort of people that say that:<br>People who genuinely misunderstand what product management is about — often founders who never worked with solid product managers<br>People who want to draw attention to themselves or to their company with yet another “X is dead” message<br>Having said that, there is a certain product subrole that I see as most vulnerable to being replaced by AI — the pure delivery product owner.<br>The deliver PO’s main job is to translate roadmaps defined by other people into backlogs, PRDs, and user stories. The challenge here is that AI is already capable of producing such artifacts at a fraction of the time and cost, and they are polished and convincing. Are they as good as the ones produced by a human PO? Probably not. Do POs do more than just produce artifacts to drive agile dev? Certainly. The problem is that in output-driven companies these may seem like minor concerns given the prospect of accelerating the feature factory and reducing costs. It’s tempting to have one human PO do the work of five, or to have someone upstream use AI to turn the roadmap into specs, or have some engineers do it (making them “full-stack developers”).<br>This sort of transition has happened before. For...