CHAPTERS
- 0:00 – 2:58
Why AI PM roles pay more and what makes them different
Aakash and Pawel start by unpacking the rising demand for AI product managers and why compensation is higher than typical PM roles. The core theme is the hybrid skill set: strong business/product judgment plus enough technical depth to collaborate effectively with engineers in a fast-moving space.
- •AI PM pay premium driven by market heat and scarce skill set
- •AI PMs must blend business skills with technical understanding (without necessarily coding)
- •Newness of the tech raises the bar for cross-functional communication
- •Growing AI market suggests increasing need for AI PMs
- 2:58 – 6:03
Prompting as a foundational AI PM skill: context, roles, and assumptions
Pawel demonstrates a high-quality prompt used for product discovery—especially for identifying hidden assumptions behind opportunities. He emphasizes that prompts should include context, goals, and structured steps, and can leverage multiple personas to surface different risk areas.
- •Explain context and objectives before asking the model to do work
- •Use personas (PM/designer/engineer) to get varied perspectives
- •Structure output around risk areas: value, usability, viability, feasibility
- •Specify steps explicitly to improve reliability and completeness
- 6:03 – 9:45
Prompting best practices and “hacks” that improve output quality
They expand from the demo into a practical playbook for prompting: clarity, formatting constraints, templates, step-by-step instructions, and iteration. Pawel also highlights avoiding leading questions, and shares the quirky but often effective trick of adding a “reward” to encourage more detailed responses.
- •Set clear expectations: success criteria and output format
- •Provide templates/examples (e.g., prior user stories) for alignment
- •Give step-by-step instructions; reasoning models can follow them sequentially
- •Avoid leading questions to reduce bias injection
- •Iterate and reverse-engineer prompts from ideal outputs; “reward” framing can increase detail
- 9:45 – 12:07
Sponsor break + prompting mastery mindset (the chess analogy)
Aakash frames prompting as a skill that compounds with practice—comparing it to chess mastery—and transitions the conversation to product craft in AI: writing PRDs for AI initiatives. Sponsor messages appear here before the course-like progression continues.
- •Prompting proficiency requires significant deliberate practice
- •Transition from prompting to AI-specific product documentation
- •Sponsor segments (Linear, Miro)
- •Sets up the shift into PRD and product alignment topics
- 12:07 – 14:51
How AI PRDs differ: fighting hype, ensuring alignment, adding guardrails
Pawel explains that AI PRDs aren’t radically different, but the AI hype makes strategic justification and alignment more critical. He outlines two essentials: tie initiatives to business strategy and include AI-specific considerations like safety/guardrails and evaluation thinking.
- •PRD’s main purpose is organizational alignment—not exhaustive documentation
- •Start with a draft PRD and iterate as you learn during development
- •AI hype increases risk of building without a business case
- •AI PRDs should address guardrails and model alignment with user intent
- 14:51 – 19:58
AI PRD template walkthrough: market, users, value prop, moat, scope, GTM
They walk through the key PRD sections: executive summary, market timing/opportunity, strategic alignment, user needs, value proposition, and competitive advantage. Pawel also covers scope elements including architectural choices and AI-specific requirements, then closes with go-to-market considerations and a real-world case study reference.
- •Market opportunity: why now and how the market evolves over time
- •Strategic alignment: avoid ‘AI for AI’s sake’ even under investor pressure
- •Segment needs by importance vs satisfaction; define value proposition via capabilities/benefits
- •Competitive advantage: sustain with Roger Martin’s ‘can’t/won’t’ test
- •Scope includes NFRs and AI eval/bias/fairness considerations; end with GTM phases and success metrics
- 19:58 – 25:04
Fine-tuning demo for PMs: when prompts get too big and expensive
Pawel introduces fine-tuning by showing the drawbacks of stuffing long instructions into every prompt (cost and inconsistency). He demonstrates training a smaller model on example conversations (Yoda voice) to internalize style/behavior, reducing token usage and enabling cheaper specialized models.
- •Prompt-injection approach can require large expensive models and repeated context
- •Fine-tuning encodes behavior/style into model weights for repeated use cases
- •Use smaller base models (e.g., 4o mini) to cut inference cost
- •Training/validation datasets help measure generalization beyond training data
- 25:04 – 30:12
Understanding fine-tuning results: epochs, loss curves, and practical value
They interpret the fine-tuning run: loss improvements, how many epochs are actually needed, and how to preview the resulting model. Aakash reinforces why many AI companies fine-tune: better brand voice control and lower costs for recurring workflows.
- •Training loss and validation checks indicate how well the model learned the target behavior
- •Often one epoch can be sufficient; extra epochs may add little value
- •Previewing the fine-tuned model validates voice/style changes
- •Fine-tuning is especially useful for prompts executed repeatedly in a product
- 30:12 – 32:44
RAG explained: when to use retrieval vs fine-tuning (and when to combine)
Pawel explains RAG as the default solution when answers must be grounded in a large corpus (and ideally quote sources). They clarify the decision boundary: fine-tuning for behavior/style and repeated patterns; RAG for dynamic/large document knowledge—often used together.
- •RAG avoids injecting entire document sets into prompts (cost and context limits)
- •Use RAG when answers must be based on external data and/or require citations
- •Fine-tuning and RAG are complementary; you can combine both
- •RAG is essential at scale (hundreds of thousands to millions of docs)
- 32:44 – 49:20
Building the RAG pipeline live: Pinecone + embeddings + n8n ingestion
They build an end-to-end ingestion workflow: monitor a Google Drive folder, download new files, split them into chunks, embed them, and store in Pinecone with metadata. The live build includes troubleshooting and iteration, illustrating real-world workflow construction.
- •Vector DB stores embedded chunks rather than raw documents
- •n8n workflow: Drive trigger → download file → chunk/split → embed → upsert to Pinecone
- •Metadata (e.g., filename) enables filtering and source attribution later
- •Operational reality: batch timing, debugging, looping over items, and re-running after fixes
- 49:20 – 59:01
Serving RAG answers: webhook endpoint, retrieval, aggregation, and citations
Pawel creates a webhook that accepts a user query, retrieves top-matching chunks from Pinecone, aggregates content and sources, and calls an LLM to generate an answer grounded only in retrieved context. They then test it with questions like OKRs and North Star Metric and discuss improvements to query rewriting and routing logic.
- •Webhook acts as the API interface for a chatbot or external client
- •Query is embedded using the same embedding model to ensure vector comparability
- •Aggregate chunk text + filenames; prompt the LLM to answer only from RAG context and list sources
- •Potential enhancements: decide when to use RAG, generate better search queries, and extract sub-questions from long user inputs
- 59:01 – 1:07:20
Turning the endpoint into a chatbot UI with Lovable (and dealing with formatting issues)
They use Lovable to quickly generate a front-end chatbot that calls the webhook and renders results. The demo surfaces common friction—like markdown formatting inconsistencies—while reinforcing how quickly a functional RAG chatbot can be assembled with modern tooling.
- •Lovable can generate a basic chatbot UI that calls the webhook
- •Markdown rendering may require iteration and clearer formatting constraints/examples
- •Execution logs help validate end-to-end flow from UI → webhook → retrieval → LLM → response
- •Tool stack recap: n8n workflows, Pinecone vector store, Lovable front-end
- 1:07:20 – 1:19:10
MCP demo: connecting Figma → generating Jira epics and stories automatically
They introduce MCP (Model Context Protocol) as a standard that lets agents interact with external systems via discoverable tools. Pawel connects Claude (Cloud) to Figma and Jira, then generates epics and INVEST-style user stories from a Figma design into a new Jira project—showing major PM time savings.
- •MCP standardizes tool discovery and execution across services (e.g., Stripe, Jira, Figma)
- •Configure MCP servers with credentials; the agent reads supported tools automatically
- •Use case: read Figma design + create Jira epics/stories with acceptance criteria
- •Potential upgrades: include Figma node links, incorporate existing story standards from Confluence, run without manual approvals via hosted workflows
- 1:19:10 – 1:24:59
AI agents in practice: deep market research + agent orchestration patterns
Pawel shows an agent that plans and delegates market research tasks across sub-agents using web search/scraping, then synthesizes findings with sources. They run a demo comparing Amazon Prime Video vs Netflix content strategy, producing a PM-oriented report with citations and structured opportunity areas.
- •Agents can plan multi-step research, delegate tasks, and synthesize outputs
- •Market research example: Prime Video vs Netflix content strategy and positioning
- •Outputs include comparative analysis, demographics, market share dynamics, gaps/opportunities, and many sources
- •Implementation can be done in Lovable with backend logic hosted in Supabase edge functions
- 1:24:59 – 1:33:16
Building agents with n8n: memory + tool use (calendar/email) and real-world caveats
Pawel sketches an alternative agent architecture in n8n, emphasizing built-in tool connectors, agent memory, and orchestrations similar to MCP-driven systems. A quick improvised demo shows an agent sending emails and creating calendar events, while highlighting the need to configure the right tools and constraints.
- •n8n agent node supports model choice, memory, and tool access (Jira, Gmail, Calendar, etc.)
- •Tool parameters can be model-defined, enabling flexible automation
- •Improvised demo shows practical workflow: create calendar event + send email invite
- •Common pitfalls: missing tools (read vs create), time/date assumptions, and need for better constraints/testing
- 1:33:16 – 1:36:30
Wrap-up: the AI PM toolkit and the future of AI product management
Aakash recaps the “pyramid” of AI PM skills covered: prompting, AI PRDs, fine-tuning, RAG, MCP, and agents. They end with the big career question—whether all PMs must become AI PMs—and a closing plug for Pawel’s newsletter/community and show subscription reminders.
- •Course recap: prompting → PRDs → fine-tuning → RAG → MCP → agents
- •Not every PM must become an AI PM, but demand is likely to grow rapidly
- •Pawel promotes Product Compass newsletter and paid community office hours
- •Final calls to subscribe/follow/review to support the show
