CHAPTERS
Why Laurel built a company operating system to scale AI use beyond the “1%”
Aakash introduces Jiaona “JZ” Zhang (CPO at Laurel) and frames the core challenge: a small fraction of employees are highly effective with AI while the majority don’t know what to use when. The episode sets up Laurel’s answer: a company-wide operating system that standardizes workflows, skills, and automation across functions.
GitHub as the ‘Company OS’: folder structure, skills, and cross-functional playbooks
JZ screen-shares Laurel’s GitHub repo that serves as a company-wide OS. Each function (CS, sales, marketing, engineering, finance, etc.) has structured folders mapping phases of work into repeatable activities and “skill files.”
Making the OS real: Slack-based daily workflows + AI ‘skills’ in company context
The OS becomes actionable when integrated into where people already work—Slack/email—rather than sitting as documentation. JZ shows how daily briefings and meeting prep connect to skills that can be uploaded into AI tools (e.g., Claude organization skills) for just-in-time execution.
The “1% vs 99%” problem and the ontology mapping of work
JZ explains how Laurel bridges uneven AI adoption by codifying best workflows from the most AI-native employees and distributing them organization-wide. They map each function’s work into an ontology (categories → tasks) to decide what to automate vs keep human-led.
Three-step blueprint to build your own Company OS (start small → playbooks → agents)
JZ lays out a progression for companies starting from scratch. Step one is a single tedious workflow automation; step two formalizes playbooks and audits which steps are human vs automatable; step three turns the playbook into agents and skills that run inside daily work tools.
Slack automation demo: feature request intake and triage without back-and-forth
JZ demonstrates a lightweight but high-leverage starting point: an automated workflow in Slack for feature requests. Instead of long threads, the workflow captures required context (frequency, evidence, impact), routes ownership, and creates a trackable ticket with SLA expectations.
From 55-page playbooks to an agent pipeline (Dust/Claude) and the ‘mega agent’ concept
JZ shows how large GTM playbooks become actionable by translating steps into agents. She explains why a “mega agent” (e.g., a GTM agent) that routes to sub-agents is more usable than expecting people to remember many specialized tools or commands.
Avoiding automation overload: consolidating scheduled tasks into a single OS experience
JZ discusses a common failure mode: building too many scheduled automations and overwhelming users with information. Laurel’s OS consolidates skills and automations into a coherent daily experience to keep adoption consistent across roles and proficiency levels.
Culture as infrastructure: company-wide hackathons and ‘everyone is a builder’
JZ argues the OS only works with the right culture and leadership mandate. Laurel institutionalizes building via recurring hackathons, training, and shared expectations that non-engineers can ship real improvements.
PMs shipping full-stack features with Devin: from onboarding UX to backend changes
JZ provides concrete examples of PMs shipping production changes, including both front-end and back-end work, using Devin as an agentic engineer. This reframes PM work from coordination-heavy to end-to-end product building with appropriate reviews and safeguards.
The Captain model: ownership based on the hardest thing to get right
Laurel assigns a “captain” for each initiative based on which discipline is most critical to success (engineering, design, product, data). The model clarifies decision-making while allowing cross-functional contributors to ship with AI assistance and targeted expert review.
Checks, balances, and transparency: code review, shared channels, and compressed collaboration
Aakash probes how Laurel prevents conflicts, maintains quality, and avoids duplicate work when many roles can ship. JZ emphasizes transparency (shared visibility into shipping), lightweight review channels, and ground rules that compress traditional product reviews into fast, async collaboration.
Two-track product reviews: when to move in hours vs when to do strategy/architecture review
JZ outlines a two-track review system. Small, end-to-end changes can ship quickly with lightweight review, while systemic interaction changes and strategy shifts require deeper alignment—product strategy review and architecture review—to avoid local optimization.
Scaling the transformation: AI Ops as the new BizOps (‘the Sasha model’)
JZ explains how Laurel operationalizes AI transformation by dedicating people full-time to building workflows, agents, and efficiencies. An AI Operations team (starting with Sasha) proves value and then expands, creating specialized AI Ops roles per function as demand grows.
Hiring for AI-native builders: screen-share interviews + the four levels of AI maturity
JZ shares her hiring method: ask candidates to screen share how they actually use AI to distinguish real capability from buzzwords. She defines four levels of AI maturity—from chat usage to workflow automation to app-building to shared apps/shipping—and uses it to assess individuals and organizations.
The future of product orgs: fewer, more senior builders + fundamentals that still matter
The conversation closes on how AI compresses coordination costs and changes team shapes: leaner product orgs with highly capable, senior product builders. JZ stresses that while tools and operating cadence change dramatically, core product fundamentals—customer-centricity and problem-first thinking—are even more important.
