Check out the conversation on Apple, Spotify, and YouTube.
Is AIPM actually real or is it BS? (0:00)
Aakash: Jyothi, welcome to the podcast. I want to start with the hard questions. You had this title AI product manager, but I keep hearing that AI product manager is BS. Is it actually real or is it hype?
Jyothi: Let me give you a data-driven answer because I have been on both sides of this, hiring AIPMs at Meta, Netflix, and Etsy, and now talking to dozens of companies about their AI strategies.
When I look at the industry landscape for AIPMs, there are a few critical distinctions that many people miss. The kind of roles that exist are twofold.
One is a traditional PM with AI features added on. This is probably 80% of what is labelled as AIPM jobs out there right now. These are where PMs are leading LLM capabilities and adding AI features to existing products. Think of a chatbot you are adding to your customer service portal or AI summarization to your document tool. The core product existed before you bolted an LLM onto it.
The other type is the AI native PMs. This is a new category of PM roles that is opening up. About 20% of the ones out there are AI native PM roles. Here the product is AI. It is not a feature, it is not something you bolt onto the product. Think ChatGPT or GitHub Copilot or Claude, Cursor, Perplexity. The key characteristic is the product is fundamentally probabilistic. The value proposition is literally impossible without AI. You cannot build ChatGPT without an LLM. AI is not just enhancing the product. It is the product.
Aakash: So two different types, 80% in traditional products, 20% in AI native. There are basically four times more open roles in those traditional companies. So if somebody wants to become an AIPM, what is the roadmap?
The three layers of the AI PM stack (4:22)
Jyothi: Before I jump into the roadmap, I want to talk about what type of AIPM roles exist along the stack.
At the top, I call this the application PMs. Here the PMs own the end to end user experience. They are thinking about how users interact with AI, how do you build trust, how do you make AI reliable enough for everyday use. They need to understand the AI human interface and interaction patterns. This is probably the easiest for someone who wants to convert from a traditional PM role because it encompasses a lot of existing product management skills along with AI knowledge.
The second is the platform PM. Here PMs are building tools that other teams who are building application products are using. Think developer platforms, model orchestration systems, evaluation frameworks, observability tools. Here the PM needs to understand both the technical infrastructure and developer experience. You are not building for end users, you are building for other builders.
The last is the infra PMs where PMs are building the foundational systems that power all AI products. Vector databases, GPU orchestration, optimising kernel level compilation, optimising model serving. The lower you get into the stack, the deeper your expertise needs to be.
Aakash: What are roughly the percentages of roles at each of these three buckets?
Jyothi: About 60% of roles are application PMs, about 30% are platform PM, and maybe 10% are infra PM.
Aakash: So the hardest roles are actually the smallest. Can you walk us through the key concepts to know?
5 core concepts every AIPM needs to know (7:11)
Jyothi: Whether it is application, platform, or infra, some of the key concepts are the same across. We are going to talk about five techniques.
The first is understanding the difference between what an AIPM does versus what a regular PM does. The second is determining when to use AI, because there is this hype around using AI and knowing when to say yes and when to say no is a very powerful skill. The third is what AI techniques are available, so we will look at a menu. The fourth is if we decide to use Gen AI, we will learn about core concepts around AI agents, prompt engineering, context, RAG, and evaluations. And last is delivering AI products, all the way into deployment.
What differentiates a PM from an AIPM (10:01)
Jyothi: A product manager is essentially the CEO of the product. A PM owns the product and its associated decisions. What product managers do is balance UX, tech, and business. PMs lead without authority. They do not have people reporting to them. So PMs need to be able to influence teams and make hard calls.
The core difference is traditional products are deterministic. AI products are probabilistic. Traditional products have predictable behaviours. AI products are inherently probabilistic, meaning the same input can result in different outputs.
If I have a button in a traditional product, I click on it and every single time it will open the next page. But every time you ask an AI product, because it is probabilistic, it can produce different outputs.
As AIPMs you must think in terms of quality distributions, in terms of acceptable error rates. It is no longer binary success versus failure. You tackle questions like what is the error rate that users can tolerate before trust breaks. How do we handle edge cases that occur 5% of the time. Do we need a fallback deterministic system.
What is also different is data is your first-class citizen. Traditional PMs can focus on features and user flows. As an AIPM you must treat data as a product experience because poor data creates poor experiences. Having a good data strategy is a prerequisite before you even start implementing your AI product.
Aakash: The data piece is actually one of the underrated ones because people often hear data and shrug their shoulders and say they understand basic statistics. But there is a lot more to it in terms of data pipelines, how the data is being cleaned, what is being used as training data. There is a lot of nuance.
Jyothi: Garbage in, garbage out. If you have data that is not high quality, your model outputs will also not be close to reality.
Similarly, your model behaviour with AI products is iterative versus a fixed feature of a traditional product. Any new change requires you to retest your model and understand what is changing.
Your unit economics are also very different. Traditional products have predictable cost structures. Because of the probabilistic nature of AI products, your unit economics are variable. It depends on how long your LLM takes to give an answer.
And last, you now need to emphasise a lot more on responsible AI and guardrails because AI products need to handle potential harms, bias, misuse, and emergent behaviours that were not explicitly programmed into the model.
When to use AI and when not to use AI (15:19)
Jyothi: This is a report from MIT that many people are aware of. One of the key factors is picking the right opportunities to apply AI. It seems common sense but it is not as common. Several teams are choosing the wrong problems to apply AI to. Apparently 19 out of 20 people are choosing the wrong one.
Here is when AI makes sense. You have to choose AI when it is well suited for specific patterns.
Pattern recognition in complex data. When patterns exist in your data but they are too complex for humans to manually define. For example, YouTube uses machine learning to identify patterns of users watching videos, which would be impossible to capture with simple rules. The relationships between user behaviour and content preferences are multi-dimensional.
Prediction from historical data. When you have historical data over several years to predict future outcomes. At Amazon we used AI to forecast inventory needs based on seasonal trends, upcoming promotions, and even weather patterns. These models could consider hundreds of different variables in ways that humans simply cannot process.
Personalization at scale. When you need to create personalised individualised experiences for thousands or millions of users. Content recommendation engines are classic examples.
Aakash: And what are the bad places?
Jyothi: I would not say bad, but here is where heuristics are sufficient.
When explainability is non-negotiable in your industry. It is really hard for AI models to have high explainability.
When there are clear rules in your domain. Tax calculation software is a great example. Tax codes are complex but they are explicit, making them perfect for rules-based implementation.
When data is limited. AI needs lots of data to be effective. If you are launching a new feature or entering a new market where historical data does not exist, start with heuristics.
When development speed is critical. AI systems generally take longer to build. For MVPs or time-sensitive features, starting with traditional methods could be the right business decision.
How to select the right AI technique (20:33)
Jyothi: When we look at AI these days, people jump straight to using ChatGPT or building with an LLM. Honestly, a simple machine learning model would have solved the problem in a week at a fraction of the cost.
When I think of AI techniques, I think of them in three buckets.
The first is traditional ML. Regression models, random forests, XGBoost. This has been around for years. It is mature, reliable, and still powers most of the AI you interact with. Choose ML when you have structured data and need to predict or classify something. Think spreadsheets. The sweet spot is when you are predicting a number or a category, you have historical data with clear patterns, you need the model to explain its decisions, or speed and cost matter. Fraud detection and customer churn prediction are examples.
As a PM, the question you should ask is can I put this problem in a spreadsheet with clear input columns and an output I want to predict? If yes, start with ML.
The second is deep learning. Neural networks, computer vision, speech recognition. This thrives when you are dealing with image, video, audio, any form of unstructured data with sophisticated pattern recognition. Deep learning shines when humans can do the task easily but it is really hard to write explicit rules for it. When I see your face, I know this is Aakash. It is easy for me, but writing it in code as if-then statements is impossible. Medical image diagnosis, manufacturing defect detection, voice assistants are all deep learning.
As a PM, ask is this a perception problem? Am I dealing with images, audio, video? If yes, deep learning is your friend. The catch is deep learning needs more data, more compute, and is less explainable than traditional ML.
The third is Gen AI. LLMs, diffusion models, Stable Diffusion, ChatGPT, Claude. Use Gen AI when you want to understand, generate, or reason over natural language or images. The breakthrough with LLMs is not just that they can write. It is that they can read, comprehend context, reason across information, and respond appropriately.
Gen AI is the right choice for natural language interfaces where users interact conversationally. Content generation where you are creating text or images. And reasoning and synthesis where LLMs take information from multiple sources and make judgments.
Aakash: And then there is the whole angle around AI agents as well, where most people are building agents into their products or MCPs that agents can interact with.
AI agents and the building blocks (26:32)
Jyothi: Agentic AI is a system that can make decisions and take actions on your behalf to achieve some goal. You are not explicitly telling it what order to follow. It understands your goal and tries to reason and find the path to achieve it.
The core building blocks for an AI agent are four.
Perception is how the agent receives information. Text input, image, sensor data, or API connections.
Reasoning is how the agent processes information and makes decisions. This is where your models live, LLMs, classification models, planning algorithms.
Execution is how the agent affects its environment. Generating text, making API calls, controlling hardware.
Learning is the feedback mechanism of how the agent evaluates outcomes and improves.
Aakash: When do you use a workflow versus an agent?
Jyothi: There is a huge difference. Workflows are predetermined sequences of tasks where everything is defined in terms of how the process will go. Think automation pipelines where AI serves as a powerful component. An example would be an invoice processing workflow. Step 1 extract data from PDF, step 2 validate against rules, step 3 evaluate, step 4 update the system.
Agents are goal-oriented systems that can independently decide how to accomplish objectives. The key characteristic of workflows is predictable patterns, human-defined decision trees, deterministic outcomes. An agent architecture is very different.
The agent architecture has the agent as the brain or orchestrator, a model which could be GPT or Claude or any language model, memory which stores context and allows the agent to be stateful, and tools which are utilities that extend capabilities beyond what the model alone could do, like a weather API or booking system.
Live demo of workflows and agents in N8N (33:26)
Jyothi: We are going to use N8N. It is a low code, no code tool that allows anyone to build workflows or agents. It has a strong community where you can find forums and get answers quickly.
First we built a basic workflow. We started with a manual trigger, then an HTTP request to Open Meteo for weather data. I copied the API URL for Los Angeles into the HTTP request node with the get method. The output showed the weather data.
Then we added a code node to format the information. I went to ChatGPT and said this is what I am trying to code in JavaScript and it generated the code. It formatted the output to say “In Los Angeles, the high today is this temperature and the low is this temperature.”
Then we added a Gmail node to send the email with the weather report. We connected the credential, set the recipient, subject line, pasted the formatted message, and executed. The email was sent.
That is a basic workflow. No intelligence. Step after step.
Now we created an agentic workflow instead. We added a chat message trigger, then an agent node. By default it gives you a model node, memory node, and tool node.
We connected the OpenAI chat model with GPT 4.1 mini. Added simple memory. Then added two tools, the same HTTP weather request and Gmail integration.
Unlike the workflow where we defined the message, we let the model automatically define it based on whatever message it receives. We are not writing any code, not defining any conversion steps. We give the agent the tools and let it decide.
When I typed “What is the weather today in Los Angeles,” the agent called only the HTTP weather tool. It did not execute Gmail. I never said do not execute Gmail, but the agent determined it only needed the weather tool.
Then when I said “Send the message,” it used the Gmail tool. This is the key difference. We are not telling which tool to use. The agent determines it based on the question.
Aakash: That is what makes it actually AI, an actual AI workflow, not just a regular no code workflow.
Prompt engineering and context engineering (43:36)
Jyothi: Before we get to RAG, I want to talk about prompt engineering and context engineering.
Think of prompts as the primary interface between you and the AI system. The prompt is how you tell the agent what to do, how to behave, and what outcomes to expect.
There are system prompts which set the overall behaviour and personality of your agent. For a customer service agent, your system prompt establishes an empathetic personality, professional tone, and identity verification requirements.
Then user prompts are what the actual user inputs.
Here is where it gets interesting. How you design your system to handle the unpredictable nature of user inputs determines how your agent responds. Users will not always ask questions the way you expect.
That is where few-shot examples come in. You show AI what good responses look like by providing examples. This is the really underrated technique where you put in what a good response looks like and what a bad response looks like.
Aakash: People think this is a lot of work, but when you are engineering the system prompt for an agent, it is worth it.
Jyothi: Incredibly powerful in production systems.
Now context engineering. This is where the magic happens in production because context engineering is about managing everything the AI needs to know to do its job effectively within the constraint of context windows.
AI models have context windows, a limit on how much information they can process at once. Claude Sonnet has a 200K token context window. That might sound like a lot until you start loading your company knowledge base, conversation history, real-time data, and user prompts. Suddenly you are making hard decisions about what stays and what goes.
I think about context engineering in three layers. Immediate context is the current conversation or task. Session context is the user’s recent interactions. Knowledge context is broader information the agent needs to reference.
Context window management directly impacts cost because every token costs money. If you are carelessly loading your entire knowledge base into every interaction, you are burning through your budget fast. Context engineering is the art of knowing what to load and when.
Aakash: What is an example of that you learned the hard way?
Jyothi: That is when we started understanding that there is a way to dynamically figure out based on the information what context is needed, what information from your knowledge base could be loaded in. That is where prompt flow and orchestration patterns come in.
When people say prompt engineering is dead, it is not dead. It is part of this holistic context engineering that encompasses prompting strategies as well.
RAG systems explained and built in Langflow (48:15)
Aakash: How do we dynamically pull in this information quickly?
Jyothi: That is where we learn about RAG, which helps you figure out based on the prompt what the right information is to retrieve and load.
RAG is retrieval augmented generation. It is very simple but has tremendous value. When people say should I go and fine tune my model, I say no, start with RAG because RAG might solve 80% of your problems.
Like the word says, retrieval. It retrieves information from the knowledge base, augments it along with the user input before passing it to the LLM. That allows the LLM to have the context to generate output rooted in the knowledge base of that company.
Here is how RAG systems work. You have documents in a company. You chunk them, which is breaking them into smaller pieces. Think of a storybook and after every 20 pages you rip it. That is a fixed chunking strategy.
You take the document, break it into chunks, pass it through an embedding model, and store it in a vector database.
When a user queries, the query is also passed to the embedding model, converted into a vector, and that vector goes to the vector database to find the nearest neighbours that would answer the question. It retrieves that information and adds it along with the user input and passes to the LLM. The LLM now has the documents from the vector database and the user input to generate a response rooted in the information.
Now about fine tuning. Many people ask can we take an LLM and fine tune it to our use case. Fine tuning should never be your first option, maybe not even your second.
The practical hierarchy I recommend is first start with prompt optimisations. Then optimise your context engineering. Implement RAG. Almost 80% of use cases get solved with RAG versus fine tuning. Only if these three do not suffice should you go for fine tuning.
Aakash: Especially if you have done really good prompt engineering at the top.
Jyothi: Absolutely. Because fine tuning is in the API documentation, people immediately jump to it. First follow the sequence.
We then built a RAG system using Langflow. For the data flow, we started with a file node, uploaded the State of AI in Business 2025 report, connected it to a split text node for chunking. We added an OpenAI embedding model using embedding 3 small, and an Astra DB vector database with a collection called Langflow. We connected the chunks to ingest data and the embedding model to Astra DB.
For the retriever flow, we added a chat input for user questions, the same embedding model, Astra DB to search the stored documents, a parser to process the data, a prompt template with the instruction “given the context above, answer the question as best as possible,” and connected the language model to an output.
When we asked “What is this document about,” it responded with detailed information about the State of AI in Business 2025 report, grounded in the actual document content.
The AIPM career playbook (58:56)
Aakash: What is the right roadmap for hands-on projects to become an AIPM?
Jyothi: Always start by not thinking of it as projects. Think of it as building products. Build a use case, a pain point that you have. Then rather than being done with it, take it forward. Think of it as a product. Launch it. Have friends and family try to use it. Now all of a sudden you have real users. Things will break. You are now doing things like a real product manager would.
By taking it from a project to a product, you start getting the confidence to put those in your resume. You can give richer information when you talk to recruiters. Instead of “I attended this course” or “I did this project,” you have richer details. This broke in these use cases. Here were the challenges I had to overcome.
Aakash: Should people be creating a portfolio?
Jyothi: Yes. Your portfolio should have an app that solves a real problem. Build an agent. We just built a simple agent, build one that solves a problem. Build a RAG system. Look for problems within your area and build examples that you can convert into products with real users.
Aakash: How important are certificates?
Jyothi: Certificates are a great way to signal to recruiters and hiring managers that what you have learned is credible and accredited. You could learn the concepts, do hands-on projects, and then go take the AWS AI Practitioner certificate. That gives you a credible certificate to tell hiring managers it is not just something you have learned but is accredited by AWS.
How PM cultures differ at Amazon, Meta, and Netflix (1:01:55)
Aakash: How do the AIPM cultures differ at those three companies?
Jyothi: Very different.
At Amazon or AWS, it is a very customer-obsessed, document-writing culture. Amazon invented the PRFAQ or the six-pager where everything starts with a press release and frequently asked questions document before engineering writes a single line of code or a design mockup is created. The philosophy is working backwards from the customer. You start with the customer problem, articulate why existing solutions do not work, then explain how your product solves it.
This PRFAQ is reviewed all the way up by your VP or even sometimes Andy Jassy. It is a very document-writing heavy culture. Amazon PMs spend probably 40 to 50% of their time writing documents. You become an exceptional writer at Amazon. There is no option around it.
At Meta, it is the complete opposite in terms of process. If Amazon is about rigorous upfront planning, Meta is all about experimentation and iteration. Move fast. Product management at Meta is expected to be deeply technical, where you understand the codebase, go through insights of how something was implemented, talk about shipping multiple variants and testing against control groups, and let data tell you what works.
Of all the companies I have worked with, Meta has the most sophisticated experimentation infrastructure in the industry. As a PM there, you live and breathe statistical significance.
At Netflix, the philosophy is context over control. Perhaps the most unique approach to product management among big tech. Instead of rigid process or documentation requirements or approval hierarchies, Netflix invests heavily in making sure everyone understands the strategic context, and then trusts you to operate independently within that context. You are expected to be an exceptional communicator. You need to be very comfortable with ambiguity and be able to define your own swim lane.
Aakash: All three of those companies are kind of notorious for having performance-oriented cultures. Amazon just laid off 30,000 people. Meta has rolling layoffs. Netflix is known for pressure. How is it working in these companies?
Jyothi: An absolutely phenomenal experience. I have learned a lot. At Amazon, the first thing that gets ingrained is working backwards from a customer pain point. With Meta, it is all about how do I test quickly, what should the experimentation culture look like. With Netflix, I have learned truly about what autonomy means and the power of building consensus and working together towards a shared vision.
The scale is phenomenal across all three. Every feature you build is used by millions of users. That experience is something I would encourage everyone to have at some point in their career.
Why Jyothi left Netflix (1:07:15)
Aakash: Director of AIPM at Netflix feels like a dream job. Why did you leave?
Jyothi: I have been in the field of AI for 13.5 years. I have about 12 patents in the field of AI. With so much AI growth happening, I derive a lot of satisfaction from teaching product professionals how to transition into being an AIPM.
I have been teaching for 2.5 years. The greatest satisfaction is when someone says your experience and insights were so powerful that I was able to crack that interview and now my pay is 2x what I used to get.
With a lot of opportunity out there and AI jobs increasing, I wanted to go full time into teaching and consulting companies to draft their AI strategy, applying the learnings from leading scaled AI businesses and products.
I added two new courses. One on agentic AI for someone who already knows AIPM fundamentals and wants to build agentic AI products. And a PM accelerator specifically helping professionals crack product interviews. My previous students from AIPM continue down the funnel to agentic AI and the PM accelerator. The courses run full just from that flow.
I am just two months in so it is probably too early to figure out how things are, but I am really excited about it.
Aakash: If I am reading between the lines, you might not have hit Director of AIPM at Netflix pay yet, but you clearly see a path to getting to more. Is that fair?
Jyothi: Absolutely, yes.
Aakash: That is the potential you can get as a course instructor. Jyothi, thank you for sharing your knowledge so in depth, so freely with all of us.
Jyothi: Thank you so much for having me. I am thrilled to be here.
