By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Stop Applying to AI PM Jobs Until You Watch This

Jyothi Nookula has 13.5 years in AI, 12 patents, and has been an AIPM at Amazon (SageMaker), Meta (PyTorch), Netflix (Developer Platform), and Etsy.

Jyothi NookulaguestAakash GuptahostAakash Guptahost

Mar 23, 20261h 12mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Why “AI PM” isn’t BS: Traditional PM + AI features vs AI-native PM
The episode opens by challenging the claim that “AI product manager” is hype. Jyothi explains the AI PM landscape with a practical split between traditional products that add AI features and products that are fundamentally AI-native.
- •AI PM roles fall into two categories: AI features on existing products vs AI-native products
- •Most “AI PM” postings are actually traditional PM roles with LLM features bolted on
- •AI-native products are probabilistic by nature and impossible without AI (e.g., ChatGPT, Copilot)
- •Understanding which category a role fits helps candidates target the right skills and interviews
AI PM roles across the stack: Application vs Platform vs Infrastructure
Jyothi maps AI PM jobs to three layers of the product stack and explains how requirements change as you move downward. The discussion includes which layer is easiest to enter and rough market sizing for each.
- •Application PMs own end-user AI UX, trust, and interaction patterns; easiest transition from traditional PM
- •Platform PMs build tools for other builders (orchestration, evals, observability, developer experience)
- •Infra PMs focus on foundations (vector DBs, GPU orchestration, model serving optimization)
- •Approximate role distribution: 60% application, 30% platform, 10% infra
The five-part learning roadmap for aspiring AI PMs
Jyothi outlines the master plan for becoming effective as an AI PM. This frames the rest of the episode: when to use AI, how to choose techniques, core agent/RAG concepts, and how to deliver AI products end-to-end.
- •Start by understanding how AI PM differs from traditional PM
- •Develop judgment for when to use AI vs when to avoid it
- •Learn the menu of AI techniques and tradeoffs
- •Master core concepts: agents, prompts/context, RAG, evaluations
- •Understand delivery: iteration, deployment, monitoring, and quality management
What PM fundamentals still matter—and what changes with AI products
The conversation revisits baseline PM responsibilities (UX/tech/business leadership without authority) and then highlights the AI-specific shifts. Jyothi emphasizes that probabilistic behavior changes how PMs think about quality, cost, and risk.
- •PM baseline: balancing UX, tech, business; vision; customer obsession; prioritization; stakeholder alignment
- •Key AI shift: deterministic products vs probabilistic outputs (same input → different results)
- •AI PMs must think in distributions, error tolerances, edge cases, and fallbacks
- •Data becomes a first-class citizen; poor data directly degrades product experience
- •AI changes iteration cadence, unit economics variability, and guardrails/responsible AI needs
Choosing AI vs rules: when AI is worth it (and when heuristics win)
Jyothi explains a common cause of failed AI pilots: picking the wrong problems. She offers clear patterns that favor AI and equally clear conditions where rules-based systems are the right business call.
- •AI fits pattern recognition in complex, multidimensional data (e.g., recommendations)
- •AI is strong for forecasting/prediction when you have rich historical data (e.g., inventory forecasting)
- •AI enables personalization at scale for millions of users
- •Prefer heuristics when explainability is non-negotiable or domain rules are explicit (e.g., taxes)
- •Avoid forced AI when data is limited or speed-to-market/MVP pace is critical
Selecting the right AI technique: Traditional ML vs Deep Learning vs GenAI
Rather than jumping straight to LLMs, Jyothi presents a three-bucket toolkit. She explains when each approach is appropriate, the key questions PMs should ask, and the tradeoffs in cost, data, and explainability.
- •Traditional ML (regression/trees/XGBoost): best for structured data, prediction/classification, cost/speed/explainability
- •Deep learning: best for perception tasks (image/audio/video) where explicit rules are hard
- •GenAI/LLMs: best for natural language interfaces, content generation, reasoning/synthesis across sources
- •PM decision heuristics: “Can this be a spreadsheet problem?” (ML) vs “Is it perception?” (DL) vs “Does it require reading/writing/reasoning in language?” (GenAI)
- •Tradeoffs: deep learning/GenAI often require more data/compute and have lower explainability
AI agents explained: definition + core building blocks
The episode shifts to agentic AI, defining what makes an agent an agent. Jyothi breaks down agent components and how they combine into goal-oriented behavior rather than a fixed sequence.
- •Agentic AI: goal-oriented systems that decide actions rather than follow a fixed script
- •Four building blocks: perception, reasoning, execution/actions, learning/feedback loops
- •Perception sources can include text, images, sensors, and APIs
- •Reasoning can include LLMs, classifiers, and planning algorithms
- •Execution includes tool/API calls, text generation, or hardware control
Workflow vs agent: when you need determinism vs autonomy
Jyothi contrasts automation workflows with agents and provides an architecture lens. The difference centers on predictability (human-defined steps) versus a system choosing tools/actions based on the goal.
- •Workflows: predetermined steps, defined decision trees, predictable execution paths
- •Agents: select actions/tools dynamically to achieve objectives
- •Agent architecture: orchestrator (agent) + model + memory + tools
- •Memory enables statefulness across conversations/actions
- •Tools extend capability beyond the model (search, APIs, code execution, etc.)
Hands-on build in n8n (Part 1): a deterministic weather-to-email workflow
A practical demo shows how to build a simple workflow in n8n: trigger → HTTP request → code formatting → Gmail send. The focus is on understanding step-by-step automation without autonomy.
- •Why n8n: low/no-code accessibility and strong community support
- •Workflow nodes: manual trigger, HTTP request to a weather API, JavaScript code node, Gmail send
- •Using ChatGPT to generate JavaScript for transformation inside n8n
- •Workflow behavior: explicit, sequential, and “no intelligence” beyond defined steps
- •How integrations/credentials work (e.g., Gmail OAuth)
Hands-on build in n8n (Part 2): an agentic version that chooses tools
The second demo rebuilds the weather assistant as an agent using a model, memory, and tools. The agent decides whether to call the weather API and whether to send an email based on the user’s request.
- •Agent trigger via chat message input
- •Connect an OpenAI chat model (e.g., GPT-4.1 mini), add memory, then add tools (HTTP + Gmail)
- •Agent decides tool usage dynamically (answer only vs answer + email)
- •Contrast with workflow: no need to hardcode message formatting steps
- •Demonstrates practical autonomy: the system selects tools based on intent
Prompt engineering vs context engineering: making agents work in production
Jyothi explains why prompting still matters, but context engineering is the real production differentiator. The discussion covers system vs user prompts, few-shot examples, and the economics and constraints of context windows.
- •Prompts are the primary interface: system prompts define behavior; user prompts are unpredictable inputs
- •Few-shot examples improve reliability by showing good/bad response patterns
- •Context engineering manages what the model needs within context window constraints
- •Three context layers: immediate task, session history, and broader knowledge context
- •Context window management affects cost; avoid loading entire knowledge bases every time
RAG fundamentals: how retrieval-augmented generation works (and why before fine-tuning)
RAG is introduced as the default enterprise pattern for grounding LLMs in company knowledge. Jyothi walks through the pipeline from chunking to embeddings to vector search, and provides a clear hierarchy: prompt/context/RAG before fine-tuning.
- •RAG = retrieve relevant knowledge and augment the prompt before generation
- •Pipeline: documents → chunking → embeddings → vector DB; query → embedding → nearest neighbors → context injection
- •Grounds responses in company knowledge and reduces hallucinations
- •Recommended hierarchy: prompt optimization → context optimization → RAG → only then fine-tuning
- •Claim: RAG solves the majority of enterprise use cases compared to fine-tuning
Building a RAG system in Langflow: ingest + retriever flows
A step-by-step Langflow build demonstrates the two halves of RAG: loading documents into a vector store and querying them at runtime. The demo uses OpenAI embeddings and an Astra DB vector database to retrieve chunks and answer questions in a playground.
- •Why Langflow: no-code blocks, strong alignment with LangChain/LangSmith ecosystem
- •Ingest flow: file loader → split/chunk text → embeddings (e.g., text-embedding-3-small) → vector DB (Astra DB)
- •Retriever flow: chat input → embedding → vector search → parse results → prompt template → LLM → output
- •Prompt template uses retrieved context as a variable plus the user question
- •Playground test validates retrieval-grounded answers about the uploaded document
AI PM career playbook: build products (not projects), portfolio, and certifications
The episode closes the technical masterclass with a career strategy for breaking into AI PM roles. Jyothi stresses shipping real products with users, building a portfolio of agents/RAG apps, and using certifications as credible signals.
- •Reframe “projects” as products: launch, get users, observe failures, iterate like a real PM
- •Portfolio suggestions: build an agent, build a RAG system, solve a real pain point in your domain
- •Better resume storytelling comes from real usage, breakages, tradeoffs, and learnings
- •Certificates can signal credibility (e.g., AWS AI practitioner) when paired with hands-on work
- •Advice targets being able to collaborate effectively with engineering, not just “know terms”
How AI PM culture differs at Amazon, Meta, and Netflix—and why Jyothi left Netflix
Jyothi compares the operating rhythms of three major tech companies and what each teaches PMs. She then shares her motivation for leaving Netflix to focus full-time on teaching and consulting as AI hiring accelerates.
- •Amazon/AWS: PRFAQ/six-pagers, rigorous writing culture, work backwards from customer; heavy documentation
- •Meta: experimentation-first, high technical expectations, sophisticated testing infrastructure and stats rigor
- •Netflix: “context over control,” autonomy with high communication and ambiguity tolerance
- •Despite performance pressure, Jyothi recommends the growth and scale benefits of these environments
- •Leaving Netflix: pursue teaching/consulting full-time; expand courses (agentic AI, PM interview accelerator)

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.