CHAPTERS
Why you should pause AI PM applications and learn the fundamentals first
Aakash frames the episode as an AI PM “masterclass,” and Jyothi sets the tone: stop applying until you truly understand AI fundamentals. They establish credibility (Jyothi’s experience across Meta/Amazon/Netflix) and outline what the conversation will cover.
- •AI PM hiring is competitive; fundamentals are the differentiator
- •Jyothi’s background leading AI products across big tech
- •Preview of topics: role reality, roadmap, core concepts, agents, RAG, career strategy
Is “AI Product Manager” real? Two types of AIPM roles (AI features vs AI-native)
Jyothi gives a data-driven breakdown of what companies label as “AI PM.” Most roles are traditional PM jobs with AI features added, while a smaller share are truly AI-native products where AI is the product itself.
- •~80%: traditional product PM + AI features (LLM bolted onto an existing product)
- •~20%: AI-native PM roles (product is probabilistic; impossible without AI)
- •Examples of AI-native: ChatGPT, Copilot, Claude, Cursor, Perplexity
- •Key litmus test: AI enhances vs AI enables the entire value proposition
Roadmap to becoming an AIPM: where roles sit in the stack (Application vs Platform vs Infra)
They map AIPM roles across the stack, from end-user experiences to developer platforms to infrastructure. The deeper you go, the more technical depth you need, and the role distribution skews heavily toward Application PM.
- •Application PMs (~60%): own end-to-end AI UX, trust, reliability, interaction patterns
- •Platform PMs (~30%): build orchestration/evals/observability/dev tools for internal builders
- •Infra PMs (~10%): GPUs, vector DBs, serving, kernel/compilation optimization
- •Conversion path: traditional PMs often start easiest in Application PM roles
What makes an AIPM different from a PM: probabilistic systems, data as product, and new constraints
Jyothi defines classic PM responsibilities, then explains what uniquely changes with AI. AI products are probabilistic and iterative, data quality becomes central to UX, economics vary with usage, and responsible AI/guardrails become core product work.
- •Deterministic vs probabilistic behavior: think distributions, error rates, trust thresholds
- •Data as a first-class citizen: “garbage in, garbage out” affects user experience
- •Iterative model behavior: changes require retesting and ongoing evaluation
- •Variable unit economics: costs depend on tokens/latency/output length
- •Responsible AI: bias, misuse, emergent behaviors, and guardrails
When to use AI vs rules/heuristics: choosing the right problems
They emphasize that many AI pilots fail because teams choose the wrong problems. Jyothi gives patterns where AI shines (complex pattern recognition, prediction, personalization) and where rules-based approaches are better (explainability, clear rules, low data, urgent speed).
- •Good fits: complex pattern recognition, forecasting with rich historical data, personalization at scale
- •Examples: recommendations (pattern recognition), inventory forecasting (prediction)
- •Prefer heuristics when explainability is non-negotiable
- •Prefer heuristics when domain rules are explicit (e.g., taxes)
- •Prefer heuristics when data is limited or speed-to-market is critical
Picking the right AI technique: traditional ML vs deep learning vs GenAI
Jyothi introduces a practical decision framework: don’t jump straight to LLMs. Choose the technique based on data type, task type, constraints (cost, explainability), and user interaction patterns.
- •Traditional ML: structured data, prediction/classification, faster/cheaper/more explainable
- •Deep learning: perception tasks (image/audio/video) where explicit rules are impossible
- •GenAI/LLMs: natural language interfaces, content generation, synthesis/reasoning
- •PM heuristics: “Can this be a spreadsheet problem?” → start with ML
- •Trade-offs: DL/LLMs need more data/compute and are typically less explainable
AI agents fundamentals: definition, building blocks, and workflow vs agent decision
They define agentic AI as goal-oriented systems that choose actions to achieve outcomes. Jyothi contrasts deterministic workflows (predefined steps) with agents (dynamic tool use), and explains agent architecture components.
- •Agentic AI: goal-oriented decision-making and action-taking without fixed step order
- •Four building blocks: perception, reasoning, execution, learning/feedback
- •Workflow: predefined sequence, predictable paths, deterministic expectations
- •Agent architecture: orchestrator + model + memory + tools
- •Tools extend capabilities beyond the model (APIs, search, code execution)
Hands-on build in n8n: create a deterministic workflow (weather → format → email)
Jyothi demonstrates a simple automation workflow in n8n using a manual trigger, a weather API call, light transformation via a code node, and a Gmail send step. The focus is understanding workflow structure and how low-code tools help build intuition.
- •n8n chosen for low/no-code speed and strong community support
- •Workflow nodes: manual trigger → HTTP request (OpenMeteo) → code node → Gmail send
- •Using ChatGPT to generate JavaScript for transformations
- •Workflow is “step-by-step,” with no autonomous decision-making
- •Practical takeaway: learn system mechanics even if production won’t be no-code
Hands-on build in n8n: convert it to an agent (model + memory + tools)
They rebuild the same use case as an agentic system: the agent decides when to call the weather tool and when to send email. This demonstrates the key difference—tool selection and sequencing is driven by intent and context, not a fixed pipeline.
- •Agent trigger via chat message instead of manual run
- •Connect OpenAI chat model, add memory, and expose tools (weather HTTP + Gmail)
- •Agent chooses tools based on user request (answer weather vs email weather)
- •Demonstrates autonomy: doesn’t call Gmail unless instructed/needed
- •Shows why agents are different from ‘regular’ automations
Prompt engineering and context engineering: production reliability, cost, and context windows
Jyothi explains system vs user prompts and why few-shot examples are powerful in production. She expands to context engineering—managing what information is loaded into the model within context window limits while controlling cost.
- •System prompts set behavior/personality and constraints; user prompts are unpredictable
- •Few-shot examples clarify “good vs bad” responses for more consistent outputs
- •Context engineering = managing all information the model needs, within window constraints
- •Three layers: immediate context, session context, knowledge context
- •Cost control: tokens are money; avoid loading entire knowledge base every turn
RAG explained: retrieve the right knowledge before you fine-tune
They position RAG (Retrieval Augmented Generation) as the default enterprise approach for grounding LLMs in company knowledge. Jyothi presents a practical hierarchy: prompt optimization → context optimization → RAG → only then consider fine-tuning.
- •RAG pipeline: chunk documents → embeddings → vector DB → retrieve nearest matches → augment prompt → generate
- •RAG grounds responses in company knowledge, reducing hallucinations
- •Fine-tuning is rarely the first or second choice; often unnecessary
- •Practical order of operations: prompts → context → RAG → fine-tune
- •Claimed impact: RAG can solve ~80% of enterprise knowledge use cases
Build a RAG system in Langflow: ingest, embed, store, retrieve, and answer
Jyothi live-builds a two-part Langflow setup: a load/ingest flow to chunk and store embeddings in a vector database, and a retriever flow to embed queries, fetch relevant chunks, and pass them into an LLM via a prompt template.
- •Langflow used for block-based RAG building and alignment with LangChain/LangSmith ecosystem
- •Ingest flow: file upload → split text (chunking) → OpenAI embeddings → Astra DB vector store
- •Retriever flow: chat input → embeddings → Astra DB search → parse results → prompt template
- •Prompt variable for retrieved ‘context’ + user ‘question’ → LLM → output
- •Playground test: ask what the document is about; model answers grounded in retrieved text
AIPM career playbook: products-not-projects, portfolios, and certifications
They shift from building blocks to career strategy: the best portfolio items are real products with users, not isolated demos. Jyothi recommends showcasing agents and RAG systems, and using certifications as credible signals—without relying on them alone.
- •Reframe: build products with real users, not one-off projects
- •Portfolio staples: an agent use case + a RAG system solving a real problem
- •Ship, iterate, collect failures/lessons—creates stronger interview stories
- •Certificates can signal credibility (e.g., AWS AI Practitioner) but should support hands-on proof
- •Goal: be able to work effectively with engineers, not just describe concepts
How PM cultures differ at Amazon, Meta, and Netflix—and why Jyothi left Netflix
Jyothi compares three distinct PM operating systems: Amazon’s document rigor, Meta’s experimentation, and Netflix’s autonomy via context. She explains leaving a dream role to go full-time into teaching and consulting, motivated by impact and the AI wave.
- •Amazon/AWS: PRFAQ/six-pager culture, intense writing, ‘working backwards’ from customer
- •Meta: fast iteration + deep experimentation infrastructure; PMs live in statistical significance
- •Netflix: ‘context over control,’ autonomy, alignment through communication
- •Why leave Netflix: scaling teaching/consulting impact during rapid AI market growth
- •Closing: encouragement to learn by building and apply fundamentals before job hunting
