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 months ago
Duration
Format
Interview
educational
Views
28.6K
693 likes
57 · 43
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.
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.
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.
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.
“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.”
“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)
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.
17px
metaphoranalogystory
You 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.
She is the chief product officer at Loro, the $100,000,000
AI time platform. Platform. She teaches PMS Stanford.
Before 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.
Can you tell me how you interview people and really find these gem AI pills super senior ICPMs?
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.
How should people be thinking about in an AI native organization? This is the role of a PM. And so those are the four levels.
Level one is you're talking to ChatGPT. You're talking to Claude. You're really using AI kind of in chat mode.
Level 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.
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.
Before 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.
So be sure to check that out at bundle.akashg.com, and now into today's episode.
Jay 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.
Can you show me what this is and what it does? Of course. Alright.
Let me screen share here. Okay. Let's start here.
Let'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.
So in customer success, you do account management. And within account management, you're thinking about, you know, renewals, upsells.
Um, you do a customer enablement. And within that, we essentially work with our customers. We do office hours.
We help them with rollout. We do training and onboarding. Each of these folders have a skill.
And 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.
And 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.
Right? 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.
Cool. You have some folders in GitHub. You have, you know, some some stuff that you can download.
How 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.
And 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.
So 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.
And 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.
This 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.
This 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.
And 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.
And 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.
My, 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.
They'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.
And 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.
Maybe 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.
And 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.
Again, 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.
How 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.
In 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.
But 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.
All 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.
So 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.
These 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.
So 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.
Wow. 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.
This company OS, this is bringing that power to everybody. Now you guys are an AI native company.
You guys are an AI company yourselves, and so you guys would have certain advantages
in 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?
I 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?
What 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.
I don't wanna input, um, my data into a CRM anymore. I want that to be automated.
So 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.
So 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.
So 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.
It 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.
I used to pay for granola and Lindy separately. Ariso replaced both. One tool does more, and it lives right in Slack priority work.
Check it out at ariso.ai/akash. That's ariso.ai/aakash. Here's the dirty secret about prototyping.
You spend two weeks building a prototype. You validate your assumptions. Engineering loves the direction.
Then what happens? You throw the whole thing away. Bolt changes this completely.
When 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.
They ship on top of what you've built. I use Bolt every single day. I host my LAN PM job cohort on it.
And 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.
Check out Bold at bold.new/akash. That's bolt.new/aakash. Link in the show notes.
Today'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?
Are 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.
Showing 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.
That's pendo.io/aakash.
Okay. 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.
I 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.
When 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?
Um, what is actually going on here? Give me some more details. All of those things usually require back and forth.
So, 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.
And then what often happens is you then have to triage it. You say, hey. You know, is it for this team or that team?
Is 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.
So, 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.
Great. I come in here. Um, I'm going to automatically, um, ask for all of this information.
So, you know, what is it? Who is it coming from? What's going on here?
It 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.
Right? It's just like a very small step in in creating your operating system. So I start there.
The next step is this idea of how do you start to really automate based on a bunch of things that your team is doing.
And 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.
They're getting kind of forward deployed into these organizations, helping them use Laurel as a as a product.
And 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.
It covers everything from implementation to onboarding to user onboarding. And and depending on who you are. Is it the admin?
Is it the actual, um, timekeeper, etcetera? You know, different onboarding.
These 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?
And 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.
Well, 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.
It 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.
And 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.
When 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.
The 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.
And 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.
They've launched, obviously, a lot of, um, agents. You can use, uh, a lot of things from OpenAI as well.
You can use a Glean. You can use a Dust. We, at Laurel, use Dust.
And 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?
This 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.
And 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.
I 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.
Um, 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.
And 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.
The 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.
And 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.
So help me understand this part. Why use Dust instead of just all Claude or Claude code? Yeah.
That'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.
I 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.
And 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.
And 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.
And as a result, it gives me my briefing right there as opposed to me having to go and call an agent builder. And
then 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?
Yeah. That's a great question. It's so funny.
Um, 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.
You 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.
I 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.
I 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.
And 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.
And, 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.
And 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.
And 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.
Right? The thing that you are encoding
that'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.
What is the right company culture? How do you really get people to take advantage of a company OS like this? Yeah.
Absolutely. I think it really starts with culture.
I 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.
It 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.
How do we do a company wide hackathon every quarter, every six weeks?
Right? 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.
One, 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.
And 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.
And 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.
And 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.
So 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.
It 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.
And 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.
And 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.
Many 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.
Similar 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.
So really think about new user onboarding. What is it that they see? How do how do we make that experience super delightful?
All 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.
And 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.
Ashley 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.
And 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.
I'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?
We 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.
You 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.
Um, 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.
And 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.
You 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.
And 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.
I 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.
And 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.
And that's ultimately the the key pieces of the system. Wow. There is so much gold buried
in the various parts of your answer there. The first part I wanna double click on first is PM's shipping to production. Okay.
People have heard about that. But PM's not just shipping.
Okay. 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.
That'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?
This is the role of a PM today. We talk a lot about this in terms of, uh, what is engineering anyways?
What 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.
And 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.
Usually, 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.
I hope you're enjoying today's episode. Are you interested in becoming
an 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.
If 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.
So 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.
Be 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.
Turns 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.
Customer.io changed that. Every message I send is now based on what users actually do in the product.
Someone 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.
I describe the campaign I want, and it builds the full journey form. Triggers, timing, copy, even branching logic.
And 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.
Your 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.
Notion 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.
The idea is simple. Customer.io
helps 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.
It'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.
And 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.
How 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?
And 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?
And 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?
Right? And and it actually gives you a pretty good answer. Hey.
You 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.
We're not. Um, you do this through the help of asking, you know, Claude code to look at your code base, cursor.
What 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.
It'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.
The 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.
It'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.
And 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.
Obviously, 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.
And I think we can all immediately
see 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.
What is the right set of checks and balances you need to put in place in your organization? How do you you mentioned code reviews.
Where 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?
Usually, 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.
That's a great question.
So we again, I believe in the power of humans.
So 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.
I 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?
So, 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?
And, again, I'll just, you know, zoom in here. Like, I'm proposing a change to this experience.
Getting 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.
This doesn't make sense. I'm I'm on the engineering success team.
Let 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.
You guys have a really interesting process for when you do and don't do product reviews. What is
the right balance so that you enable people to move fast, but you're building the right level of collaboration on bigger features? Yeah.
The 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.
Those 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.
You, 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.
And 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.
And 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.
But 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.
So 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?
That is not a small thing. It re it touches, um, it's the whole, like, user interaction.
And 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?
Um, 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.
I think a lot of, quote, unquote, AI native companies are just like, road maps are gone. Planning is gone. Everything is gone.
Um, 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.
And 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?
Making 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
did temporary initiatives go through a product review? It did not. Wow.
Okay. So what would be the, like, the right aperture?
What have been some of your recent product strategy reviews?
Yeah. So, um, today, uh, Laurel is beloved in a lot of firms that, um, think about billable hours.
And 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.
What are my PMs doing? Going back to this ontology and and this work map of every single function.
I 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.
This 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.
Relationship building. You just will never replace a real check-in, a real moment of, you know, true hospitality and delight.
An 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?
You 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.
It 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.
We 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.
They'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.
And 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.
And especially if you're on the customer success team, we expect that you do this with our customers. How do we systematize that?
And 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.
And 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.
But 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.
And 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.
You 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.
We 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?
We 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?
Where 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.
So you this isn't your first rodeo. You've been in product for a really long time.
If 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.
And 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.
They're looking at what we've just showed them, and they're saying, gosh. This is too far away from my reality.
Is it true that, like, this just won't work in certain type of companies,
or 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.
You 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.
Now 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.
Start 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.
Go 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.
It'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.
Go 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.
Again, great examples. I'm getting into a customer call. I would love to be prepped.
I 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.
I write the same, um, same email over and over again. It should be auto populated.
Again, 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.
And 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?
And 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.
I'll do it. It'll take me a couple weeks. These playbooks can be written in an hour.
Actually, 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.
We'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.
And 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.
When you create that expectation and you celebrate those wins, you'll get more and more of that behavior.
For you guys, did it happen as a transformation? Were you guys always this way? Did it start with the CEO and the founder?
How 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.
Um, 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.
And 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.
Um, 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.
And 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.
Before 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.
And 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.
And 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.
And 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.
And 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
really 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
who is, like, the right driver? It feels to me like it probably has to start, like, literally with the CEO. Right?
Yeah. 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.
This 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.
And when I think about, um, at the time, our core product, um, timekeeping. Right?
Like, 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.
Like, 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.
And 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.
Laurel is AI native, although it was founded, like, more than three years ago.
And 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.
Here 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.
Right? Like, when you think about copywriting today, you should not be writing copy by hand. You should be editing when you're doing videos.
Like, 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?
Amazing. So I think that's the key point for a lot of people that I talk to at least is that
they 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?
What 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?
And how many people are product builders? Meaning, is it just the product person themselves by functional title, or is it also the designer?
Is 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.
What I do look for specifically in in product builders who are product managers by training, I look for a couple of things.
I 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.
Um, 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.
There 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.
And 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.
It 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.
Um, 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.
And 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.
They'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.
That's crazy. So you have embraced the super senior
ICPM. 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.
Is that the trend of the future, smaller and smaller product orgs? I think so. Yeah.
I 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.
You 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.
I think that the best teams are gonna be lean,
but 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.
Can you tell me how you interview people and really find these gem AI pilled super senior ICPMs?
I 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.
It 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.
Let'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.
And 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.
We are you know, I'm AI pilled. We're AI pilled.
We 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.
And 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.
You'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.
Level 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.
An OS does not start necessarily as an OS, but it starts with a first, um, automation. Right?
A 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.
Right? You say, hey. You know, it's really important that I I'm doing this thing.
It'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.
And 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.
You can assess a given company on, like, of those four levels is the majority of the organization, um, operating at.
And 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?
Um, or have you actually created, like, some way to really, like, scale yourself, some kind of workflow, some kind of agent?
Or are you starting to build, like, apps? And or, you know, what are you shipping? Like, truly, truly shipping.
And 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.
Wow. People don't believe me when I keep saying this is the new interview. This is what I'm hearing.
You've heard it from a CPO herself. So a lot of people are feeling pretty bad about this whole transition.
Transition. 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.
They're saying, hey. We're compressing out the juniors. You had a really interesting take on this, which is that
the 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.
And, 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.
And 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.
So 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.
Those 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?
It's not me saying it, guys. It's her. I've been preaching this for months and months.
This is the future of product management. We just gave you the entire playbook.
She just screen shared literally everything. The company OS, how their PMs are knocking down linear tickets.
If you want a really amazing job, apply to Laurel. JV is not just doing this though. Right?
You 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.
Can you get yourself outside of Laurel? What's the world of Jay z? What's going on?
Um, 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.
Um, 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.
Um, 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.
Um, 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?
Uh, 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.
And 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.
Um, 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.
You 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.
And, 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.
In 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.
And so as a as a leader, the way you empower your team is very different. Do you have the right culture?
Do you have the right team? Do you have the right space for people to even build?
Do 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?
That 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,
the 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.
We have hit a crazy milestone. We crossed 40,000 YouTube subscribers. We have also crossed 565,000 average views per listen per episode.
When 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.
This 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.
You 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.
Check 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.
This 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.
Jay Z has absolutely killed it. Thank you so much, Jay Z. Thanks for having me.
I 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.
As 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.
This 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.
Anthropic shipped a Figma-style artboard editor into Claude Code itself, and one identical prompt with real context beat Claude Design's default template every time.
A five-tool stack — transcription, cuts, AI b-roll, code-built motion graphics, and a self-review loop — that lets an agent finish a rough cut to a client-ready render without a human in the loop.
The 'set it and check back' pattern replacing one-shot prompting, broken into four parts, a decision tree for when it's worth building, and a live Claude Code demo.
A breakdown of Claude Code's native /loop and /goal commands, shown live on a race-simulator agent and a newsletter-writing agent that grades its own drafts until they pass.
A creator walks through five concrete levers — effort level, model delegation, token-saving skills, research offloading, and advisor mode — for keeping Claude Code costs and weekly usage caps under control.
A 10-minute walkthrough of Anthropic's internal classification of agent loops — four types, two slash commands, and the stop-condition rule that prevents a $6,000 night.
00:01
00:35
01:11
01:55
02:01
04:19
05:13
06:55
07:45
08:25
09:00
09:54
10:56
11:45
13:30
14:10
15:06
16:18
16:59
19:41
21:26
22:04
23:27
23:56
24:48
26:49
27:42
28:29
29:09
29:23
29:37
30:25
30:34
32:05
33:02
33:52
34:42
35:22
37:50
40:49
41:15
44:37
45:04
47:56
48:51
51:40
52:56
54:08
54:45
56:18
57:07
57:59
58:30
59:11
60:21
60:48
62:07
62:48
64:00
64:26
66:26
67:23
06:53
Video of the Day17:00
19:42
12:27
12:01
10:28