Modern Creator
Why Modern Creator?
Aakash Gupta · YouTube

How to Build a Company OS in Claude Code

Laurel's CPO screen-shares the exact GitHub folders, Slack automations, and Claude skill files that let non-technical employees ship production code and operate like the top 1% of AI users.

Posted
1 weeks ago
Duration
Format
Interview
educational
Views
28.6K
693 likes
Big Idea

The argument in one line.

A company operating system built from per-function Claude skill files closes the gap between the 1% of AI-native employees and everyone else by encoding the top performer's workflows into something anyone can call on demand.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…
  • You lead a team or company and want a concrete, already-shipped blueprint for rolling out AI tooling beyond a handful of power users.
  • You are a PM, designer, or non-engineer who wants a real example of shipping front-end and back-end features using an agentic tool like Devin or Claude Code.
  • You are hiring for AI-native roles and want a practical, screen-share-based interview method instead of a take-home or whiteboard test.
  • You are curious how a real company structured playbooks, ontologies, and skill files at scale rather than ad hoc prompting.
SKIP IF…
  • You want a step-by-step technical tutorial on writing Claude skill files — this is a walkthrough of what exists, not a how-to build one from scratch.
  • You are looking for consumer-facing AI product advice rather than internal operations tooling.
TL;DR

The full version, fast.

Every company has a small percentage of AI-native employees and a much larger group who don't know what tool to use when. Laurel's CPO closes that gap with a "Company OS": a GitHub repo organized by business function, where each activity has a Claude skill file capturing how the best performer does that task. The build path is three steps — automate one tedious workflow, turn a full team playbook into an audited set of skills, then wrap specialized agents behind one router so people don't need to remember which agent to call. Delivery matters as much as the skill itself: automations live inside Slack and email, not a separate tool nobody opens. The payoff is concrete — non-engineer PMs and designers ship full-stack features to production, reviewed by a "captain" model instead of a handoff chain, and hiring now filters on a 4-level AI-maturity scale assessed via live screen share.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →
Voices

Who's talking.

02:04guestJiaona Zhang
00:00hostAakash Gupta
Chapters

Where the time goes.

00:00 – 01:46

01 · Intro

Cold open with JZ's 1%/99% framing, guest introduction, subscribe ask and bundle pitch.

01:46 – 02:04

02 · Episode begins

Aakash frames the episode: Laurel has taken personal/team AI operating systems to a company-wide level.

02:04 – 05:40

03 · The Company OS: GitHub structure screenshare

JZ walks through Laurel's GitHub repo: per-function folders (customer success, design, engineering, marketing, etc.), each with activity folders and skill files; shows Slack daily-briefing integration and org-level Claude skill upload.

05:40 – 09:00

04 · The 1% vs 99% problem

The core problem statement: a small number of AI-pilled employees vs. the rest of the org not knowing what to use when; the OS is the fix.

09:00 – 10:05

05 · 3 steps to build your own Company OS

Framework: (1) automate one tedious workflow, (2) build and audit a full playbook into skills, (3) wrap specialized agents behind one router agent.

10:05 – 12:30

06 · Ads

Ariso, Bolt, and Pendo Agent Analytics sponsor reads.

12:30 – 14:31

07 · Slack automation demo: feature request triage

Concrete level-1 automation example: a Slack bot that auto-collects context (Gong recordings, customer impact, urgency) before a feature request is triaged.

14:31 – 22:51

08 · Playbook to agent pipeline

Turning a 50-page GTM playbook into an audited set of skills/agents; introduces Dust as the agent-builder Laurel used before moving work natively into Claude skills; discusses the 'mega agent' router concept.

22:51 – 29:02

09 · Company culture and the companywide hackathon

How Laurel built adoption: company-wide hackathon at an offsite, Devin enablement guide so non-engineers can ship, concrete examples (temporary initiatives feature, empty-state redesign) shipped by PMs and a customer success team member.

29:02 – 29:44

10 · PMs shipping front-end and back-end features

Discussion of the scope of what PMs now ship — full-stack features, not just copy or growth experiments.

29:44 – 30:34

11 · The captain model explained

Every feature gets one 'captain' based on whichever skill (engineering, design, or PM/content) is most critical to the hardest part of the problem.

30:34 – 32:37

12 · Ads

Product Faculty AIPM Certificate and Customer.io sponsor reads.

32:37 – 37:38

13 · Continuation to captain model

Extends the captain concept into checks and balances: 'Ask Devin reviewers' Slack channel, transparency as the first principle, ground rules for what needs review.

37:38 – 50:08

14 · Two-track product reviews

Small features skip formal review (lightweight async checks only); larger system-level changes get full product-strategy and architectural review. Discusses why JZ rejects the 'no roadmap, no planning' AI-native extreme.

50:08 – 57:59

15 · The AI Ops team and the Sasha model

Laurel's dedicated AI Operations team, started with one person (Sasha) proving value; unreasonable hospitality as a systematized (not just cultural-poster) value; discussion of Ryan (Laurel's CEO/founder) driving the AI-native rearchitecture from the top.

57:59 – 59:01

16 · The screen-share interview

Transition into JZ's hiring philosophy: every candidate, any function, screen-shares their actual AI workflow.

59:01 – 1:06:08

17 · The 4 levels of AI maturity

Defines the 4-level framework (chat, workflow automation, personal apps, shared/shipped apps); discusses PM team shrinking to 5 PMs + 4 designers, the 'orchestrator' profile, and displacement fears among junior PMs.

1:06:08 – 1:07:59

18 · Outro

Fundamentals-never-changed closing, milestone shoutout (40K YouTube subs, 565K avg views/episode), recruiting pitch for Laurel PM roles, subscribe/rating ask.

Atomic Insights

Lines worth screenshotting.

  • Every company has a 1% who are AI-native and a 90-99% who don't know what to use when — the gap is a distribution problem, not a talent problem.
  • Build the ontology before the OS: map every function's work into categories and tasks first, then decide what gets automated versus what stays human.
  • A separate agent tool in a new tab won't get adopted consistently — deliver skills and automations inside Slack and email, where people already work.
  • When AI adoption is everyone's responsibility, it's no one's responsibility — dedicate one person full-time to AI Operations and let their visible wins create demand from every other team.
  • A 50-page team playbook can be turned into a first draft in under a minute with Claude, though making it accurately reflect the business still takes hours, not weeks.
  • The captain model replaces the handoff chain: every feature has one owner end-to-end, chosen by whoever holds the skill most critical to that feature's hardest problem.
  • A PM at Laurel shipped a full front-end-and-back-end feature — deeply integrated with billing and time-entry logic — despite self-identifying as a designer, not an engineer.
  • Laurel's CPO went from managing hundreds of people to 5 PMs and 4 designers, because adding headcount adds coordination cost that cancels out one PM's expanded capacity.
  • The new AI-era interview is a live screen share: watching someone's actual daily workflow reveals their real AI maturity level in under a minute, unlike a resume claim.
  • The 4 levels of AI maturity are chatting with a model, automating one workflow, building personal apps, and building shared apps that ship to real users.
  • Small features skip formal product review and go through lightweight async checks like an "Ask Devin reviewers" Slack channel; only larger, system-wide changes get a full strategy and architecture review.
  • The most durable culture change came from a company-wide hackathon that included every function, not just engineering, establishing that everyone is expected to be a builder.
  • PM fundamentals — staying close to the customer, starting from the problem instead of the solution — haven't changed; only the tools and the speed of execution have.
Takeaway

Encode your best worker's judgment, don't just buy another tool.

WHAT TO LEARN

The gap between AI-native teams and everyone else isn't access to tools — it's that nobody wrote down what the 1% actually do, and nobody delivered it where people already work.

03The Company OS: GitHub structure screenshare
  • A company operating system can live in plain GitHub folders organized by business function, with each activity inside a function tied to a specific skill file.
  • Delivering the system through Slack (daily briefings, surfaced skills) matters as much as building the skills themselves — the interface people already use is the real adoption lever.
053 steps to build your own Company OS
  • Start with the single most tedious repeated workflow in your day — that's the entry point, not a company-wide rollout.
  • Graduate from a single automation to a full audited playbook, then to a router agent that dispatches to specialized sub-agents, in that order.
08Playbook to agent pipeline
  • A dedicated agent-building tool (like Dust) can make sense early on, but the gap between specialized tools and building directly in Claude skills is closing fast.
  • A single 'mega agent' that routes requests to the right specialized sub-agent solves the real adoption problem: nobody remembers which of a dozen agents to call.
09Company culture and the companywide hackathon
  • A company-wide hackathon that includes every function, not just engineering, is what actually shifts the belief that 'everyone is a builder.'
  • Non-engineers shipping full-stack, billing-integrated features (not just cosmetic changes) is a credible bar for what 'AI-native' should mean in practice.
11The captain model explained
  • Assign feature ownership by whichever domain is hardest to get right for that specific feature, not by job title.
  • End-to-end ownership, including testing your own feature, removes the classic waterfall blame loop between PM, designer, and engineer.
14Two-track product review
  • Reject the extreme version of 'AI-native' that discards roadmaps and planning entirely — local speed without a shared strategy produces fast motion without real progress.
  • Decide upfront which bucket a feature belongs in (fast lightweight track vs. full review track) so speed and rigor aren't fought over case by case.
15The AI Ops team and the Sasha model
  • A single AI-operations hire who demonstrates clear value creates organic demand — every other team will want their own version once they see the results.
  • Cultural values like 'unreasonable hospitality' become real when systematized into a workflow trigger, not left as a poster or a doc nobody revisits.
