3 Trendy AI PM Archetypes, and 1 We Actually Need - Itamar Gilad

9 min read Original article ↗

There’s no shortage of AI hype at the moment and that includes lots of speculation about the future (or lack there of) of product management. 

In this article I’ll review three PM predictions that are circulating in the product-sphere — The AI-PM, Developer PM, and No-PM futures. I’ll discuss each to see whether it is real or hype. Then I’ll show you a fourth alternative that is rarely discussed but may matter the most.

The AI PM 

The AI PM is the type of 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 other terms that will surely be added to this ever growing list.

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 as of Q1-2026 1-in-7 open PM positions ask such AI skills. This is the fastest growing category of PM by far (+465% since 2023), but that makes sense as this type of role hardly existed before. 

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 work in the field you’ll be expected to be an expert, but the rest of us can do with a basic understanding of the concepts. It’s reasonable to assume that over time more layers of abstraction will be added, so we won’t all have to know how AI works under the hood to use it.

 The Developer PM

This archetype describes a product manager who increasingly works like a developer. There are several flavors of this model.

A PM who is using coding agents to do her work 

This person, although not coding, uses dev environments like Claude Code, Codex, or Cursor to do product work.
Right now, I don’t feel that’s hype at all; in fact there are good reasons to work this way: 

  • Coding agents are designed to help you completes tasks and projects
  • Coding agents are good at remembering context and building knowledge across sessions
  • Coding agents are good at searching and retrieving data across many files
  • Coding agents have unique skills such as spawning sub-agents
An example of my personal Cursor workspace: the left pane is the AI chat window. The middle pane shows documents under work, and the left pane shows folders and files containing context, built-up knowledge, and inflight projects. To get started follow this excellent tutorial by Tal Raviv and Aman Khan.

Still, this may be a stop-gap solution until environments designed for information workers will start offering similar capabilities. Claude CoWork is perhaps the first example, and we can expect Google, Microsoft, Atlassian, and Notion to make strong moves in this space.

Coding Prototypes

This is a popular rational for PMs to learn to vibe code. Two reasons are often mentioned:

  • Prototypes for idea validation (experiments) — This is indeed a helpful skill. Prototypes are necessary in certain mid-stage tests and it’s great if a PM is able to produce them.
  • Prototypes as a way to communicate requirements — This is an unpopular option, but I’m not a huge fan of prototypes-as-requirements. It’s true that a working prototype can communicate a flow and an experience better than words and images, so in certain cases prototypes have their place. Still, over the years I realized that “requirements” — whether in the form of PRDs, stories, or prototypes — are at best conversion starters. The details of the implementation should be hammered down through discussion with your team, managers, and stakeholders. A working prototype already provides too many answers and can derail the discussion into the minutia of implementation details. So don’t lock yourself in a room and come out with a prototype. Start the discussion with a more raw concept, and use prototypes as a tool for co-development and communication of the consensus.

Developing Production Code

Some people argue that future PMs will actually be part-time professional coders. This is part of broader idea of overlapping skills and an emergence of “full-stack” roles that do product management, design, and development. I’m unconvinced. With the exception of early-stage startups where everyone needs to do 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 help the true professionals (who also have a full-time job) maximize their potential. 

No PM 

Some people argue that the PM role is becoming obsolete altogether. I feel that these sort of statements are almost entirely hype and usually come from these sources:

  • People who genuinely misunderstand what product management is about — often founders who never worked with solid product managers
  • People who want to draw attention to themselves or to their companies with yet another “AI killed X ” message

Having said that, there is a certain product role that I see as vulnerable to being replaced by AI — the pure delivery product owner.

The delivery 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? Absolutely. The problem is that in output-focused 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 (hence making them “full-stack developers”).

This sort of transition has happened before. For example the draftsman used to be a very important role in many companies, translating designs produced by architects or designers into schematics fed into manufacturing or construction. However when computer aided design (CAD) appeared in the 1980s, most draftsmen lost their jobs. Some became CAD draftsmen, but mostly the role is no longer needed because architects and designers use the CAD software themselves. 

A good career move may therefore be to be to go upstream and become a full product manager (many companies have these as separate roles, while in others PMs wear both hats — I’m definitely in favor of the latter). The PM role is different. She needs to turn the messy context of her company — management mandates, customers requests, stakeholder ideas — into a coherent roadmap. This is a harder and more “human” job that AI probably will struggle to do (although many AI tech companies are already trying to automate roadmap production as well). So this job seems to offer more job security. 

That may be the case, but you should consider that new technologies disrupt not just roles, but also companies. 

Practice hands-on the modern methods of product management, product discovery, and product strategy.  

Secure your ticket for the next public workshop
or book a private workshop or keynote for your team or company. 

AI and the Company Operating Model

Look at any major transformation that required companies to change the way they work, and you’ll see that some companies were quicker to adopt the new thing and faster to grasp what it’s really good for. These companies created important business advantages for themselves. This was the case with CAD, ERP, Cloud Computing, and Agile Development.

AI is likely to be a disruptive technology affecting not just markets, products, and software development, but also the operating model of the company. 

I’ve written in the past about the 8-function company operating model shown below, (think of each function as sub-systems in your body). 

I argued that traditional companies tend to over-focus on execution — product delivery, go-to-market, and operations — at the expense of everything else, which causes them to be disoriented, misaligned, and very wasteful. These companies will likely focus their AI efforts on the same three areas, essentially putting their feature factories on steroids. 

Modern product companies try to work and develop all functions. No company is perfect in this respect, but at least there’s awareness and willingness to improve. These companies will apply AI across the board, and in so doing will improve all their skills. I’ve written before that I see a lot of potential in AI helping companies remove friction, analyze data, offload hard cognitive tasks, and in general help the company move in the right direction. 

Which leads us to the fourth and painfully neglected future PM archetype.

The AI-Empowered PM

Many of the functions mentioned above are cross-functional. Product managers are often drivers or key contributors. As such I see the future PMs as ones that help put AI to use for the general improvement of company functions — far beyond just coding or spec generation. 

I tried to capture this idea in a previous article where I listed all the PM functions today and how AI may help do them better. This is of course future projection, but I think, forward-thinking PMs that want make themselves valuable to their companies and also create more impact on users and the business, should consider this path seriously. 

Sidenote: I’m starting to put these ideas to practice in a series of workshops. The first one — depending on demand and feedback — may be about using AI to create better OKRs, a topic I see most companies struggle with and where I witness AI making a massive difference. 
Fill out this form: AI-Powered OKR Course  to learn more and I’ll reach back to you with details when the course becomes available. 

Conclusion

It’s too early to say how AI will affect product management, but of the four models I’ve shown I most prefer that AI-empowered product manager. Rather than start from what the technology can do and project back to the role, it’s better to begin with the needs of the org and the product manager and see how AI can help. I may be wrong of course, but I see high potential AI will empower better product management rather than reinvent the role.

Join my newsletter to get articles like this 
plus exclusive eBooks and templates by email

Related Articles

Share with a friend or colleague