A friend asked me which skills he'd need for an AI PM role. He has been doing product management on the mobile side for three or four years. I sent him three roadmaps and felt useful for about an hour.
Then I read them properly, and they annoyed me.
In general terms, when people are being directed towards AI product management, what gets told to them is that they need to take very serious courses, and then what gets questioned is what kind of knowledge they have at the base, so everyone thinks that becoming an AI product manager has a very long roadmap. Honestly I don't think it is education. Especially now, when AI has developed this much, sitting down and talking together with AI, developing a product, experiencing yourself what kind of problems you run into there, I think that is more valuable for a product manager than reading a roadmap and then taking a course to try to develop your skills according to that roadmap. I haven't seen many places that give this.
All three of them answer the question with a list and a clock. One says a traditional PM needs three to six months, another says four to five at ten to fifteen hours a week, the third says six to twelve with two hundred study hours attached and an "82% success rate" that has nothing underneath it. The Institute of AI PM roadmap at least puts the fundamentals in Phase 1, before a single word about models, and its list of what derails candidates opens with "Over-indexing on technical skills: Companies hire PMs, not engineers. Product sense matters most." That part I agree with completely.
What comes with you from games
On the game development side, product managers actually develop products in a much fuzzier environment, so understanding the users becomes easier after you present the product to them, experiencing it and estimating it from the very beginning is very difficult, so the tolerance for ambiguity is quite high in a game product manager. But one of the really important points is this. The design problems you run into while designing the game, you are actually living them also while designing the AI, or while determining their paths and their flows. A product manager who runs into these problems, especially on the gaming side, I think can get over these problems on the AI side more easily.
In fintech it is different. A product manager working on the fintech side has knowledge on financial subjects, on data security, or on other different subjects, and while passing over to AI product management, bringing these learnings across gives serious benefit, gives benefit to the teams.
The language of AI product managers and the language of product managers working in different sectors, at the first entry, can be a bit different. You may need to have command of new terminology and new terms. So when I first entered, yes, in general the frameworks, the standards and so on, these are similar, but the questions AI product managers run into and have to ask, and their style of asking these questions, differentiate a bit.
Where it gets harder
Honestly I don't have very serious experience on this side. I haven't had the opportunity to come together with a data scientist, or with someone good on the machine learning side, and have much discussion on a certain subject.
In general terms the games we give service to have taken millions of downloads. We are talking about games at the level of a hundred fifty thousand, half a million, one million monthly active users, some of them at the ten million level. The data we examine here doesn't go over funnel design like it does in applications, it is more scattered. Following how the user will behave inside the game, especially if there is no linear flow and the user is free, can be quite difficult, so our analyses on the game side could be more complex, more complicated. In a way, actually, even if we were not at the level of a data scientist or a machine learning engineer, there were times we had to do very hard analyses to pull something out.
Aishwarya Srinivasan, who spent ten years in ML at Microsoft, Google and IBM before leading developer relations at Fireworks AI, describes where that ends up: "AI PMs are now expected to own the full feedback loop, including evals. In the past, PMs would hand this off to data scientists who handled model performance. Now, the PMs are expected to define what good looks like for the AI feature, design the evaluation framework, and monitor it post-launch." Then the clause I would underline is this: "that requires a level of rigor that most traditional PM training does not prepare you for."
And the line I'd send my friend instead of the roadmaps: "AI is the what, product management is the how."
Seniority
Seniority stops helping at this point, apparently, and the reflexes you built up start working against you. I don't agree with that at all, and I don't fully follow the claim either. What seniority brings is a different set of things. Team management. The right directives given to a team. I'm in a lead position myself, a notch above senior, and my aim is mostly to get teams to the right question, the right design, the right document.
There is a second reason and I think it is the one that matters most right now. Product managers catch the opportunity to work with different different business groups and teams, so they can be more in command of their language. Actually I think this will have a very big contribution in agent development. Whichever role you are making an agent for, you understand that role's language more easily, and your chance of writing a more suitable skill for there, or of giving an instruction, increases. I think this is very important.
To give a rough example, in my micro learning application the number of days I spent on design is two, and together with development, the time to bring out the application we created together with AI is also two. So good design, good directives, good briefings, good design, and transferring these correctly to the AI, and you can incredibly shorten the development time of the product you produced with AI.
On that application I take on the product design role. Because in the product design role you are actually creating a new product together with a model, one of the problems I ran into, especially together with Opus 5 and Fable, is that since there is very serious reasoning in these models, in some of the reasonings they can try to direct you, whereas actually your design is more correct, and you may need to behave a bit insistently that this should be done at the start. This is a subject outside the product manager. In a product that is taken live you can run into more different cases.
What I look at especially on the design side is whether the user experience is good or not. Primarily, would I want this feature, would I see it inside the application and desire to use it, would it increase engagement. Rather than technical questions, I try to answer by approaching from the user's point of view.
How I close my own gaps
I am not in favour of this time being spent only by taking education. Previously, yes, these times needed to be spent while taking education, because fundamentally it was giving you a foresight about whether you could be a good product manager here. But now I think this job is a bit different. Take education while taking education, but also continue developing products, develop products yourself, try to dance with AI. Learning in practice is easier now. In theory you come face to face with the risk of forgetting what you learned, but in practice, as you practice, this knowledge settles. You can say the points you think you are missing, or more correctly, you can ask the AI to say them to you, and this way you can go and learn them.
For example, when I first started I didn't know what a vector database does, what RAG does. Let me tell how I followed a path to learn these. First I imagine an application, and I put this application into words. After putting it into words I give this to my researcher AIs. The researcher AIs tell me with which technology it can be done, with which method it can be done. If something I don't know comes out there, I try to learn those. This way I close my gaps like this, because actually, since I already know how I need to proceed as an approach, as a framework, this system speeds me up excessively.
What I told my friend in the end was to constantly run small products, small workflows, small automations with AI. Nothing bigger than that.
Hats
The most useful framing I found isn't in any of the roadmaps. It is in Irene Bratsis's AI Product Manager's Handbook, which refuses the phase structure and organises the role as five competencies: technical proficiency, business acumen, communication, leadership, and problem solving. Each one holds a cluster of what she calls hats. Technologist, AI expert, technical translator, data steward, quality controller. She writes: "We can think of each competency as a concentration of skills and responsibilities and not just as standalone skills" (ch. 18, p. 398). And a line for anyone who has just read three roadmaps and feels behind: "listing these competencies isn't about promoting excellence in each one, but rather is being done to demonstrate the full range of skill sets and competencies you can explore as you grow and mature into your AI PM career."
Data steward, a few years ago, I would have failed that one. Yes, there were many situations where data I didn't understand came, many situations where meaningless data came. So on most subjects I now enter myself and handle determining the event schema, and reading this event schema, myself.
Honestly, frankly, the one I feel a bit bad about myself on is quality control. For that I even developed an AI. From the videos I shoot, there is even an AI that quickly analyses the transitions between the scenes and questions accordingly. But quality control, actually your dance with it makes you clarify the quality of the product a bit more.