17The 4 levels of AI maturity
  • Score AI maturity on a 4-level scale — chat use, single-workflow automation, personal app-building, and shipping shared apps — for both individuals and whole teams.
  • Expect team sizes to shrink, not grow, as the most senior, AI-fluent operators take on more end-to-end ownership themselves.
  • The best-positioned people are 'orchestrators' — broad strategic thinkers who can also execute in detail — because they no longer need to be complemented by a full team of specialists.
Glossary

Terms worth knowing.

Company OS
A company-wide, GitHub-organized library of Claude skill files, one set per business function, that encodes how the most AI-proficient employee performs each recurring task.
Skill file
A reusable instruction set (in this case built for Claude) that captures the steps and judgment needed to complete a specific recurring task, callable on demand instead of re-explained each time.
Ontology (work map)
A structured map of every task a business function performs, used to decide which tasks should get more human attention and which should be automated.
Captain model
An ownership structure where one person — chosen by whichever skill is most critical to a feature's hardest problem — takes that feature from start to finish, replacing sequential handoffs between PM, design, and engineering.
AI Operations (AI Ops)
A dedicated internal role or team, analogous to biz ops, whose full-time job is finding and rolling out AI-driven efficiencies across the company.
4 levels of AI maturity
A scale used to assess an individual's or team's AI usage: Level 1 is chatting with a model, Level 2 is automating a single workflow, Level 3 is building personal apps, and Level 4 is building shared apps that ship to real users.
Product builder
Anyone — PM, designer, or engineer — who takes a feature from conception through shipped production code, rather than handing pieces of the work to specialists.
Resources

Things they pointed at.

22:40toolDust
29:05toolDevin
10:05toolAriso ↗
10:56toolBolt ↗
11:45toolPendo Agent Analytics ↗
30:34productProduct Faculty AI PM Certificate ↗
31:23toolCustomer.io ↗
00:00productLaurel ↗
Quotables

Lines you could clip.

00:01
“You got these people who are these 1% AI users. They're highly AI pilled, and then you have the 90 to 99% of the rest of the organization who isn't sure what to use when.”
crisp problem statement, works as a cold open for any AI-adoption content→ TikTok hook↗ Tweet quote
51:04
“AI ops is the new biz ops.”
short, quotable reframe of an emerging role→ IG reel cold open↗ Tweet quote
1:04:26
“One PM can do so much more than ever before, but there aren't that many of them who are that skilled.”
captures the bifurcation thesis in one line→ newsletter pull-quote↗ Tweet quote
53:36
“When you add more people, you add more coordination costs. You actually have a harder time making people feel like they are absolutely responsible for taking something end to end.”
counterintuitive team-sizing argument→ TikTok hook↗ Tweet quote
1:05:00
“The fundamentals and the principles have never changed. In fact, they're even more important than ever before. But the tools and the way you operate, that's radically changed.”
strong closing line, works as episode outro pull-quote→ newsletter pull-quote↗ Tweet quote
Topic Map

Where the conversation goes.

