Aakash GuptaHow to Build a Company OS in Claude Code | Jiaona Zhang | Product Growth
CHAPTERS
- 0:00 – 1:32
Cold open: the “1% vs 99%” AI adoption gap inside companies
Jiaona Zhang frames the core organizational problem: a tiny group of highly fluent AI users versus the vast majority who don’t know what to use, when. The episode sets up the solution: a company-wide operating system (OS) that makes AI workflows repeatable, discoverable, and consistently adopted.
- •AI adoption is uneven: power users experiment, everyone else stalls
- •The biggest bottleneck is “what tool/skill should I use right now?”
- •Company-wide systems can productize best practices across the org
- 1:32 – 5:37
Tour of Laurel’s Company OS: GitHub as the source of truth + Slack as delivery
JZ walks through Laurel’s GitHub-based company OS: a structured set of folders per function, broken down into activities and “skills.” She then shows how the OS becomes real behavior change when skills are surfaced in Slack—where people already work—via daily briefings and just-in-time guidance.
- •A single GitHub repo organizes operating playbooks across every function
- •Folders map: function → activities → skill files (how-to, templates, guidance)
- •Slack is the primary “runtime” for the OS: briefings, prep, and prompts
- •Company context/skills can be uploaded into Claude so people can call them on demand
- 5:37 – 9:00
Ontology-driven work maps: standardizing what great looks like for every function
JZ explains how Laurel maps each function’s work into an ontology: categories and tasks that define what the company expects people to do. This ontology informs which skills to build, what to automate, and where to shift human time toward higher-leverage work.
- •Every function’s work is categorized into a consistent task map
- •The ontology drives which skills exist and how they’re named/discovered
- •Goal: automate low-value repeatables; amplify high-value human judgment
- •Product work is increasingly shaped to look more like engineering execution
- 9:00 – 10:05
A 3-step path to build your own Company OS (starting small)
JZ outlines a progression from simple automations to a full operating system. Step one is deliberately small: pick one tedious workflow and automate it so the win is obvious and adoption is easy.
- •Step 1: pick one repetitive, painful workflow and automate it
- •Target common time sinks: templated emails, CRM updates, meeting prep
- •Use simple triggers/sequences before attempting a big OS overhaul
- •Early wins create momentum and credibility for broader change
- 10:05 – 12:30
Sponsor break: inbox + prototyping + agent measurement tooling
Aakash shares sponsor messages focused on AI assistance for email/calendar/Slack, prototyping that produces shippable code, and analytics for measuring AI agent impact. This break separates the “how to start” guidance from hands-on automation demos.
- •AI assistants embedded in Slack to handle inbox/workflows
- •Prototyping tools that generate production-ready front-end code
- •Agent analytics to connect AI behavior to product outcomes
- 12:30 – 14:32
Slack automation demo: feature request intake, triage, routing, and SLAs
JZ demonstrates a practical “Level 2” automation: turning messy feature-request chatter into a structured intake. The workflow automatically gathers required context, routes to the right owner, and creates a trackable ticket—reducing back-and-forth and speeding up product response.
- •Automate the questions you always ask (impact, frequency, evidence, context)
- •Auto-route requests to the right PM/team and set expectations (SLA)
- •Auto-create tickets for tracking and prioritization
- •Slack/Teams is often the best place to start because adoption friction is low
- 14:32 – 22:29
From playbooks to agent pipelines: sub-agents, “mega agents,” and tool choices (Dust vs Claude)
JZ explains how long playbooks become executable systems by converting steps into agents and workflows. A key insight: users won’t remember dozens of separate agents, so Laurel builds a “wrapper” mega-agent that routes requests to the right sub-agent, ideally delivered in the tools people already use.
- •Step 2: create playbooks, then audit what stays human vs can be automated
- •Convert playbook steps into agents; centralize access via a routing mega-agent
- •Tools: Dust/Glean-type builders were earlier easier; the gap is shrinking with Claude
- •Avoid “automation overload”: consolidate and deliver just-in-time in Slack/email
- •Skills can live directly in Claude as callable skill files
- 22:29 – 29:44
Culture as the multiplier: companywide hackathons + enablement to ship with Devin
JZ argues adoption starts with leadership and culture, not tooling. Laurel runs companywide hackathons and provides training so non-engineers can ship safely—using Devin as an agentic engineer—and then codifies those workflows back into skill files and guides.
- •Leadership sets expectation: AI-building is cross-company, not just engineering
- •Quarterly/regular hackathons normalize building across functions
- •Enablement guides teach non-technical staff how to ship to production with Devin
- •Real examples: PMs shipping front-end + back-end features end-to-end
- •Codify learning into playbooks/skills so it scales beyond early adopters
- 29:44 – 37:50
The captain model: who leads an initiative in an AI-native, cross-functional world
JZ introduces Laurel’s “captain” concept: every initiative has a single accountable lead, chosen based on which skill is most critical to nail for the outcome. With AI tools and strong review practices, captains can be PMs, designers, engineers, or even GTM—depending on what matters most.
- •Captain = accountable owner determined by the hardest/most critical success factor
- •Engineering captains for architectural shifts; design captains for interaction-led work
- •PM captains when business context + customer understanding are the core constraint
- •AI tools can assess codebase risk; humans still step in for contentious/risky parts
- •Code review and transparency keep cross-functional shipping safe
- 37:50 – 45:34
Two-track product reviews: move fast on small changes, align deeply on system-level bets
JZ describes a bifurcated review process: small, end-to-end builder work moves quickly with lightweight checks; major experience/system changes get heavier strategy and architecture reviews. She pushes back on the idea that “roadmaps are dead,” arguing strategy matters more when speed increases.
- •Track 1: small features ship fast with lightweight review and PR checks
- •Builders own end-to-end quality (reducing waterfall handoffs and QA loops)
- •Track 2: larger changes require product strategy reviews and system thinking
- •Roadmaps/planning still matter—speed without direction creates local maxima
- •Example: temporary initiatives shipped without a full product review
- 45:34 – 49:05
Making it real in traditional companies: start small, build playbooks fast, and scale the OS
JZ explains why even legacy orgs will be forced to adapt as competitors accelerate. She offers a pragmatic entry point—automate one workflow, or build a tool for another hungry internal team—then expand into ontologies and playbooks, which can now be drafted rapidly with LLMs.
- •AI-native operating models will spread because competitive pressure is inevitable
- •Start with one workflow; build credibility before attempting a broad OS
- •If blocked from shipping, build internal tools for other teams to prove value
- •Playbooks that used to take weeks can be drafted in minutes and refined in hours/days
- •Leaders should celebrate and scale the 1% workflows across everyone
- 49:05 – 54:39
The AI Ops (Sasha) model + CEO sponsorship: operationalizing transformation across functions
JZ shares Laurel’s structural lever: an AI Operations team whose charter is to tinker, systematize, and drive efficiency across the company—akin to “new biz ops.” She also emphasizes that CEO-level conviction accelerates the shift, but function leaders can drive meaningful change inside their domains.
- •AI Ops is the new Biz Ops: curiosity + relentless automation mindset
- •One high-impact AI Ops hire creates demand: “I want my own Sasha”
- •Scale AI Ops coverage by function (GTM, product, finance, etc.)
- •CEO courage/vision (re-architecting for AI-native) is a major accelerant
- •Function leaders can still mandate AI-enabled work maps and practices
- 54:39 – 1:07:59
Future of product teams: lean orgs, “product builders,” and interviewing for real AI maturity
JZ describes a shift toward smaller, more senior teams where individuals can ship end-to-end with AI support. She shares her interviewing tactic—asking candidates to screen-share their actual workflows—and offers a four-level AI maturity model from chat usage to shared apps and customer-shipped systems, ending by reaffirming that PM fundamentals are more important than ever.
- •Teams trend smaller: fewer people, less coordination cost, more ownership
- •Hiring focuses on senior judgment + hands-on curiosity + customer closeness
- •Interviewing: screen-share reveals real capability vs performative AI talk
- •4 levels of AI maturity: chat → workflow automation → app building → shared apps/customer shipping
- •Fundamentals (problem-first, customer-centricity, success metrics) remain constant even as tools change
