CHAPTERS
Why Laurel’s CPO interviews for “AI-pilled” product builders
Aakash introduces Jiaona “JZ” Zhang and frames the episode around a provocative idea: the most effective AI-native PMs operate like end-to-end builders. JZ previews how fundamentals stay the same while tools and operating systems change how teams execute.
- •JZ’s background (Laurel CPO; ex-Linktree, Airbnb, Dropbox, Webflow, WeWork; Stanford instructor)
- •What’s changing: PM execution model vs. PM principles
- •Teaser: JZ’s interview tactic to verify real AI fluency
- •Preview of AI maturity levels and company operating systems
Inside Laurel’s “Company OS” in GitHub: functions, folders, and skills
JZ screen-shares Laurel’s GitHub repo that acts as a companywide operating system, organized by function and phases of work. The key concept is turning repeated work into reusable “skills” that are discoverable and standardized across the org.
- •GitHub as the source of truth: folders for CS, sales, marketing, design, engineering, finance, etc.
- •Each workflow area contains playbooks/skill docs (e.g., renewals, negotiation support, onboarding)
- •Skills are meant to be executed repeatedly, not just documented
- •The OS maps real work, not abstract org charts
Making the OS real: Slack-driven daily briefings + Claude skills
JZ shows how the OS gets embedded into daily work via Slack, including a daily briefing pattern. Skills are uploaded into AI tools (e.g., Claude) so people can call the right asset at the right moment instead of reinventing decks/emails.
- •Most work happens in Slack/email—delivery must meet people where they work
- •Daily briefings: calendar + meeting prep + handoff/session prep skills
- •Claude ‘skills’ as company context to reduce repeated content creation
- •Operational goal: consistent customer experience through shared motions
The “1% vs 99%” AI adoption gap—and how a Company OS fixes it
JZ explains the common adoption failure: a small group of power users builds great workflows, while most employees don’t know what tool/skill to use when. The OS converts individual experimentation into organization-wide leverage.
- •1% of power users vs. the rest of the org lacking clarity
- •Standardizing ‘what to use when’ across roles and functions
- •Onboarding people into shared skills instead of ad hoc tips
- •Scaling best practices from top performers to everyone
Step 1 of building your own OS: automate one painful workflow (feature request triage)
JZ outlines a three-step path to build an operating system, starting with a single annoying workflow. She demos a Slack automation that structures and routes feature requests to reduce back-and-forth and improve triage speed.
- •Pick one repetitive task you’d love to never do manually again
- •Slack workflow collects required context (impact, frequency, recordings, details)
- •Auto-routing to the right owner + creating a trackable ticket
- •Define SLAs and reduce ambiguity in intake processes
Step 2: from playbooks to agent pipelines (and why a ‘mega-agent’ matters)
Next, JZ shows how large playbooks become usable by translating steps into agents and automations. The breakthrough is creating a single ‘mega-agent’ interface that routes requests to the right sub-agent so teams don’t need to remember dozens of tools.
- •Playbooks can be long (50+ pages) but must translate into action
- •Audit steps: human-required vs. automatable/productizable steps
- •Agent builders (Dust/Glean/Claude/OpenAI) can encode sub-workflows
- •Mega-agent pattern: one entry point that routes to specialized agents
- •Adoption hinges on minimizing interface switching; deliver in Slack/email
Tooling strategy: Dust vs. Claude + avoiding automation overload
JZ explains why Laurel initially used Dust for agent building and how that gap is shrinking as Claude improves. She also warns that scheduled automations can overwhelm teams, motivating consolidation into a single OS with curated, high-signal delivery.
- •Early tooling maturity favored dedicated agent builders; now Claude can cover more
- •Skills can be stored as files and invoked directly inside Claude
- •Scheduled tasks can become noise; information overload reduces adoption
- •Company-level curation creates consistency across functions
Culture as the multiplier: hackathons, ‘everyone is a builder,’ and enabling non-technical shipping
JZ argues the OS only works with the right culture—leadership must signal it’s cross-company, not just engineering. She describes companywide hackathons and training that enable PMs and even Customer Success to ship production changes using agentic engineering tools (e.g., Devin).
- •Leadership sets expectation: building is for every function
- •Companywide hackathons as repeated ritual (quarterly/6 weeks)
- •Training: how to ship to production safely even if non-technical
- •Examples: PMs shipping front-end + back-end features; CS contributing via guides
- •Break work into playbooks, then into skills/agents for repeatability
PMs shipping real features: ontology of PM work and what gets automated away
JZ shares how Laurel redefines PM work to look more like engineering: feature work, testing, QA, backlog execution—augmented by agents. Meanwhile, historically PM-heavy tasks (competitive analysis, stakeholder writing, research ops) should be automated or delegated to workflows.
- •PM ontology intentionally mirrors engineering responsibilities
- •PMs own end-to-end quality: build, test, QA, fix bugs
- •Automate: competitive intel gathering, synthesis, scheduling, repetitive stakeholder comms
- •‘Build the system once, monitor it’ vs. doing manual deep work daily
- •OS surfaces skills just-in-time to change behavior
The Captain Model: assigning ownership by the most critical skill for success
JZ introduces the ‘captain’ concept: each initiative has a single accountable leader chosen based on the hardest part to get right (architecture, interaction design, content/business context). AI tools help non-engineers assess risk and pull in engineers for code review where needed.
- •Captain chosen by what matters most: engineering, design, data, PM judgment
- •AI tools can analyze codebase state and highlight risks
- •Non-engineers can ship when back-end is stable and risk is understood
- •Engineers still review risky parts; governance is integrated, not removed
- •Captain model reduces handoffs and accelerates delivery
Governance without bureaucracy: transparency, guardrails, and two-track product reviews
To prevent conflicts and quality issues, Laurel uses transparency (shared channels, visible PRs) and lightweight rules. JZ explains a two-track review system: small changes move fast with async checks; strategy/architecture shifts get rigorous reviews to preserve global coherence.
- •Transparency: channels for Devin/PR visibility and reviewer tagging
- •Guardrails: enablement guides + quick pre-checks for proposed changes
- •Two-track model: fast lane for small features; heavy review for systemic changes
- •Compress product reviews into async feedback loops when possible
- •Reject ‘no roadmap/no planning’ extremes—strategy still matters
Strategy example: expanding the meaning of time + operationalizing ‘unreasonable hospitality’
JZ describes product strategy reviews focused on where Laurel wins and expands—time tracking beyond billable hours to broader ‘time as a resource’ across roles. She also explains how the OS can systematize culture, like ‘unreasonable hospitality,’ by prompting personalized customer delight actions using captured context.
- •Strategic expansion: time matters even outside billable-hour firms (and in tech)
- •Humans focus on high-value work (relationships, onsite hospitality)
- •Automate logistics and prep to enable better human moments
- •Operationalize values: ‘unreasonable hospitality’ becomes a repeatable practice
- •Use transcripts/context (e.g., Gong) to suggest tailored delight ideas
Transformation playbook for non–AI-native companies: start small, build allies, scale 1% workflows
JZ argues every company will be forced toward AI-native velocity, but individuals can move first without CEO-level access. She recommends starting with small automations, building tools for other teams, rapidly generating playbooks with LLMs, and celebrating power-user workflows to spread adoption.
- •Competitive pressure will force change; don’t wait to be dragged
- •If you can’t ship code yet, build tools/workflows for another hungry team
- •Use LLMs to draft playbooks fast; refine with business-specific judgment
- •Create a culture of celebrating automation wins and sharing workflows
- •Scale the ‘1%’ experiments into standard operating practice
AI Ops as the new Biz Ops: the ‘Sasha model’ and CEO-level conviction
JZ explains how Laurel institutionalized AI adoption by creating an AI Operations function—full-time people whose mandate is workflow automation and tool-driven efficiency. She credits the CEO’s early conviction to re-architect the company around AI, while noting leaders at any level can still drive function-level transformation.
- •AI Ops: dedicated role to tinker, build workflows, and prove value
- •‘Sasha effect’: one great AI operator creates demand across every function
- •Path to scaling: AI Ops per domain (GTM, product, finance, etc.)
- •CEO conviction accelerates org-wide shift; Laurel re-architected post-2018 founding
- •Functional leaders can still map work, color-code automation opportunities, and drive change
Hiring the future PM: small orgs, senior builders, screen-share interviews, and 4 AI maturity levels
JZ forecasts leaner product orgs with more senior, judgment-rich builders who love hands-on work and can ship end-to-end. She details her screen-share interview to verify real AI practice and outlines four levels of AI maturity from chat usage to shared apps and customer-shipped workflows.
- •Trend: smaller orgs reduce coordination costs; more end-to-end ownership
- •Senior ‘ICPM’ builders can outproduce larger teams when AI-enabled
- •What she looks for: battle-tested judgment + curiosity + fearlessness + customer closeness
- •Interview tactic: screen-share to reveal real usage vs. buzzwords
- •Four AI levels: (1) chat/search, (2) workflow automation, (3) app building, (4) shared apps/shipping to customers