00:00 – 02:04sparseCold open + intro
02:04 – 09:00denseCompany OS live demo (GitHub, Slack, skills)
09:00 – 12:30steady3-step build framework + ads
12:30 – 22:51denseSlack automation demo + playbook-to-agent pipeline
22:51 – 30:34denseCulture, hackathon, non-engineers shipping
29:44 – 37:38steadyCaptain model + review process + ads
37:38 – 50:08denseTwo-track product review
50:08 – 57:59denseAI Ops team, culture origin, CEO buy-in
57:59 – 1:06:08denseHiring: screen-share interview + 4 levels of AI maturity
1:06:08 – 1:07:59sparseOutro
The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphoranalogystory
00:00You got these people who are these 1% AI users. They're highly AI pill, and then you have the 90 to 99% of the rest of the organization who isn't sure what to use when. Meet Jay z.
00:10She is the chief product officer at Loro, the $100,000,000
00:14AI time platform. Platform. She teaches PMS Stanford.
00:17Before just, she was the CPO at Linktree, and she's led product at Airbnb, Webflow, Dropbox, and WeWork. You do something pretty crazy in your interviews.
00:26Can you tell me how you interview people and really find these gem AI pills super senior ICPMs?
00:32The fundamentals and the principles have never changed. In fact, they're even more important than ever before. But the tools and the way you operate, that's radically changed.
00:42How should people be thinking about in an AI native organization? This is the role of a PM. And so those are the four levels.
00:48Level one is you're talking to ChatGPT. You're talking to Claude. You're really using AI kind of in chat mode.
00:53Level two is where you start to automate a workflow. Level three is when you start building, you know, apps. And then level four, I'd say, is where you're actually building, I call, shared apps.
01:02How does someone start from step one? What is the process somebody needs to go through in order to build up and create their own company operating
01:10system.
01:15Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. And if you wanna get access to amazing AI tools, check out my bundle where if you become an annual subscriber to my newsletter, you get a full year free of the paid plans of Mobin, Arise, Relay app, Dovetail, Linear, Magic Patterns, DeepSky, Reforge Build, Descript, and Speechify.
01:38So be sure to check that out at bundle.akashg.com, and now into today's episode.
01:46Jay z, I've been teaching people a lot about how to use Cloud Code with personal operating systems, with team operating systems. You guys at Laurel have taken it to a level I have not seen before. You guys have built out a company operating system.
02:01Can you show me what this is and what it does? Of course. Alright.
02:06Let me screen share here. Okay. Let's start here.
02:08Let's go to GitHub, our favorite place. And so you'll see here that we have in GitHub a company wide operating system where for every single function in a company, customer success, data science, design, engineering, finance, imitation, legal, marketing, we have, um, essentially all these folders that share how do you think about each phase of work that that function does.
02:35So in customer success, you do account management. And within account management, you're thinking about, you know, renewals, upsells.
02:42Um, you do a customer enablement. And within that, we essentially work with our customers. We do office hours.
02:48We help them with rollout. We do training and onboarding. Each of these folders have a skill.
02:55And I think, uh, for those of you who are less familiar with GitHub, we'll actually hop over here to something that is very familiar, which is essentially your file structure, your folder structure. And so going to customer success, you can see that each of these folders have a series of, um, you know, folders that are the are the activities that they do.
03:15And then within each of them, they have skills. So how do you actually think about creating the right assets for the negotiation support or the right references? I'll go back one more, um, for renewals.
03:27Right? Um, what is the skill file there to really think about how do you walk through a renewal correctly with a customer? And now you're like, okay.
03:36Cool. You have some folders in GitHub. You have, you know, some some stuff that you can download.
03:41How does this all come to drive, like, real change? And the way I'll talk about this is, you know, at the end of the day, we all live in some form of email or Slack.
03:53And so what I'll do really quickly is I'll open up my Slack. And, again, this is not real data in the sense that we do have very sensitive data that I'm not gonna be be sharing. So this is a little bit more mock, but it shows you exactly how our how our team operates.
04:06So for example, every single morning, every person on a lot of these customer facing teams, right, they're highly, um, repeatable motions. The more we can, uh, sing from one voice and say the same thing, the the the way we can, um, create consistency and the awesomeness of the customer, uh, experience, that makes your company much more unified.
04:28And it's a big part of the brand. And so when you think about that and you think about a customer success person waking up in their day and really seeing let me go here.
04:38This is a example for customer success. Here's your calendar. Here are all the meetings that you have, the check ins that you have, you know, the onboarding sessions you have.
04:47This is something that a lot of people are building, this example of a chief of staff light concept. But what we're now doing is we're integrating all the skills. So for example, when we do a handoff, when we do a session prep, um, all of these are actual skills.
05:02And what happens is then when anyone is using Claude, for example, and I'll just go into, um, I'll I'll go really quickly into the organization settings, and I go into your skills, you can start to see that you can upload all of these skills into your company context.
05:19And as a result, when you're going through your day, you can essentially say, great. I'm going through my day. I'm doing all these things.
05:25My, um, I will use these skills so that I no longer have to spend all the time creating that one deck or spend all that time creating an email. It is actually, um, something you know exactly what skill to use when. And I think that's the biggest thing that, um, companies struggle with, which is you got these people who are these 1% AI users.
05:44They're, uh, tinkering with their workflows. They're highly AI pilled. And then you have the, you know, 90 to 99% of the rest of the organization who isn't sure what to use when.
05:54And so as a result, you can actually integrate your skills, again, at a company level. So across every single one of these functions, going back to files, each one of these functions and all the activity that they do in order to be able to understand what, um, skill should I should I be using when and where should I be spending my time.
06:13Maybe the last thing I'll just show to kind of, um, to really bring this to life is every single company, you can map every single functions work to what I call an ontology. So in sales, you know, all of the work in sales maps to these categories that they're supposed to be doing.
06:28And within each category, there are a series of tasks that happen. And this is actually what has informed the ontology that I just showed you. We've done the really hard work of mapping out, okay, for every single function.
06:39Again, I'll scroll through this. Marketing, sales, customer success, implementation, design, engineering, so on and so forth. These are the things that we believe that each function should be doing.
06:48How do we actually create, um, a set of skills to for for you to, um, do the things that we want you to be doing more and to also automate the things that we don't want you to be doing anymore. So I'll go to product, which is, you know, a lot of the audience here today.
07:03In product, what's really interesting is that, you know, you should be spending your time like an engineer in many ways. And we talk about this later where the ontology or the work map of a product manager is starting to look a lot more like an engineer.
07:17But there are a lot of things that used to be in the day to day of a product manager, doing competitive market analysis, doing these all these, like, writing for stakeholder management or, um, really mundane tedious organization, um, getting people on a phone, synthesizing, um, feedback, etcetera.
07:36All of these things, as we all know, are starting to get automated. But again, it's automated in a really lumpy way, where one PM might be doing it really, really well. Another PM might not be doing it as well.
07:46So what we can do here is when you onboard everyone with a company OS, again, going back to this GitHub and going to, let's say, product, right, you can start to say, hey.
07:57These are all the playbooks, all the skills that I wanna give every single person on my team. And then when they come in for their daily briefing, what ends up happening is that they are able to see their day at a glance, and we essentially tell you where you can automate your day.
08:13So you take the thing that is that is essentially designed by the 1% of of every any given function, the person who is playing around the most, and you're able to spread those learnings throughout the entire rest of the organization.
08:25Wow. I think this is so powerful because we all have been working in different teams where there's that one person who's got their skills locked. But if they're just compounding in a bucket, then nobody can really benefit.
08:37This company OS, this is bringing that power to everybody. Now you guys are an AI native company.
08:45You guys are an AI company yourselves, and so you guys would have certain advantages
08:50in building this. How does someone start from step one? What is the process somebody needs to go through in order to build up and create their own company operating system?
09:00I like to think about it as three different steps. And so let me screen share again, and I will, um, share how do I think about essentially, um, getting your steps in, going from most simple to most advanced. So the first way to think about this is how do you just start small?
09:15What is one workflow that you or your team does that is incredibly tedious that you shouldn't be doing again? So typically, for many, many functions, it is, you know, I write this email, and I want this email to have a template that is automatically, you know, um, kicked off for me when, um, x y z things happen, or there's a sequence of things that happen.
09:35I don't wanna input, um, my data into a CRM anymore. I want that to be automated.
09:40So there's some degree of thinking about what is super mundane takes a lot of time out of your day today. And if that were to be automated away, you'd be thrilled about. And I'll give you one very, um, product oriented example, which is there are so many companies out there, so many PMs out there that spend a lot of their days responding to questions, escalations.
10:03So the sales team comes into a channel. I'm notoriously bad at my inboxes. I guess there's a version of that where I seem cool and unavailable, but the reality is I miss sponsor emails, guest pitches, and stuff that my team actually needs me for.
10:15So I got an AI assistant, the sponsor of today's episode, Ariso. Ariso connects to my email, calendar, and Slack. Then I just chat with it over Slack, and it helps me with everything.
10:26It builds workflows to respond to emails, resolve customer issues, prep me for meetings. It actually comes to my meetings, updates its own knowledge, and remembers context from past conversations. So every time I talk to it, it already knows what I'm working on.
10:41I used to pay for granola and Lindy separately. Ariso replaced both. One tool does more, and it lives right in Slack priority work.
10:48Check it out at ariso.ai/akash. That's ariso.ai/aakash. Here's the dirty secret about prototyping.
10:57You spend two weeks building a prototype. You validate your assumptions. Engineering loves the direction.
11:02Then what happens? You throw the whole thing away. Bolt changes this completely.
11:06When you prototype in Bolt, you're not building throwaway mock up. You're building real front end code that integrates with your existing design systems. So when you hand it to engineering, they don't throw it away.
11:16They ship on top of what you've built. I use Bolt every single day. I host my LAN PM job cohort on it.
11:22And honestly, I'm up till 2AM some days just vibing in the tool, having fun, and building. That's when you know a product is good. When you're using it past midnight, not because you need to, but because you want to.
11:32Check out Bold at bold.new/akash. That's bolt.new/aakash. Link in the show notes.
11:41Today's podcast is brought to you by Pendo, the leading software experience management platform. McKinsey found that 78% of companies are using GenAI, but just as many have reported reported no bottom line improvements. So how do you know if your AI agents are actually working?
11:55Are they giving users the wrong answers, creating more work instead of less, improving retention, or hurting it? When your software data and AI data are disconnected, you can't answer these questions. But when you bring all your usage data together in one place, you can see what users do before, during, and after they use AI.
12:12Showing you when agents work, how they help you grow, and when to prioritize on your road map. Pendo Agent Analytics is the only solution built to do this for product teams. Start measuring your AI's performance with agent analytics at pendo.io/akash.
12:25That's pendo.io/aakash.
12:30Okay. So let's move into Slack and see what this might look like. You know, a lot of companies, if you just go into any Ask product channel or any channel, you see so many, um, success folks, um, support folks, sales folks, um, other teams hitting up that channel, asking people, hey.
12:46I have a question. I have a feature request. And so the very small workflow that we did, and I'll go all the way down, is we created a Slack automation that essentially said, look.
12:56When a feature request comes in, we typically spend a bunch of time going back and forth asking about how many times was this asked about. Send me the Gong recording where I could watch what the customer's actually saying. Um, what is the impact of this for your customer, which requires some degree of judgment from the person managing the account?
13:13Um, what is actually going on here? Give me some more details. All of those things usually require back and forth.
13:19So, again, if I go back to this this system of how do you think about a a place to start, what is something that you do over and over again that you could really easily automate? And that automation to for us was as simple as, hey. Let's just automate what we ask someone to fill in.
13:35And then what often happens is you then have to triage it. You say, hey. You know, is it for this team or that team?
13:41Is it for this PM or that PM? And what's the SLA to getting back to the, um, request on what we're doing about this feature request? And so all of that you can build into something as simple as Slack.
13:53So, again, a lot of people have Slack, Teams, whatever it is you're using to chat with your teams. You can do something very simple where you essentially say, okay.
14:00Great. I come in here. Um, I'm going to automatically, um, ask for all of this information.
14:06So, you know, what is it? Who is it coming from? What's going on here?
14:10It automatically assigns it to the person that, um, makes the most sense to go look at this. Um, and then it automatically creates some kind of ticket so that we can track it. And so all of that, again, this is one zero one, I would say.
14:22Right? It's just like a very small step in in creating your operating system. So I start there.
14:26The next step is this idea of how do you start to really automate based on a bunch of things that your team is doing.
14:35And so the example here I have is, you know, again, a team that usually has a lot of people, a lot of humans. Um, at Laurel, uh, we have a large, you know, GTM team within, um, GTM, uh, go to market. We have, um, really awesome success folks, um, who are essentially, you know, what I call, like, time consultants.
14:53They're getting kind of forward deployed into these organizations, helping them use Laurel as a as a product.
14:58And so what we've done is we've essentially created a playbook. And, again, this is very, very long. I think anyone who's ever created a playbook before, this is 50 pages.
15:06It covers everything from implementation to onboarding to user onboarding. And and depending on who you are. Is it the admin?
15:13Is it the actual, um, timekeeper, etcetera? You know, different onboarding.
15:17These things, by the way, are very fast now with Claude. You can actually create this from a lot of sources and have it be written really quickly. But what the struggle most companies has is now that I've created a playbook, how do I actually get people to do the playbook?
15:31And how much of the playbook is actually done by the human versus actually done by, you know, agents or workflow automations? Right? And so this is where, again, going back to this concept of of the playbook model, this is where you can say, okay.
15:45Well, I've created a playbook. I've went through, and I've audited the things that, again, it requires a human to do. It requires a human to get on the phone with someone.
15:53It requires a human to go fly on-site. Um, but here are the things that we think we can automate. This is either, um, something we can productize, or this is something that we can create an agent to do.
16:03And so that is, I would say, the next step that you graduate to, where you essentially create a playbook. And then off of the playbook, you decide on a set of skills. And that's, by the way, where we started to get the first version of the OS I showed you earlier.
16:18When we went into customer success and we said, what are all the things that someone might be doing? These large buckets. It was largely off of playbooks.
16:26The playbooks for implementation, the playbooks for, um, activating a customer, the playbooks for really talking to them the right way to make sure that they're set up for success.
16:36And so that is really the the second way to think about it. And, um, maybe I'll share one thing here, is there are a lot of, um, agent builders out there today in the world. So you could use know, Claude itself.
16:46They've launched, obviously, a lot of, um, agents. You can use, uh, a lot of things from OpenAI as well.
16:52You can use a Glean. You can use a Dust. We, at Laurel, use Dust.
16:56And so I'll take a moment and see if this loads. So if somebody hasn't heard of DUST, yeah, this is an agent building tool?
17:03This is an agent building tool. And what we find is often a lot of the, um, things that someone does can be turned into a series of repeatable steps that gets automatically triggered.
17:14And so a great example, and I'll just go scroll down here really quickly, all of these are agents that we have built. So going back to the, um, the the playbook concept, if you say, hey.
17:26I have a playbook of all the things that you need to be doing here. And, again, 55 pages worth. I don't think anyone's gonna read anything here.
17:33Um, what you can start to do is go into an agent builder and say, I'm gonna create an agent for each of these steps. If I have to draft emails a lot as a customer success manager, if I have to actually scrape LinkedIn a lot as a salesperson, if I have to look at the market as a salesperson or think about prospecting questions, each of these can be you can build an agent for each of the parts of the workflow here.
17:57And then going back to really thinking about how does everyone engage with your operating system thoughtfully, no one's gonna remember that they're gonna call the specific agent that's gonna do the email and the specific agent that's gonna do the RFP.
18:11The the big learning that we've had is how do you create a wrap, like a like a mega agent, something like the a, um, a go to market agent that can be called by the sales team at any point, by the success team at any point. And then that agent is able to route the ask, the the need, or the help to whatever one of these sub agents that is actually useful.
18:34And then going back to, like, really, the delivery piece is so important. Even the friction of coming to something like a different interface, coming to a desk and asking it questions is is really low. In instead, actually going into your, um, your Slacks, your emails, and delivering people just in time playbooks and automations is really the way to go to get to the point where you're you're actually getting people to use the agents and the workflows that you've built.
19:02So help me understand this part. Why use Dust instead of just all Claude or Claude code? Yeah.
19:07That's a great question. We started using Dust back in fall of last year, and so I think there was just a maturity of the tools. Back then, it was just much easier to use something that specialized in agent building like a Glean or a Dust.
19:22I do think today there is that gap is shrinking quite rapidly. And so as a result, I don't think you need to go out there and buy a specialized tool that does these.
19:32And in fact, you can just build them in Claude. And this is actually a little bit where we're going, which is if I go back to the operating system that I was showing you earlier, and all of these no longer have to go through a DUST or a Claude. Instead, what we're able to do, make this much larger, is we can we can take all of these skill files and go into Claude itself and put them in as skill files.
19:56And so as a result, you could, um, now you can literally just say, hey. I'm inside whatever it is I'm doing, and I can just call the you know, that skill slash morning briefing product.
20:08And as a result, it gives me my briefing right there as opposed to me having to go and call an agent builder. And
20:14then should people be setting up, like, automations on top of these to be running these? Is your daily morning, like, running on a schedule or something like that?
20:23Yeah. That's a great question. It's so funny.
20:25Um, I'll go I'll share a little bit of my personal experience. So I set up a bunch of these schedule things. And even if I just go to scheduled, I'll go right here.
20:33You can see that I have a lot of these scheduled tasks, and you only see a couple of these pinned. And what I found was that, um, I it was almost overkill. It was like I sat there.
20:45I was like, oh, I might automate this, and so I built it. I like, oh, I might automate that, and so I built it. I was like, that might be interesting information.
20:51I built it. And, actually, I think we're in a world where we are we we have information overload. And so this is why we took the time as a company to be like, we can't just assume that people first of all, that they're gonna do this for themselves.
21:03And second of all, that they're not gonna be overwhelmed by the number of, like, automations and, you know, uh, schedule things that happen. And as a result, that's how we consolidated it all into what I was showing you earlier, which is this this idea of actually having all in one place because the chances that you're gonna come back and say, okay.
21:22And, again, this is this is this is also to to, uh, make sure that the information or, like, the adoption of AI is actually consistent across the org, and that's the main thing. I think that you see a lot of, let's say, PMs be super AI native, a lot of engineers be super AI native. You don't see the same across all the functions, um, and potentially sometimes the go to market functions.
21:41And so as a result, we really think hard about how do we deliver that to you in the form of something that you can look at on a daily basis and really be integrated with, um, your workflow. And the last thing I'll share, um, at Laurel is we think a lot about how do we surface it even more just in time.
21:58And what we're able to do, um, in terms of our product is we're able to detect what it is you're working on when. Okay. So I think I get it.
22:05Right? The thing that you are encoding
22:08that's most important is not the scheduled tasks or this particular interface and dust. It is the actual skills, and you are enabling the least AI proficient people at your company to operate at a similar level to those AI native people.
22:23What is the right company culture? How do you really get people to take advantage of a company OS like this? Yeah.
22:30Absolutely. I think it really starts with culture.
22:32I just have a few photos from our off-site about three months ago. And it's really important to for it to start from the top, from leadership to say, this is so important to us.
22:45It is not just an engineering thing. It is a cross company thing. And what we did at this off-site is we did a company wide hackathon, and I do know of a lot of companies that do this on a regular basis.
22:57How do we do a company wide hackathon every quarter, every six weeks?
23:02Right? Or how do we even get the just the go to market team to do a company do a hackathon and show what it is that they're building so that the expectation that, you know, everyone is a builder is is true everywhere in the company, not just in engineering. So with this, um, what we did is we did two things.
23:18One, we did, um, training. And so what we did is we actually did a lot of training around, like, how do you actually ship to production even if you're not technical? Uh, so we created this enablement guide for how to ship features with Devon.
23:32And so, you know, Devon essentially is like an agentic engineer. You can give it tasks. It it it started off, I would say, a year ago, two years ago when we first started using this as almost like intern level engineer.
23:45And today, I think it it's actually, you know, a decent software engineer. It's not a staff level software engineer, but it does a lot of things. And as a result, you know, um, my team is able to ship.
23:54And I'll just get go through a couple examples. Here is, um, a feature an end to end feature, which includes front end changes and back end changes, where, um, you know, we enable people to to delete temporary initiatives.
24:08So when you're keeping your time, sometimes you don't know what matter or what project you're working on yet, but you know that you're doing some amount of work that should be grouped together and submitted at the end of the day. And so that's where temporary initiatives is really powerful. Now that, again, is a front end and back end feature.
24:23It is not just a front end, like, almost like cosmetic change. It's actually pretty deeply rooted in how does it interact with PMSs and other systems, and when does it release versus not. There's there's a lot of complexity in something like, um, temporary initiatives.
24:39And so this, by the way, you know, if you look at the person actually knocking down those tickets and committing these PRs, this is actually a PM on my team.
24:47And I'll just go to their LinkedIn briefly. Um, Nick, who's awesome, has been at Laurel for some time. If I go back to his educational history, right, like, um, we we didn't grow up.
24:58Many of us didn't grow up as engineers. And yet Nick, I I would say he's probably identifies self identifies more on the design side than on the engineering side, is able to take this feature end to end, which I think is just so cool.
25:13Similar similarly, um, within, you know, many parts of our product, and I'll just go through another example here, this is the empty state for when someone comes in.
25:24So really think about new user onboarding. What is it that they see? How do how do we make that experience super delightful?
25:30All of this is done by, um, by Jessica, who is, again, a PM on my team, not an engineer, and also not a PM who necessarily started their career in, um, in engineering or studied computer science.
25:45And so I think this is just such a great example of people being able to ship even when they're not technical. And maybe the last thing I'll show you, because I think this is even cooler, is, uh, this little picture here, um, which is this is someone on our customer success team.
26:00Ashley is amazing. She deeply understands our customers and their needs. And by working with the PMs on the team to really create this enablement guide for Devon, they worked on this together so that, again, if if you are even less technical than a PM, right, if you're on a success team, how might you use this guide to be able to really ship the way, you know, in a safe way, in in a reliable way.
26:25And then all of these pieces we then broke down to say, well, should we start building skill files, you know, agents to help you so that when you're trying to do this thing that typically is a playbook and, this is not 55 pages, but it's still eight pages. You are able to get the help and the support you need. And so that is really again, the the crux of it all is understanding what is the work that you're doing, how do you start to document that down, and then really clearly define these are the parts that remain human centric versus these are the parts that should be automated away.
26:57I'll pause there, but I think it's also really cool to look at this on ontology, which is essentially, you know, for every single function in the company. What are all the buckets of work that they're doing? And and what we do is actually we we actually spend cycles saying, you know what?
27:10We believe that, like I said earlier, a product person should be operating like an engineer. So all of the the things that we expect an engineer to do, we expect them to be doing feature work. We expect them to be testing.
27:23You know? We're we expect them to actually, like, crank through the backlog. The exact same things show up in what we want PMs to do.
27:30Um, it is it is not a, um, uh, an error where, you know, here in Ontology, we really have things like, we want you to be, you know, doing future work with agents. We want you to be, um, you know, actually QA ing your your product and fixing the bugs, not just, like, QA ing in in the ways that people were doing before.
27:48And what we don't want you to be doing is things that were really tedious, like synthesizing competitive market, you know, intelligence, actually writing these, like, detailed briefs, doing research planning, doing reach out for the the research, synthesizing the research, like, all of that.
28:04You know, competitive analysis is a great example. It should you should be spending time building the agent to pull the competitive data, and you should just be monitoring it. But you shouldn't actually be doing the deep work every single day and, like, set up the system instead.
28:17And so when we actually create this ontology, we're able to say, well, we want these numbers to go up. We want everything in green, the time spent doing that to go up.
28:27I want to see Nick doing this. I wanna see Jess, you know, shipping this this this feature end to end. But what I want you to stop doing is I want you to stop doing these things that are really tedious or the very least be calling an agent every single time that you wanna do that.
28:44And and then, again, going back to, you know, how do we make that true by building the skill files, by building the agent agentic workflows where necessary, and making sure that we're surfing for surfacing them where people work.
28:59And that's ultimately the the key pieces of the system. Wow. There is so much gold buried
29:05in the various parts of your answer there. The first part I wanna double click on first is PM's shipping to production. Okay.
29:12People have heard about that. But PM's not just shipping.
29:16Okay. Here's this little growth experiment where we change the text in a button, which is a front end only change, but a front end plus back end core feature, this temporary initiatives feature, for instance, that we looked at.
29:29That's crazy. So talk to me a little bit about what is the scope of what PMs do ship to production, and how should people be thinking about in an AI native organization?
29:41This is the role of a PM today. We talk a lot about this in terms of, uh, what is engineering anyways?
29:48What is product anyways? What is design anyways? And we've really landed on this concept of, um, we want there always to be a captain of any given initiative, and the captain is the person where that skill set is the most important.
30:05And so there are lots of features. Let's say we need to, uh, overhaul a system in order to make it much easier for, let's say, PMs to ship and agents to work in that code base.
30:16Usually, the captain is an engineering captain because that's an architectural change. If we have a feature where, um, the, like, the interaction is really king, You know, we're doing this really cool stuff on mobile to make it so easy and delightful to kind of, like, look at how you spend your time in a given day and get insights from that.
30:34I hope you're enjoying today's episode. Are you interested in becoming
30:37an AI product manager, manager, making hundreds of thousands of dollars more joining OpenAI, ananthropic? Then you might wanna do a course that I've taken myself, the AIPM certificate ran by OpenAI product leader, McDad Jaffer.
30:50If you use my code and my link, you get a special discount on this course. It is a course that I highly recommend. We have done a lot of collaborations together on things like AI product strategy.
31:02So check out our newsletter articles if you wanna see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavel Hearn, is the Build Labs leader, so you're gonna live build an AI product with Pavel's feedback if you take this AIPM certificate. So be sure to check that out.
31:17Be sure to use my code and my link in order to get a special discount. And now back into today's episode. I used to think I had a retention problem.
31:24Turns out I had a messaging problem. I was sending the same onboarding emails to every new user, whether they activated on day one or never logged in again. I had no idea who was slipping or why.
31:34Customer.io changed that. Every message I send is now based on what users actually do in the product.
31:39Someone hits a key activation moment, they get nudged to the next one. Someone goes quiet, they get a different path entirely. Their AI agent makes it fast.
31:46I describe the campaign I want, and it builds the full journey form. Triggers, timing, copy, even branching logic.
31:53And when I want to know how something is performing, I just ask the agent directly, it tells me what to do next. They also have an MCP server, which means AI tools like Claude can see directly what's happening in customer.io workspace.
32:05Your segments, your customer data, your attribution, all of it. So instead of explaining your business context every time you need help, Claude already knows it.
32:13Notion used customer.io to personalize their onboarding and hit nearly 50% open rate, improved conversion by six to 7% with localized campaigns, and pushed open rates up another 20% through AB testing.
32:27The idea is simple. Customer.io
32:28helps you deliver more impact from every message you send. If you're a PM or founder and your onboarding is still one size fits all, try customer I o at customer dot I o. That is more so than anything.
32:38It's it's a data problem, so we have, you know, data science really plugged in there. But, really, um, the interaction is the most important thing to really sweat and make sure it's delightful. And as a result, a designer is the captain of that work stream.
32:51And then something like what I just showed you, something like temporary initiatives, something like the empty states, really having deep customer understanding, but also business context is really important.
33:04How do I know what people want to do with temporary initiatives? How do I know what the user wants to do? But, also, how do I know what the firm really wants to get out of it and or not?
33:14And so what we spend a lot of time now thinking about is what is the what is the most critical piece to nail for the outcome that we're looking for and therefore the future that we're building? And as a result, how do we appoint a captain that is skilled in that particular area?
33:31And so that that's generally how we think about, um, the model evolving. And so going back to a feature that might touch the front end and the back end, if we believe that the back end is in a good enough spot and by the way, you can ask GitHub sorry, Devin, um, or even, you know, like, anything that's connected to your GitHub account to to look at the code and say, you know, in what state is this?
33:52Right? And and it actually gives you a pretty good answer. Hey.
33:55You know, this this is this is what I would be careful of. Uh, And then you can actually pull an engineering, um, to to on the parts where you're like, this is probably the most contentious, or this is where it gets the most risky. And, again, you don't do this by yourself because you happen to be the most technical person.
34:11We're not. Um, you do this through the help of asking, you know, Claude code to look at your code base, cursor.
34:17What again, whatever tool of choice you choose to use, you can ask it to really give you answers the same way that a marketer would say, look. I'm giving you some copy. Now battle test us and go back and forth.
34:28It's the same concept. And and then going back to if you are clear on, again, what is the hardest thing to to get right in a particular feature? Um, for example, empty state.
34:39The empty state that we're working on here, it's the hardest part to get right is definitely not the engineering. The hardest part to get right is not even the design.
34:45It's the content. And, again, the content has to do with the user and the business and the firm, and that is a very classic PM thing. And so it makes sense for the PM to be the captain of that.
34:56And so that's really the model we think about. Captains, you know, using, um, you know, LLMs to essentially, like, ask how hard something can be.
35:06Obviously, we still, you know, have code review, um, and we make sure that, um, engineers are code reviewing the things that are risky. Um, and so all of those pieces together makes it so that we can all ship, including, you know, customer success, which is, again, really wild and and, like, go to market sales.
35:22And I think we can all immediately
35:24see how that allows engineers to work on the highest leverage back end tasks, PMs to work on higher leverage features if CSM and go to market are enabled.
35:35What is the right set of checks and balances you need to put in place in your organization? How do you you mentioned code reviews.
35:43Where where do those come in? How do CSMs or go to market, for instance, make sure that what they're building isn't in conflict with something the product team is building over here, in contact conflict with somebody else's metrics?
35:56Usually, that's where the PM came in and did a lot of the glue work. How do you handle that in this new way of working? Yeah.
36:02That's a great question.
36:03So we again, I believe in the power of humans.
36:07So something as simple as, you know, creating a channel like Ask Devon reviewers and being able to go through here and making sure that there's visibility around all of the Devon, um, all the ways we're using Devon to ship, and then tagging in the right person, tagging in, you know, um, a front end engineer to really look at something, tagging in designer to look at something else, really going through and, um, making it visible.
36:30I think the first advice I give is transparency is everything. Um, the second piece of advice is you do need to set some ground rules. Right?
36:39So, again, going back to our enablement guide, we've set some ground rules here. Um, as part of, um, even the way Devon works, we off we we actually used to do this quick check where whenever someone, let's say someone on support, had an idea, they essentially could go into this channel and post their idea and get a really quick check on, um, is this something that makes sense?
37:06And, again, I'll just, you know, zoom in here. Like, I'm proposing a change to this experience.
37:12Getting some some feedback, right, and and being able to say, hey. Play around with the first version of it, and and getting, you know, people to chime in and say, hey. This makes sense.
37:21This doesn't make sense. I'm I'm on the engineering success team.
37:26Let me give you some feedback. What you're really doing is you're taking what used to be a product review that used to take time to schedule and time to get all the stakeholders in the same room, and you're just compressing it. Double click on product reviews for me.
37:38You guys have a really interesting process for when you do and don't do product reviews. What is
37:43the right balance so that you enable people to move fast, but you're building the right level of collaboration on bigger features? Yeah.
37:51The same way we have this captain's model, I think about a framework where we call it two tracks. So there's one track which is much smaller. If you have something that even some of the features I just showed you, like, they're they're small enough where, again, a PM, somebody, a product captain, or a product builder, right, can take it end to end.
38:10Those don't go through the same, um, degree of rigorous review, but they do go through things like that ask Devin channel. They go through things, um, you know, like, uh, like, someone looking at the PR and making sure things are good.
38:22You, by the way, you are responsible for end to end testing of your features. I think that's actually really positive. The number of times where in a waterfall model, you would PM throws over the designer, and the designer throws over to the engineer.
38:32And then engineer throws back to the designer to do design QA, and the designer's like, this is not what I design. Um, that is just I think it's just such a it's like it's almost a meme because it happens so often. And so I think that's actually really empowering to say, I am the end to end product builder, and I take something from beginning to end.
38:50And I own and I'm responsible for the quality and impact of this thing. And so first of I just think that's a much more empowered way to work. Um, so but but then going back to the two tracks, you have things that, you know, can really take the product life cycle and compress it down to a day, an hour, you know, like and that's how you get the velocity.
39:09But there are some things where you're like, look. I think that the way that this product is gonna behave, what I'm suggesting is a change, the feature that I wanna do, it requires more much more alignment.
39:20So a great example is, um, within Laurel, if you're gonna change the complete way that activities are displayed, that's a that's a pretty radical change. Um, and how might someone a user go zoom in and out of their day?
39:33That is not a small thing. It re it touches, um, it's the whole, like, user interaction.
39:39And as a result, we say, look. We do wanna do a product review for that. We wanna make sure that, um, we talk about, well, how do we think about the entire product as a system so that we're not adding some random thing over there and a random thing over there?
39:51Um, but a lot of I think the first step is to actually even say what is in what bucket so that the things that could be running really fast are. But, also, I I really don't believe in this.
40:01I think a lot of, quote, unquote, AI native companies are just like, road maps are gone. Planning is gone. Everything is gone.
40:07Um, and what I say is, well, if everyone's running in different directions, even if you're running incredibly fast, you're not really gonna get anywhere. And I see a lot of, um, great, like, local maximizations, but sometimes it's really hard to get to the global max, you know, a whole new set function change in your product, in your market, um, positioning without real rigorous thought around what is our strategy, what is our plan, why are we differentiated.
40:32And those are the things that require much more of what I call a true product review process, where to me, it's more like product strategy review. And then there's architectural review. Right?
40:42Making sure that the system actually will support all the changes that you want and that you can get to a next level of running fast. So
40:50did temporary initiatives go through a product review? It did not. Wow.
40:54Okay. So what would be the, like, the right aperture?
40:57What have been some of your recent product strategy reviews?
41:00Yeah. So, um, today, uh, Laurel is beloved in a lot of firms that, um, think about billable hours.
41:08And we're starting to find that there are a lot of firms, even if they don't have billable hours, um, they really think they still need to think about the concept of time. Um, I would say it even applies to tech. I think about the concept of time all the time.
41:18What are my PMs doing? Going back to this ontology and and this work map of every single function.
41:25I mean, all of us should be thinking about the concept of time. What should salespeople be doing today versus what should not be human anymore? And this is I wanna be very clear.
41:34This is not a, therefore, we do not hire humans. It is a, put the humans on the most important things. The and I'll give you some great examples in here.
41:43Relationship building. You just will never replace a real check-in, a real moment of, you know, true hospitality and delight.
41:52An actual on-site, taking a champion out to dinner, that cannot be replaced by agents. But what will make it so much easier to operate and and no one actually wants to do these things, what if the scheduling for the on-site and making sure that all of the back and forth and logistics is taken care of?
42:08You know, again, in marketing, we do a lot of events. What if all the logistics of event planning work on? Even this idea of unreasonable hospitality, and I I think this is such a a great example.
42:18It is such a core value of us, of ours here at Laurel, um, where we really wanna delight our customers all the time. We wanna delight each other.
42:27We wanna delight our customers. And so we really have codified, um, unreasonable hospitality as as almost like a like a cultural principle that we have, uh, a company value. A lot of companies do this, by the way.
42:37They're like, this is a cultural company value. And then it's in a doc somewhere. People read it, and then they forget about it.
42:43And what we do instead is we say, well, what does that actually mean? We actually want to make sure that no matter who you are, even if you're the most thoughtful person in the world or you're not the most thoughtful person in the world, even if you're four years into your time at Laurel or you're four days into your time at Laurel, you understand that unreasonable hospitality is a requirement of how we operate.
43:03And especially if you're on the customer success team, we expect that you do this with our customers. How do we systematize that?
43:11And and and that's a real real question. You know? Again, there are people on our team who, um, just from who they are as humans, they're the kind of people who's like, someone told me that they're going to Mexico.
43:21And so and it's the first time, by the way, that they're traveling outside the country. And so I bought them an engraved passport holder. That is, by the way, a lot of people on the Laurel team.
43:31But if I were to scale that to hun like, a lot a lot of people and make sure that everyone's doing it at every point in time even when they're really busy with other stuff, it's pretty unlikely that's gonna happen. Instead, we say, well, we actually want to make sure that unreasonable hospitality is a check that we put in.
43:46And so, again, going back to the OS I was showing you, hey. If you have a check-in with someone, um, and, you know, we haven't actually done anything like this in a while.
43:55You haven't had an in person touch point. How might you surprise and delight them? And here are some ideas that we've already pulled for you.
44:02We pulled from your Gong, uh, transcripts that these are things that they love. And we pulled, um, from the fact that they love these things instead of making you do all the work of figuring out, is it a passport holder? How do I even get a passport holder engraved?
44:14We are gonna we're gonna systematize that. And so that's this real idea of, like, deeply understanding your your your company's work, your team's work. What are the things that makes you special?
44:26Where do you put the humans on the things that make you special? And then where do you even in those moments, like unreasonable hospitality, make it so it's easier to do that job and to deliver that particular feeling.
44:38So you this isn't your first rodeo. You've been in product for a really long time.
44:44If we were to wind back to some of those experiences, those former experiences, let's say, like Airbnb in 2015 or Dropbox in 2013 or WeWork in 2019, You've been in these large organizations that most people listening to this podcast have been in where the PM traditionally never had access to GitHub, let alone, like, the amount we're showing here where they have a Devon agent that is shipping front end and back end features.
45:12And you'd be surprised. Even at companies like Adobe, PMs are still living in that world that you and I were in back then. They still don't have access.
45:20They're looking at what we've just showed them, and they're saying, gosh. This is too far away from my reality.
45:26Is it true that, like, this just won't work in certain type of companies,
45:30or will they eventually get there? It is just a matter of time. I'll start with the end, which is I do think it is a matter of time that every company is gonna have to get there.
45:40You can't keep doing the same thing if everyone else, including all your competitors, are moving at 10 times the speed. So I do think that there will be pressure to ultimately get there for everyone.
45:51Now what you want to be for the company and for the individual is you want to be, um, as far, uh, you know, as as advanced as possible, right, in that curve as opposed to just waiting for it to happen to you. And this is where I go back to you know, the first step is just start small.
46:08Start with one workflow that you are doing, and or I really I really push on this. I think this is really a great way to to get your feet wet and and start to think about this.
46:19Go find another team in your company somewhere. And even if you're like, I am not quite ready to ship to production for whatever reason, and usually the reasons are not that you can't, like, you're not physically able to.
46:31It's usually something about the the system or the process that it's not quite there yet. But but let's just say that you you don't feel like you can in the next month.
46:39Go somewhere else where the there's always somewhere in the org that is hungry for product thinking and hungry for a tool to make their life better. And I would start with, let's just go build a tool for somebody in a different org to make their life better and simultaneously pick up one part of your workflow that is taking you a lot of time, and there's really no reason that you should be doing that.
47:03Again, great examples. I'm getting into a customer call. I would love to be prepped.
47:08I would love to be prepped for that in a way that, you know, an agent is serving me that information as opposed to me having to pull from multiple different sources. Right? That's a very simple example.
47:17I write the same, um, same email over and over again. It should be auto populated.
47:22Again, these are just small, small, little automations, or you can call them templates, whatever it is that you that, um, makes sense to you. Start there.
47:31And then I would say, if you're ready to take on something bigger, this idea of, like, what does a function do, or what does an end to end, um, operational journey look like?
47:43And there, I would start to say, map out your ontology or take your playbook and really, you know, write that down. And, again, what I what I find really fun is, like, these playbooks I think if someone was tasked to write a playbook back in the day, they'd be like, okay.
47:58I'll do it. It'll take me a couple weeks. These playbooks can be written in an hour.
48:03Actually, the first draft can be written in sub a minute. But to make it actually right and and, you know, really reflective of your business, yeah, it'll take a little bit more time. But we're talking hours here, maybe days max.
48:14We're not talking weeks. And so I think when you get a feel for how much you can enable yourself and you can enable others, you're gonna create a culture. Again, even just going back to culture change, you're gonna create a culture where it's celebrated, and it's fun.
48:31And and, again, if you're a leadership, what I'd really encourage you to do is make that the culture. Celebrate those wins. Take the people who are your 1% and take their workflows and figure out how to scale that workflow to every single person on the team.
48:45When you create that expectation and you celebrate those wins, you'll get more and more of that behavior.
48:51For you guys, did it happen as a transformation? Were you guys always this way? Did it start with the CEO and the founder?
48:58How did it come about so that now you guys do feel the confidence that you have this enablement playbook of Devon where anyone can ship to production? Yeah.
49:06Um, I think there were a lot of pieces, but I'll highlight the pieces that I think are most relevant that someone listening to this could take and and replicate. The first piece I've already shared, which is the idea of just doing a hackathon. And in the hackathon, uh, making everyone participate because it changes this idea of you have to be technical to build something.
49:25And and, again, I think most people have done that. Um, so I would expect that, you know, 90% of the people listening have participated in some kind of hackathon. If you have not, that's the first step.
49:36Um, the second step is to really think about all of the different ways you can, again, automate the workflow. I think that a structural thing that I would really recommend is actually making this idea of playing with AI tooling, creating workflows, automating large swaths of somebody's day in a way that makes them much more productive, make that the actual charter and mandate of a full of a person full time.
50:06And what I really find is a lot of times when you say it's everyone's responsibility, it's no one's responsibility. And so what we have at Laurel is we actually have an AI operations team. And to me, AI ops is the new biz ops.
50:18Before biz ops, they were doing really meaningful things, but often it was it was very high level, all the different hats, a lot of, like, market level stuff. Now if you repurpose this idea of having biz ops, which is really, again, a Swiss army knife in many ways, to finding people who are insanely curious, tinkering with the latest technology, and relentless about finding efficiencies, that's the DNA I really look for.
50:45And so we've actually built out an AI operations team. We started with Sasha, who has built out a lot of the things that I've I've shown today.
50:54And what he did is basically was like, I'm gonna demonstrate value in having AI operations. And very soon, when you when you have one person who's doing an excellent job, every single other function is like, I want my Sasha. I want my own AI Sasha.
51:08And that is how you then get the buy in to say, okay, well, maybe we have an AI person, AI operations person just doing go to market, and a separate AI operations person just doing product, and a separate AI operations person just doing finance. Because all of these functions, by the way, finance, rev ops, product ops, research ops, you name it, all of them are changing so dramatically.
51:30And so being able to retool your the way that your company works with someone who's really dedicated to pushing that forward really, really accelerates the the journey. That's
51:41really interesting. And you guys were founded before the AI revolution. So I guess, like, for other companies that were founded before then, I think you were twenty eighteen, like, where
51:53who is, like, the right driver? It feels to me like it probably has to start, like, literally with the CEO. Right?
51:58Yeah. I was gonna say I wanna give a ton of credit to Ryan. So, yes, um, Laurel, um, was founded actually, I would say Time by Ping.
52:05This is what Laurel was called, uh, previously, was founded in 2018. Um, but Ryan actually had the the foresight and and the the courage, really, to say, you know what? When I think about what time looks like in a world of AI and LLMs, it's very different.
52:21And when I think about, um, at the time, our core product, um, timekeeping. Right?
52:26Like, what does timekeeping look like in a world that, where you have to kind of enter it manually or just do it through call it what I call integrations versus a world where you can actually start to really see everything that's happening on your computer and synthesize that and run that through an LLM.
52:42Like, he basically had the foresight and, again, courage to say, I'm going to rearchitect my entire product, my entire company to be AI native.
52:52And so it's it's really interesting. Like, I really believe that, and I experience this day to day. I wouldn't you know, like, I I I was like, I I I wanna be building at the cutting edge.
53:03Laurel is AI native, although it was founded, like, more than three years ago.
53:09And so that it does start with the CEO. But even if if people don't have that degree of change and conviction, I think you can still do it at every single level where, you know, if you are not the CEO, but you're, uh, an executive, you can say, well, this is how I expect my function to really operate.
53:29Here in my function, I am a marketing leader. I fully expect that this is what we are doing, and let me go color code everything in here that should be AI enabled.
53:39Right? Like, when you think about copywriting today, you should not be writing copy by hand. You should be editing when you're doing videos.
53:45Like, if you're not using, um, a lot of the AI tooling out there, you're spending a lot of money on studio, on video in a way that you don't need to anymore. So being able to go line by line in terms of your, again, your your work map, what is it that all my humans do, and how do I really think about where do I need to keep that person versus where can I actually really AI charge supercharge them?
54:08Amazing. So I think that's the key point for a lot of people that I talk to at least is that
54:14they they don't have any access to the stuff we're showing, and probably it needs to start, like, all the way at the CEO level, and then it can work its way down where, like, you need really amazing CPO like yourself who is also AI pilled in order to make this happen. And that's kind of the next layer I wanna talk about is, as an AI pilled CPO, what is your take on the types of product teams we're going to see in the future?
54:39What types of product managers are you hiring, and what is the shape of their role today? I think for many people, um, I'm sure this is dialogue that's happening everywhere. This idea of, are you a product manager or are you just a product builder?
54:53And how many people are product builders? Meaning, is it just the product person themselves by functional title, or is it also the designer?
55:02Is it also the engineer? I'm a big believer of the fact that I think everyone should be a product builder. It goes back to my how we operate the team today with captains and taking features end to end.
55:14What I do look for specifically in in product builders who are product managers by training, I look for a couple of things.
55:24I found that if you're incredibly senior in the sense that you have the judgment, you've gone through the hellfire, you've shipped things that haven't worked. And I think for all of us that have shipped things, most of the time, it doesn't work in the first go around.
55:37Um, if you have if you kind of have that battle tested judgment, I'm finding that the combination of that experience plus this intense curiosity, this desire to be hands on, I think you see a little bit of a bifurcation.
55:50There are lot of people who are very experienced and almost scared that their job is changing, and they're feeling more fear than, I would say, excitement.
56:00And I would say that there's another group of people who are very experienced, and they have been they've never been more excited. Like, I I've never been more excited, by the way, to not be doing all these things I used to do in the past.
56:10It took me forever that there was no part of me that wanna be doing that. Instead, I love, you know, actually, like, shaping a product, really getting hands on.
56:20Um, and then so so being able to find those people who are excited, who are curious, but yet have the the judgment and the reps is really, really important. And so, again, um, this is not necessarily by design, but what I found really interesting was, you know, there are a number of people in my team who previously were, you know, CPOs, VP of products, head of products, and they've come in.
56:41And they they're the ones building end to end. They're the ones shipping end to end. Um, and, again, they've never been more excited.
56:47They've never been more excited to not have a team to have to manage because they realize that a lot of that is just overhead. A lot of that just cord coordinate coordination cost. They've realized that a lot of it is just coordination cost, and instead, they can just be, um, enabled to get right in there and drive the change that they wanna see.
57:07That's crazy. So you have embraced the super senior
57:11ICPM. I think you said something pretty crazy actually when we were talking before, which was the more senior you get, the longer you've been in product, the smaller your orgs have become.
57:21Is that the trend of the future, smaller and smaller product orgs? I think so. Yeah.
57:26I mean, I've had hundreds of people, and today, I have five PMs and four designers. And, um, there isn't a real reason to grow that because, again, like, when you add more people, you add more coordination costs.
57:40You actually have a harder time making making people feel like they are absolutely responsible for taking something end to end. And so I do think of that as the future.
57:51I think that the best teams are gonna be lean,
57:55but not so lean that they're starved. And so it's really important to find that line. So you said you do something pretty crazy in your interviews.
58:03Can you tell me how you interview people and really find these gem AI pilled super senior ICPMs?
58:10I think a lot of people are talking about, of course, you know, you do a session where people have to build with AI. I I think that's all fine, and I think it makes a lot of sense to do that.
58:21It it takes cycles, by the way, to even have a standardized interview loop. On some companies, it makes sense because they're large enough where they're hiring, you know, enough PMs. But, again, I I do think many people are saying, hey.
58:31Let's actually get a little bit more particular about who we hire and make sure that they're really seasoned, and we'd rather pay a few really seasoned people, you know, a lot more than having just an army of people.
58:43And so what I've been doing, and I I do this, by the way, for every function, not just product or designer or so, you know, so on and so forth, is I I do ask people to screen share. And what I found is it is so easy to say, hey.
58:56We are you know, I'm AI pilled. We're AI pilled.
58:59We do a bunch of stuff with AI. But as soon as you get into like, if you really peek under the hoods, you're like, actually, I think you're what I call, like, level one.
59:07And maybe I'll just take a moment and talk about the levels for me. Level one is you're talking to, you know, you're talking to ChatGPT. You're talking to Claude.
59:15You're really using, um, AI kind of in a chat mode, almost like like search mode. Right? Like, I ask a question, you give me an answer.
59:23Level two is where you start to automate a workflow. Right? And this is what I was showing earlier around just the first step is, like, start small.
59:30An OS does not start necessarily as an OS, but it starts with a first, um, automation. Right?
59:37A first little piece of workflow that everyone's gonna start doing. And so that's level two. Um, level three is when you start building, you know, apps.
59:45Right? You say, hey. You know, it's really important that I I'm doing this thing.
59:49It's really tedious. I'm gonna build an app to make it less tedious. And then level four, I'd say, is where you're actually building, I call it, shared apps.
59:56And or if you really think about the product life cycle, you're really shipping to your customers. And so those are the the maybe the four levels, um, that you can assess yourself on.
1:00:06You can assess a given company on, like, of those four levels is the majority of the organization, um, operating at.
1:00:13And so, um, what I find is when you actually ask someone to screen share and show them how and show you how they AI, you're very you can very quickly get a sense of, are you at level one? Are you basically just talking to ChatGPT?
1:00:27Um, or have you actually created, like, some way to really, like, scale yourself, some kind of workflow, some kind of agent?
1:00:35Or are you starting to build, like, apps? And or, you know, what are you shipping? Like, truly, truly shipping.
1:00:40And so really getting to see that live on screen is really, really interesting because, otherwise, it's really easy to just be like, this is what I do, and it's pulled from LinkedIn or pulled from the latest thing you saw on the Internet. But actually peeling it back and be like, what is on your screen is is really fascinating.
1:00:58Wow. People don't believe me when I keep saying this is the new interview. This is what I'm hearing.
1:01:03You've heard it from a CPO herself. So a lot of people are feeling pretty bad about this whole transition.
1:01:11Transition. Like, there there's a lot of fud going around in the PM field. If you check out Reddit or something, people are feeling a lot very nervous about this change.
1:01:20They're saying, hey. We're compressing out the juniors. You had a really interesting take on this, which is that
1:01:26the best PMs are actually getting more roles, and the rest are feeling fear and destruction. Can you unpack that for us? I think it's because one PM can do so much more than ever before, but there aren't that many of them who are that skilled, that have that judgment, who are AI pilled, um, who fearless fearlessly are going through all of these pieces.
1:01:45And, by the way, know that one of the most important things forever and will never change about the PM role is that they have to stay close to their customers. Right? So, like, the the Venn diagram of all of those traits is not large in terms of the actual number of people that fall into that, and that's what every company is gonna want.
1:02:03And and around the edges, it's like, why do I why would I go hire someone who is not all of those things? I'm gonna have to supplement them in some way, and it's gonna create overhead. And then when when in in many ways, can take that piece that is not excellent, and I can build, like, you know, again, a workflow and agent around that.
1:02:19So I I think it's really finding who I call the orchestrators. Right? The people who are big picture in terms of their thinking, but, you know, down to the detail in terms of terms of their execution.
1:02:31Those are the people who are worth their weight in gold. And I think that a lot of people who need to be complemented by a designer and complimented by an engineer, like, you know, complimented by many, many, many other people, it just doesn't make sense anymore. Because why go hire all those people when, again, one person can be the end to end builder?
1:02:48It's not me saying it, guys. It's her. I've been preaching this for months and months.
1:02:54This is the future of product management. We just gave you the entire playbook.
1:02:59She just screen shared literally everything. The company OS, how their PMs are knocking down linear tickets.
1:03:07If you want a really amazing job, apply to Laurel. JV is not just doing this though. Right?
1:03:13You actually have so much cool stuff going on. You teach product management at Stanford. Think you had, at some point, had been involved with Reforge.
1:03:22Can you get yourself outside of Laurel? What's the world of Jay z? What's going on?
1:03:28Um, I do teach every year at Stanford. Um, I do it for the love of really just getting to meet the next generation of of builders.
1:03:37Um, I also get the really awesome benefit of meeting people like the Sasha's of the world who, you know, once took my class, then TA'd for me, and now is at Laurel. And, uh, you know, teaching for me has been a combination of of passion and, honestly, a pipeline.
1:03:53Um, so I teach at Stanford. I teach at Yale, and I teach at Reforge. Um, and it's it's just how I think that when you teach something, you have to know it like the back of your hand in order to actually share that with someone else.
1:04:07Um, so, again, I just find this really funny. A lot of times I'll teach, and then I'll be like, ah, good reminder, Jay z. Like, uh, were you doing that today in your day to day?
1:04:16Uh, were you customer centric enough? Were you problem space first and not solution first enough? And so I just find it both, um, so gratifying personally, but also, um, such a great reminder of of what product really is.
1:04:28And I'll I'll say one last thing, which is what's funny is that, um, so I I teach AI leadership through Reforged, and that curriculum changes literally by the month.
1:04:39Um, you know, we teach it every six months, and the amount of change between the six months is massive. But when you actually teach fundamentals, when you teach, you know, what I call, like, PM one on one, those core principles have not changed.
1:04:51You should still always never jump to the solution. And now that you can build faster than ever before, it doesn't mean you just build everything. Like, what actually is important is to know why and for whom you're building for and what is it that you're trying to solve for and what success looks like.
1:05:06And, therefore, you actually know you've hit your target. And so what's really ironic is that through teaching all these different levels of of product people over the years, I find that the the fundamentals and the principles have never changed.
1:05:20In fact, they're even more important than ever before. But the tools and the way you operate and the way you can blast through the bureaucracy and feel empowered, that's radically changed.
1:05:30And so as a as a leader, the way you empower your team is very different. Do you have the right culture?
1:05:38Do you have the right team? Do you have the right space for people to even build?
1:05:43Do you have the right operating system? Do you have the right knowledge of what people are doing day to day? Do you have all of those pieces?
1:05:50That is changing dramatically, but in your actual, you know, one on one on one basics around what it is that a product person is supposed to be doing,
1:06:01the speed has changed dramatically, but what you're supposed to be doing at the heart of it, that has not changed. What a way to end it. Alright, guys.
1:06:08We have hit a crazy milestone. We crossed 40,000 YouTube subscribers. We have also crossed 565,000 average views per listen per episode.
1:06:17When I started this podcast two years ago, I wouldn't have believed it. I want all 565,000 of you to flood Laurel's PM applications for my money.
1:06:26This is like the coolest PM job you could possibly have. And I would say, if you are in a PM job where everything we were just talking about feels really foreign and, like, 10 steps away from what you are, find a job like this with an AIPLed CPO like Jay z.
1:06:44You are gonna learn so much more than if you get to this four years from now and then you learn it. Apply to Laurel, get her the best AIPMs in the world.
1:06:53Check out her class at Stanford if you are in the Bay Area so you can really learn AIPM. And if you are a leader, check out her course. Erin Reforge.
1:07:01This is just me saying this. You can see how much value I got out of this episode. You can see I'll be writing about a company OS soon in my newsletter.
1:07:09Jay Z has absolutely killed it. Thank you so much, Jay Z. Thanks for having me.
1:07:13I hope you enjoyed that episode. If you could take a moment to double check that you have followed on Apple and Spotify podcasts, subscribed on YouTube, left a rating or review on Apple or Spotify, and commented on YouTube, all these things will help the algorithm distribute the show to more and more people.
1:07:29As we distribute the show to more people, we can grow the show, improve the quality of the content and the production to get you better insights to stay ahead in your career. Finally, do check out my bundle at bundle.akashg.com to get access to nine AI products for an entire year for free.
1:07:46This includes Dovetail, Mobin, Linear, Reforge Build, Descript, and many other amazing tools that will help you as an AI product manager or builder succeed. I'll see you in the next episode.
The Hook

