Part 2 - Build AI Products with Agentic AI: AI PM Crash Course | Product Space

Main ideas / lessons

• AI product management is evolving from traditional PM

  • Product management now needs to deliver significantly more value (2x/3x/5x) in the same time/resources.
  • AI is not replacing PMs entirely, but some roles may become redundant over time—so PMs should upskill and add more value.

• Be cautious with relying on generative AI outputs

  • LLMs (the speaker mentions GPT-like models) can be inaccurate and unreliable.
  • Even generative AI company founders/CEOs have publicly advised against relying on GPT-style models (including tools like ChatGPT/Gemini and a “City”-named tool—likely a transcription error, possibly referring to Perplexity or another tool) for unquestioned knowledge.
  • Guidance:
    • Use AI for faster execution
    • Don’t blindly trust or “pump and dump” outputs
    • Always ensure it matches your context

• A realistic PM workflow still applies—especially around PRDs

  • Use a product requirement document (PRD) as a guiding artifact.
  • Don’t jump straight to full build:
    • Design/prototype first, validate internally with stakeholders
    • Only then proceed to backend development in later phases

---

Methodology / workflow shown (detailed)

A) Continue the “case study” from a prior session: PRD → Prototype → Backend

Step 1: Identify/prioritize features from the PRD

Ask the AI to:

• List all PRD features
• Prioritize them by impact
• Select the “market sweet spot”

Step 2: Limit initial scope

• Choose top 3 features only
• Avoid building too much at once
• Use a prototype-first approach

Step 3: Add phased development constraints explicitly

• Phase 1: prototype only
• Phase 2: backend development happens later

Rationale: In typical PM practice, you don’t parallel-send the PRD to engineering before design prototypes are approved.

Step 4: Force the PRD to be compatible with prototyping tools

• Ask for detailed user flows so the prototype can be built in tools such as:
  • Marvel
  • Visily/Vizily (names may be transcription errors)

Step 5: Iterative prompting instead of copy-paste

In a real workflow, the speaker emphasizes:

• Read output line-by-line
• Iterate prompts
• Keep refining until the output matches what’s needed

---

B) Use a “Chat PRD” tool to generate PRDs/documents

Tool purpose

After login, it can write many product/PM documents, not only PRDs, including:

• PRD
• API documentation
• Competitive analysis
• Customer journey map
• GTM
• OKRs
• Other documentation types

Demonstration approach

• Provide a problem statement, e.g.:

  “Consumers in metro cities face choice fatigue… spend too much time deciding what to order.”

• Let the tool draft a PRD using a chosen template structure

Important cautions

• The tool may randomly choose a template unless you specify the format.
• Use tools for speed, not total reliance.

---

C) Parallel prototyping to compare tool quality (useful interview tactic)

The speaker recommends parallel prototyping across multiple tools to:

• Avoid getting stuck if one tool fails
• Demonstrate evaluation rigor (e.g., “I tested multiple options and compared tradeoffs”)

Tools used in the demo

• Lovable
• V0
• Bolt
• (Earlier mention of Visily/Vizily)

Strategy

• Use the same content/PRD across tools
• Add prompt constraints like:
  • “Build prototype only in Phase 1”
  • “Explicitly exclude backend”
  • Mention roadmap/development phase separation so tools don’t build full backend prematurely

Observed outcomes

• Lovable: better performance and quicker results; more extensive depth
• V0: quick but perceived as less “up to the mark”
• Bolt: similar understanding but slower; sometimes limited/slow

---

D) Backend setup with Supabase (Phase 2)

Tool

• Supabase

Integration (conceptual)

• Connect a Supabase project to the prototyping platform
• Handle sign-in/permissions (connect/disconnect + auth setup shown conceptually)

Backend capabilities emphasized

• Authentication
• Storage
• Edge functions
• Real-time DB interaction
• DB management via:
  • Table editors
  • SQL editor
  • Viewing tables, functions, triggers

Security/requirements specified

• Enable authentication options (e.g., email verification)
• Ensure users cannot access others’ profiles/data
• Trigger a confirmation email on signup
• Store user-specific data in proper tables

Data model creation (demo result)

Generated schema/tables included (names may vary by implementation):

• user profile / public profiles
• restaurants
• food items (with categories and “mood” tags like comfort food)
• Likely cart / order items tables
  • The speaker later reviews cart and food item tables; order items were initially blank.

Validation/testing

• Approve email confirmation
• Test signup with invalid then valid credentials
• Verify the app routes users to home after confirmation

Deployment note

• The speaker answers a deployment question by referencing Supabase and its deployment link
  • A brief “Laravel” mention appears once in a learner question (likely: “Deploy inside Laravel itself?”)

---

Second case study: building an AI feature (Spam detection)

Problem framing (Gmail/Outlook-like)

• Build a spam classification feature that identifies:
  • spam vs healthy/primary inbox
• Why it matters:
  • More junk/promotional emails increase inbox confusion
  • Users may miss important emails

---

AI development life cycle (as taught)

• Data collection & preparation
  • Gather labeled spam/healthy emails:
    • From user reports/markings
    • From third-party/purchased datasets
• Model selection
  • Choose a suitable AI approach
  • For this use case: classification model
• Training & evaluation
  • Train, test, validate, and apply reinforcement learning where appropriate
  • Deploy when performance is acceptable
• Post-deployment monitoring
  • Handle complaints when healthy emails are incorrectly marked as spam
  • This implies false positives

---

Key technical concept: threshold-based classification

• The model outputs a probability between 0 and 1.
• A threshold converts probability into labels:
  • If probability > threshold ⇒ spam (1)
  • If probability < threshold ⇒ non-spam/healthy (0)
• Default threshold discussed: 0.5

---

PM-aligned decision logic to reduce false positives

• Situation: model predicts too many “1” (spam) labels → many false positives
• Proposed parameter adjustment (only one parameter changed):
  • Increase the threshold (e.g., 0.5 → 0.7)
• Effect:
  • Fewer emails exceed the threshold ⇒ fewer marked as spam
  • Reduces healthy emails moved to spam

Tradeoff:

• Higher threshold may let more spam slip into the primary inbox
• The speaker emphasizes you cannot tolerate healthy emails going to spam because users could miss urgent information.

---

How PMs work with data science teams

• PM responsibilities:

  • Discuss scenario/context and acceptable tradeoffs (what’s worse: false positives vs false negatives)

  • Translate business risk into what “better performance” means for the product

  • Communication warning:
  • PMs should learn enough data science language to collaborate (e.g., terms like ROC/AUC, activation functions, softmax—mentioned as examples)

---

Speakers / sources featured (identified from subtitles)

• Akhil — instructor/speaker, from Product Space
• Garvit — attendee/participant who shared an experience
• Gehvi/“Gevvi” (possibly other names like “Darshan” and others) — attendees contributing in Q&A
  • Mentioned names include: Darshan, Dave, Vishal, Mayank, Ritu, Harsh Raj, Nia Beam, Mahesh, Arjun, Shivam, SSK (some may be incomplete/uncertain due to subtitle transcription errors)
• IBM — mentioned as a source for layoffs (not a speaker)
• Gmail / Outlook — referenced as product domains/examples (not speakers)