By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
- 0:00 – 0:37
AutoXP teaser: automating growth experiments end-to-end
Ezra Mechaber opens with the idea that “wasting traffic” is the biggest growth PM sin and describes AutoXP: an automated system that can run multiple experiments without constant human oversight. He highlights that it already found a major win on its first experiment and can coordinate analysis through agent-like roles.
- •Traffic left unused for experiments is framed as a major growth failure
- •AutoXP is described as a “little growth PM” that can keep running continuously
- •An engineer is currently running AutoXP with multiple concurrent experiments
- •AutoXP can be prompted to find an experiment for a specific surface (like a settings page)
- •AutoXP can trigger a data-scientist-style analysis of drop-off and funnels
- 0:37 – 2:50
Meet Ezra and the episode roadmap: Figma’s internal PM OS + Jev writing assistant
Claire Vo introduces Ezra and previews the two major demos: Figma’s internal “PM OS” (a set of skills used by PMs) and a real-time writing assistant built with Jev. She frames the show as helping PMs build better with new AI tools.
- •Claire introduces herself and the show’s mission
- •Ezra is introduced as a product manager at Figma
- •The episode will cover Figma’s internal PM OS and its skill set
- •Claire also previews a real-time AI editor using Jev
- •The conversation is set up as a practical demo-focused walkthrough
- 2:50 – 4:35
Why PM OS exists: getting PMs to actually use AI for real work
Ezra explains he expected widespread AI use at Figma but found most non-engineers weren’t using tools to get meaningful work done. Spurred by a challenge from the CPO to get PMs “AI pilled,” Ezra and collaborators worked on turning personal terminal-based automation into something reusable for many PMs.
- •Ezra wanted to be “lazy in the right places” by automating PM work
- •He found limited AI adoption outside engineering despite high expectations
- •Claude Code’s arrival helped him realize what was possible in the terminal
- •Figma’s CPO asked what it would take to get PMs broadly using AI
- •Work began to convert a personal workflow into a shared, reusable system
- 4:35 – 6:40
Target problems: raising the floor on neglected PM tasks
Ezra describes choosing PM tasks that often get done poorly or skipped—then using AI to reach a “minimum allowable” quality level so nothing critical falls through the cracks. Examples include looping in support at the right time, producing usable meeting notes, and identifying owners in a large org.
- •PMs juggle too many roles, so some jobs get skipped or done poorly
- •The goal is “good enough” output to avoid blocking others
- •Launch hygiene example: remembering to loop in support at the right time
- •Meeting notes example: using transcription plus AI to become reliable
- •Org navigation example: finding code owners and understanding relationships
- 6:40 – 10:38
PM OS demo: the “chief of staff” agent setup and daily Slack triage
Ezra walks through PM OS as a chief-of-staff-like assistant that loads PM context, remembers key collaborators, and uses skills to reduce repetitive work. A major daily workflow is a “what’s up” skill that pulls together relevant Slack threads, outstanding decisions, and obligations to help a PM focus.
- •PM OS is framed as a chief-of-staff-style assistant with a memory file
- •A core skill auto-inserts relevant collaborators (EM, designer, skips) when drafting docs
- •Ezra uses PM OS as a “meta Slack” to manage an overwhelming channel load
- •The “what’s up” workflow aggregates relevant threads, decisions, and follow-ups
- •Claire highlights the value of foundational context (who owns what, who needs input)
- 10:38 – 12:10
How the repo works: skills, boot hooks, and private sub-repos
Claire and Ezra clarify that PM OS is a basic repository containing behavioral instructions and a library of skills, plus hooks to keep users updated. Ezra explains the distribution model: a shared parent repo and a private workspace sub-repo so PMs can write back personal materials without exposing them.
- •PM OS is a repo with an agents.md defining behavior
- •It includes a set of skills describing when to fire and what to do
- •Boot hooks can check for updates to keep many PMs in sync
- •Onboarding creates an invisible base context folder plus a user workspace
- •The setup uses two repos: a shared parent repo and a private sub-repo for personal output
- 12:10 – 14:26
Skill evolution: from “Cambrian explosion” to ruthless pruning (and no telemetry)
Ezra describes how early development produced an explosion of skills, followed by heavy whittling based on feedback, including a company-wide PM offsite where people installed and roasted the tool. He also notes they chose not to add telemetry to avoid creepiness and because it was built as 20% time, relying instead on feedback loops.
- •A small group rapidly shipped many skills via PRs early on
- •An offsite with Figma PMs generated hands-on usage feedback and “roasting”
- •Skills were removed or simplified as models improved
- •Telemetry was considered but avoided to keep it fun and non-creepy
- •Feedback came through a shared channel and spread to other functions (EMs, data scientists)
- 14:26 – 17:43
Favorite skills in action: build artifacts, FigJam MCP templates, and coaching
Ezra highlights a few standout skills he uses regularly: generating and publishing simple HTML artifacts for sharing, leveraging a FigJam builder connected to Figma’s MCP, and a coaching skill that uses ladder context and prior feedback to help him think through people problems before escalating to managers.
- •The “what’s up” skill is positioned as a core day-to-day workflow
- •Build artifact creates simple shareable HTML outputs and can publish internally
- •A FigJam builder uses the Figma MCP to generate workshop-style templates quickly
- •Ezra notes early “sloppy” prompt artifacts but says outputs improved over time
- •Coaching skill helps structure feedback using career ladder context and past situations
- 17:43 – 18:39
Interface shift: terminal TUI → local web UI → living mostly in Codex
Ezra explains PM OS started as a terminal-based interface, then moved to a local web front end to make writing and reading easier. He says he now spends most of his time in Codex because browser use has become strong, and he even automates small life tasks like booking a desk.
- •PM OS began as a terminal TUI inside Claude Code
- •A local web front end was built to improve writing, readability, and formatting
- •The UI goal was to make it approachable for PMs transitioning from traditional tools
- •Ezra now works primarily in Codex due to improved browser use
- •He mentions scheduling automations like booking office desks without manual effort
- 18:39 – 22:29
Bug bashing with Codex: diligent scenario testing and FigJam writebacks
Ezra describes a repeatable bug-bash workflow where Codex runs through detailed test scenarios using the browser, alongside Ezra using a parallel account. The system logs results back to FigJam and has found edge cases the team missed, including unusual input stress and UX copy issues dependent on team names.
- •Codex is used as a persistent “bug bash” partner in a threaded conversation
- •Test plans live in FigJam with accounts, paths, and actions to follow
- •Codex runs scenarios more diligently than a human and uses the browser to execute steps
- •Results are written back to FigJam, with ongoing tuning to avoid noisy comments
- •Examples found include a text box breaking under extreme emoji input and an “a/an” grammar issue tied to team names
- 22:29 – 26:26
AutoXP deep dive: Slack-triggered agents that launch and iterate experiments
Ezra expands on AutoXP as a system to increase experimentation cadence by automating parts of ideation, analysis, copy, and implementation. It uses Slack triggers and multiple automations to coordinate a data-science agent, UX writing agent, and engineering execution, then posts progress back into the same thread and triggers analysis when experiments complete.
- •AutoXP is motivated by improving experimentation cadence and not wasting traffic
- •Slack can seed an experiment prompt or AutoXP can run in a loop
- •It triggers roles: data science agent (funnels/drop-off), UX writing agent (copy ideas), and an engineering step (PR work)
- •Progress updates are posted back to the Slack thread for traceability
- •When an experiment finishes, a webhook triggers results analysis and next-step iteration (explore vs exploit framing)
- 26:26 – 27:20
Claire’s experimentation backstory: Experiment Engine and the “time to be alive” moment
Claire shares her personal history working across experimentation companies and building a startup called Experiment Engine, focused on maximizing the number of experiments. She reacts to AutoXP as a realization of that long-held vision, enabled by today’s tools.
- •Claire says she has worked at many experimentation platform companies
- •She mentions founding a startup called Experiment Engine years earlier
- •Her hypothesis then was maximizing experimentation volume and traffic utilization
- •She connects that past idea directly to the feasibility of AutoXP today
- •She expresses excitement about quickly building these systems with modern tooling
- 27:20 – 33:50
Real-time writing assistant with Jev: detect gaps, flag claims, and pull sources when you pause
Ezra demos a Jev-powered writing prototype that triggers checks whenever the user stops typing, looking for blanks and claims that need support. It can query a library of interviews or notes to suggest missing content and provide substantiating quotes, aiming for low-latency assistance that feels more like a coworker.
- •Jev is described as fast and cheap, returning compact judgments (like a number or classification)
- •Ezra is interested in Jev for low-latency coworker-like assistance vs slower top-tier models
- •The prototype runs a check whenever typing pauses
- •It detects placeholders (like “TK”) and identifies claims worth supporting
- •It pulls relevant quotes from a library of interviews to help substantiate writing in real time
- 33:50 – 42:29
Lightning round + closing: personal agents, being nice to AI, and how to find Ezra
Claire and Ezra discuss personal agent tools, including Instinct and Dots, and trade views on how they interact with AI when it’s frustrating. Ezra argues it’s better for the soul to avoid being mean, notes how context can get “poisoned,” and suggests starting fresh when stuck; they end with where to find him and a hiring note.
- •Ezra says Instinct texts him but he often doesn’t respond; he still uses it for specific tasks
- •He describes reporting potholes via a hands-free flow that saves effort vs a bad website process
- •They discuss switching preferences among personal tools, with Claire sharing her own setup
- •Ezra explains he avoids yelling at AI, partly because frustration often comes from bad instructions or poisoned context
- •Ezra shares he’s mostly on Twitter and mentions Figma is hiring PMs (and other roles)