The bait, then the rug-pull.

Every organization has the same split: a handful of employees who've quietly rebuilt their entire workflow around AI, and everyone else still guessing what tool to reach for. Laurel's CPO Jiaona Zhang stopped treating that as an inevitability and built a system to close the gap — and in this episode she screen-shares the actual thing.

CTA Breakdown

How they asked for the click.

MENTIONED ON CAMERA
10:05toolAriso ↗
10:56toolBolt ↗
11:45toolPendo Agent Analytics ↗
30:34productProduct Faculty AI PM Certificate ↗
31:23toolCustomer.io ↗
00:00productLaurel ↗
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
AFFILIATECommission earned if you click.
OTHER LINKSAlso linked in the description.
Frame Gallery

Visual moments.

Frame at 00:01 from How to Build a Company OS in Claude Code00:01Frame at 00:35 from How to Build a Company OS in Claude Code00:35Frame at 01:11 from How to Build a Company OS in Claude Code01:11Frame at 01:46 from How to Build a Company OS in Claude Code01:46Frame at 01:55 from How to Build a Company OS in Claude Code01:55Frame at 02:01 from How to Build a Company OS in Claude Code02:01
Frame at 00:01 from How to Build a Company OS in Claude Code00:01Frame at 00:35 from How to Build a Company OS in Claude Code00:35Frame at 01:11 from How to Build a Company OS in Claude Code01:11Frame at 01:46 from How to Build a Company OS in Claude Code01:46Frame at 01:55 from How to Build a Company OS in Claude Code01:55Frame at 02:01 from How to Build a Company OS in Claude Code02:01Frame at 02:04 from How to Build a Company OS in Claude Code02:04Frame at 03:25 from How to Build a Company OS in Claude Code03:25Frame at 04:19 from How to Build a Company OS in Claude Code04:19Frame at 05:13 from How to Build a Company OS in Claude Code05:13Frame at 06:05 from How to Build a Company OS in Claude Code06:05Frame at 06:55 from How to Build a Company OS in Claude Code06:55Frame at 07:45 from How to Build a Company OS in Claude Code07:45Frame at 08:25 from How to Build a Company OS in Claude Code08:25Frame at 09:00 from How to Build a Company OS in Claude Code09:00Frame at 09:32 from How to Build a Company OS in Claude Code09:32Frame at 09:54 from How to Build a Company OS in Claude Code09:54Frame at 10:05 from How to Build a Company OS in Claude Code10:05Frame at 10:56 from How to Build a Company OS in Claude Code10:56Frame at 11:45 from How to Build a Company OS in Claude Code11:45Frame at 12:30 from How to Build a Company OS in Claude Code12:30Frame at 13:30 from How to Build a Company OS in Claude Code13:30Frame at 14:10 from How to Build a Company OS in Claude Code14:10Frame at 15:06 from How to Build a Company OS in Claude Code15:06Frame at 16:18 from How to Build a Company OS in Claude Code16:18Frame at 16:59 from How to Build a Company OS in Claude Code16:59Frame at 18:05 from How to Build a Company OS in Claude Code18:05Frame at 19:41 from How to Build a Company OS in Claude Code19:41Frame at 21:26 from How to Build a Company OS in Claude Code21:26Frame at 22:04 from How to Build a Company OS in Claude Code22:04Frame at 23:27 from How to Build a Company OS in Claude Code23:27Frame at 23:56 from How to Build a Company OS in Claude Code23:56Frame at 24:48 from How to Build a Company OS in Claude Code24:48Frame at 25:35 from How to Build a Company OS in Claude Code25:35Frame at 26:49 from How to Build a Company OS in Claude Code26:49Frame at 27:42 from How to Build a Company OS in Claude Code27:42Frame at 28:29 from How to Build a Company OS in Claude Code28:29Frame at 29:09 from How to Build a Company OS in Claude Code29:09Frame at 29:23 from How to Build a Company OS in Claude Code29:23Frame at 29:37 from How to Build a Company OS in Claude Code29:37Frame at 29:44 from How to Build a Company OS in Claude Code29:44Frame at 30:09 from How to Build a Company OS in Claude Code30:09Frame at 30:25 from How to Build a Company OS in Claude Code30:25Frame at 30:34 from How to Build a Company OS in Claude Code30:34Frame at 31:23 from How to Build a Company OS in Claude Code31:23Frame at 32:05 from How to Build a Company OS in Claude Code32:05Frame at 33:02 from How to Build a Company OS in Claude Code33:02Frame at 33:52 from How to Build a Company OS in Claude Code33:52Frame at 34:42 from How to Build a Company OS in Claude Code34:42Frame at 35:22 from How to Build a Company OS in Claude Code35:22Frame at 36:01 from How to Build a Company OS in Claude Code36:01Frame at 37:36 from How to Build a Company OS in Claude Code37:36Frame at 37:50 from How to Build a Company OS in Claude Code37:50Frame at 40:49 from How to Build a Company OS in Claude Code40:49Frame at 41:15 from How to Build a Company OS in Claude Code41:15Frame at 44:37 from How to Build a Company OS in Claude Code44:37Frame at 45:04 from How to Build a Company OS in Claude Code45:04Frame at 47:56 from How to Build a Company OS in Claude Code47:56Frame at 48:51 from How to Build a Company OS in Claude Code48:51Frame at 50:20 from How to Build a Company OS in Claude Code50:20Frame at 51:40 from How to Build a Company OS in Claude Code51:40Frame at 52:56 from How to Build a Company OS in Claude Code52:56Frame at 54:08 from How to Build a Company OS in Claude Code54:08Frame at 54:45 from How to Build a Company OS in Claude Code54:45Frame at 56:18 from How to Build a Company OS in Claude Code56:18Frame at 57:07 from How to Build a Company OS in Claude Code57:07Frame at 57:59 from How to Build a Company OS in Claude Code57:59Frame at 58:30 from How to Build a Company OS in Claude Code58:30Frame at 58:46 from How to Build a Company OS in Claude Code58:46Frame at 59:11 from How to Build a Company OS in Claude Code59:11Frame at 60:21 from How to Build a Company OS in Claude Code60:21Frame at 60:48 from How to Build a Company OS in Claude Code60:48Frame at 62:07 from How to Build a Company OS in Claude Code62:07Frame at 62:48 from How to Build a Company OS in Claude Code62:48Frame at 64:00 from How to Build a Company OS in Claude Code64:00Frame at 64:26 from How to Build a Company OS in Claude Code64:26Frame at 66:06 from How to Build a Company OS in Claude Code66:06Frame at 66:26 from How to Build a Company OS in Claude Code66:26Frame at 67:12 from How to Build a Company OS in Claude Code67:12Frame at 67:23 from How to Build a Company OS in Claude Code67:23
Watch next

More from this channel + related breakdowns.

19:10
Pat Simmons · Tutorial

Clone a $1.2B App in 19 Minutes

An 8-step agentic pipeline that takes you from naive AI slop to a pixel-near Linear replica, deployed to Vercel with an MCP server, in under 20 minutes.

June 8th
Chat about this