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

The AI-Native PM Operating System [Live Demo]

Mike Bal (Head of Product at David's Bridal) shows his complete AI native PM operating system. MCP integrations explained, live demos, and how to stop drowning in 20 different tools.

Aakash GuptahostMike Balguest

Feb 3, 20261h 1mWatch on YouTube ↗

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

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Where AI fits in a PM workflow + why Claude over ChatGPT
Aakash frames the core question—where PMs should use AI—then introduces Mike Bal’s experimentation across tools during a major digital transformation. Mike explains why he currently prefers Claude over ChatGPT, citing reliability and recent model behavior, setting up the episode’s tool choices.
- •Core prompt: where PMs should use AI in day-to-day work
- •Mike’s tool experimentation across agents and research tools
- •Why Claude feels more reliable than recent GPT releases
- •Early hint: enterprise constraints and working around them
Defining the AI-native PM: thinking in prompts and pushing past ‘too technical’
Mike defines an AI-native PM as someone who decomposes outcomes into steps, then chooses the best tools (AI included) to execute those steps. The emphasis is on overcoming the mental barrier that certain workflows are “too technical,” and treating AI like an extension of your own planning process.
- •‘Think in prompts’ as a practical operating mindset
- •Work backward: goal → steps → tools
- •AI as an extension of the PM’s internal dialogue
- •Breaking the ‘too technical’ mental block
Operating system vs. tool stack: stay in flow by connecting everything
They shift from listing tools to describing an “operating system” layer that reduces tab switching and keeps PMs in flow. The central idea: use a home base (Cursor or Claude Desktop) that can query and act across Jira/GitHub/other systems without leaving the primary interface.
- •OS concept: abstraction layer over many UIs
- •Home base tools (Cursor / Claude Desktop) as command centers
- •Query Jira/GitHub status without context switching
- •Intentional separation: some research stays outside the core OS
Cursor + MCP live demo: editing a CMS without opening it
Mike demos Cursor’s layout and how he uses it more as an integration hub than a traditional IDE. Using an MCP connection to Sanity (a CMS), he queries recent changes and creates a new content document directly from the agent—showing how PM-adjacent work can be executed from the OS.
- •Cursor workflow: agent panel, terminal, and search—minimal file editing
- •MCP explained: authenticated access + API mapping to execute tasks
- •Sanity CMS demo: query documents and create a new task item
- •Value: do ‘tool work’ without opening the tool itself
Connecting tools through MCP: Claude Desktop connectors + memory MCP
They expand the MCP idea beyond Cursor to Claude Desktop, including built-in connectors and configurable custom ones. Mike highlights project-level instructions and the memory MCP as critical for maintaining cross-project context and relationships over time.
- •Claude Desktop: connectors UI + custom config via text file
- •Project-scoped instructions to avoid context bleed
- •Memory MCP to preserve relationships and cross-project knowledge
- •Anthropic’s leadership on MCP support and ecosystem
Design workflows with Figma Make: turning static visuals into editable assets
A static diagram from Canva becomes editable by dropping it into Figma and sending it to Figma Make. Mike positions Figma Make less as production-grade code generation and more as a fast way to create design variations, explore edge states, and hand layered artifacts back to designers.
- •Problem: flat images are hard to iterate on
- •Figma → ‘Send to Figma Make’ to generate editable/interactive versions
- •Best use: design variation and edge-state exploration (not shipping code)
- •Copy/paste back into Figma yields layered elements designers can reuse
Google AI Studio for prototyping: one-shot apps to GitHub/Cursor workflow
Mike recommends Google AI Studio as his current favorite prototyping environment because it’s fast, developer-friendly, and easy to get API access. He describes a loop: prototype quickly in AI Studio, then export/push to GitHub and continue iteration in Cursor like a normal dev workflow.
- •AI Studio vs Gemini app: better context handling and iteration
- •Rapid prototyping with templates/example apps
- •Export path: download zip → push to GitHub → open in Cursor
- •Only pull prototypes into the core OS once quality is ‘good enough’
Confluence + Figma integration: automated gap analysis between PRD and design
Using Atlassian MCP and Figma MCP, Mike pulls product intent from Confluence and compares it against a specific Figma frame. The result is a practical discrepancy list that saves time, reduces missed details, and acts as a ‘second brain’ for validation.
- •Query Confluence for feature intent/requirements via Atlassian MCP
- •Use a specific Figma frame URL to avoid overload and improve accuracy
- •Permission controls: read freely, require approval for writes
- •Outcome: actionable gap analysis (labels, missing fields, mismatched modules)
Research and context gathering with Manus: traceable outputs and reusable artifacts
Mike frames research as context gathering—often before formal planning—then showcases Manus as his preferred agent for deep research. He values Manus’s autonomous run style, traceability, and multi-asset outputs (CSVs, markdown reports, guides) that can later be fed into Claude or a prototyping tool.
- •Research as ‘context gathering’ to shape what questions matter
- •Manus strengths: runs independently, shows trace, returns multiple files
- •Deliverable-driven research: datasets + documentation + summaries
- •Workflow: Manus outputs → Claude for PRD/personas/tech approach → prototype
Manus vs Claude Research: limits, cost burn, and controlling what enters memory
Mike explains why he rarely uses Claude’s Research mode: chat length and usage burn, plus weaker ‘show your work.’ He also warns about contaminating an LLM’s memory with low-quality or biased inputs, advocating selective import of only vetted artifacts into the core OS.
- •Claude Research drawbacks: context limits + heavy usage consumption
- •Manus advantage: traceability and modular outputs for selective reuse
- •Selective ingestion to avoid anchoring on wrong assumptions
- •Practical example: using Manus for podcast prep and filtering outputs
Email, calendar, and docs: ‘connectors’ as non-technical MCP for comms
They demonstrate how Claude’s connectors can search Google Drive (and potentially other comms tools) to retrieve hard-to-find documents and scheduling details. The broader takeaway: everyday PM overhead—email, files, calendar—can be pulled into the OS to reduce busywork and improve recall.
- •Connectors for Gmail/Calendar/Drive as approachable ‘MCP-lite’
- •Claude used to search Drive more effectively than native search
- •Permission prompts and governance options for sensitive actions
- •Expanding OS beyond product tools into communications workflows
Tool licensing, IT, and rollout strategy: read vs write access + usage-based billing
Aakash presses on cost and access, and Mike outlines a pragmatic approach: start small, prove value, then scale plans and permissions. He suggests that many experiments don’t require proprietary context, and points to usage-based API billing (e.g., via AI Studio) as an alternative to stacking subscriptions.
- •Access controls: start with read access; add write cautiously
- •Start with $20 tiers, upgrade only when usage proves ROI
- •Many workflows can be done without sensitive company data
- •Prefer usage-based API keys for experimentation vs monthly subscriptions
Driving adoption in ‘stuck’ enterprises: prove velocity and pitch like a roadmap
They discuss how PMs can win leadership buy-in when tools are blocked by corporate policy. The playbook mirrors product thinking: demonstrate value with small wins, show where current tools hit limits, and frame AI as an impact/velocity unlock—otherwise organizational resistance is a red flag.
- •Build trust by shipping faster with smaller teams and measurable outcomes
- •Start with accessible tools (even personal) while respecting IP constraints
- •Make the case: current wall → unlock with specific tooling
- •Pitch AI enablement like a PM pitches a roadmap: value, constraints, next step
PM lifecycle + common AI mistakes: intentionality, skepticism, and avoiding ‘lazy AI’
Mike argues AI can help throughout the entire PM lifecycle: research, validation, ticket shaping, design verification, and delivery clarity. The biggest risks are classic ‘garbage in, garbage out,’ over-prompting, and outsourcing judgment—PM taste and defensible reasoning remain the differentiator.
- •AI across lifecycle: research → red teaming → requirements → dev alignment
- •Use AI to check tickets against codebase realities and reduce conflicts
- •Mistakes: over-prompting, unvetted inputs, and ‘progress theater’
- •Core skill: maintain taste/intentionality and continuously gut-check outputs
Wrap-up: operating system mindset and next actions for PMs and leaders
Aakash synthesizes the episode into concrete takeaways: centralize work in an OS, add connectors, and ensure teams have access and training. The episode closes with final thanks and standard show outro and bundle plug.
- •OS mindset: projects + context + connectors as the multiplier
- •Leaders: provide access and enable training, not just tool lists
- •PMs: build Claude projects, connect core tools, reduce context switching
- •Closing remarks, follow/subscription requests, and bundle mention

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.