Check out the conversation on Apple, Spotify and YouTube.
Intro (0:00)
Aakash: JZ, I’ve been teaching people a lot about how to use Claude 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?
The Company OS: GitHub structure screenshare (2:04)
JZ: Of course. Let me screen share here. Let’s go to GitHub. You’ll see here that we have in GitHub a companywide operating system where for every single function in a company, customer success, data science, design, engineering, finance, legal, marketing, we have 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 renewals, upsells. You do 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.
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. Going to customer success, you can see that each of these folders have a series of folders that are the activities that they do and then within each of them they have skills. How do you actually think about creating the right assets for the negotiation support or the right references? For renewals, what is the skill file there to really think about how do you walk through a renewal correctly with a customer?
Now you’re like, okay, cool. You have some folders in GitHub. How does this all come to drive real change? At the end of the day, we all live in some form of email or Slack. So I’ll open up my Slack. This is a little bit more mock data but it shows you exactly how our team operates. Every single morning, every person on a lot of these customer-facing teams, they have highly repeatable motions. The more we can sing from one voice and say the same thing, the more we can create consistency in the awesomeness of the customer experience, that makes your company much more unified and it’s a big part of the brand.
This is an example for customer success. Here’s your calendar. Here are all the meetings that you have, the check-ins that you have, 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. When we do a handoff, when we do a session prep, all of these are actual skills. When anyone is using Claude, I’ll go into the organization settings and go into your skills. You can start to see that you can upload all of these skills into your company context. When you’re going through your day, you can say, I’m going through my day, I’m doing all these things, 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. You know exactly what skill to use when.
The 1% vs 99% problem (5:40)
JZ: The biggest thing that companies struggle with is you got these people who are these 1% AI users. They’re tinkering with their workflows. They’re highly AI-native. And then you have the 90 to 99% of the rest of the organization who isn’t sure what to use when. So as a result you can actually integrate your skills at a company level so across every single one of these functions, all the activities that they do, you can understand what skill should I be using when and where should I be spending my time.
Maybe the last thing I’ll just show to really bring this to life is every single company, you can map every single function’s work to what I call an ontology. In sales, all of the work in sales maps to these categories that they’re supposed to be doing. And within each category, there are series of tasks that happen. This is actually what has informed the OS I just showed you. We’ve done the really hard work of mapping out, for every single function, 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.
I’ll go to product which is a lot of the audience here today. In product, you should be spending your time like an engineer in many ways. 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, writing for stakeholder management, really mundane tedious organization, getting people on a phone, synthesizing feedback. All of these things are starting to get automated but it’s automated in a really lumpy way where one PM might be doing it really well and another PM might not be doing it as well. When you onboard everyone with a company OS, you can say, hey, these are all the playbooks, all the skills that I want to give every single person on my team. When they come in for their daily briefing, they are able to see their day at a glance and we essentially tell you where you can automate your day. You take the thing that is essentially designed by the 1% of 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.
Aakash: 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 is bringing that power to everybody. 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?
3 steps to build your own Company OS (9:00)
JZ: I like to think about it as three different steps, going from most simple to most advanced. 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? Typically for many functions it is, I write this email and I want this email to have a template that is automatically kicked off for me when certain things happen. I don’t want to input my data into a CRM anymore. I want that to be automated. What is super mundane, takes a lot of time out of your day-to-day, and if that were to be automated away you’d be thrilled about?
I’ll give you one very product-oriented example. There are so many PMs out there that spend a lot of their days responding to questions and escalations. The sales team comes into a channel.
Slack automation demo: feature request triage (12:30)
JZ: A lot of companies, if you just go into any ask product channel or any channel, you see so many success folks, support folks, sales folks, other teams hitting up that channel asking people, hey, I have a question, I have a feature request. The very small workflow that we did 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 is actually saying, what is the impact of this for your customer, what is actually going on here, give me some more details. All of those things usually require back and forth.
What is something that you do over and over again that you could really easily automate? That automation for us was as simple as, let’s just automate what we ask someone to fill in. Then what often happens is you then have to triage it. Is it for this team or that team? Is it for this PM or that PM? What’s the SLA to getting back to the requester on what we’re doing about this feature request? All of that you can build into something as simple as Slack. It automatically assigns it to the person that makes the most sense to go look at this. Then it automatically creates some kind of ticket so that we can track it. All of that is just a very small step in creating your operating system. So I start there.
Playbook to agent pipeline (14:31)
JZ: 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. At Laurel we have a large go-to-market team and within that we have really awesome customer success folks who are what I call time consultants, getting forward deployed into these organizations helping them use Laurel as a product. What we’ve done is we’ve essentially created a playbook. This is very long, I think anyone who’s ever created a playbook before knows. This is 50 pages. It covers everything from implementation to onboarding to user onboarding, and depending on who you are, is it the admin or is it the actual timekeeper, different onboarding.
These things are very fast now with Claude. You can actually create this from a lot of sources and have it be written really quickly. But the struggle most companies have 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 done by agents or workflow automations? This is where you can say, I’ve created a playbook, I’ve gone through and I’ve audited the things that require a human to do. It requires a human to get on the phone with someone, requires a human to go fly on site. But here are the things that we think we can automate. This is either something we can productize or something we can create an agent to do. That is 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. That’s actually where we started to get the first version of the OS I showed you earlier, when we went into customer success and said, what are all the things that someone might be doing? It was largely off of playbooks. The playbooks for implementation, the playbooks for activating a customer, the playbooks for talking to them the right way to make sure that they’re set up for success.
There are a lot of agent builders out there today. You could use Claude itself, you can use things from OpenAI, you can use Glean, you can use Dust. We at Laurel use Dust.
Aakash: If somebody hasn’t heard of Dust, what is this?
JZ: This is an agent building tool. What we find is often a lot of the things that someone does can be turned into a series of repeatable steps that gets automatically triggered. Going back to the playbook concept, if you say, hey, I have a playbook of all the things that you need to be doing here, 55 pages worth, I don’t think anyone’s going to read anything here. What you can do is go into an agent builder and say, I’m going to 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 have an agent built for each part of the workflow.
Going back to really thinking about how does everyone engage with your operating system thoughtfully, no one’s going to remember that they’re going to call the specific agent that’s going to do the email and the specific agent that’s going to do the RFP. The big learning that we’ve had is how do you create a mega agent, something like a full go-to-market agent, that can be called by the sales team at any point, by the customer success team at any point, and then that agent is able to route the ask or the need to whatever one of these sub-agents is actually useful.
The delivery piece is so important. Even the friction of coming to something like a different interface and asking it questions is too high. Instead, going into 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 actually getting people to use the agents and the workflows that you’ve built.
Aakash: Help me understand this part. Why use Dust instead of just Claude or Claude Code?
JZ: We started using Dust back in fall of last year and 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 that gap is shrinking quite rapidly and so I don’t think you need to go out there and buy a specialized tool. In fact you can just build them in Claude, and this is actually a little bit where we’re going. All of these no longer have to go through a Dust or a separate tool. Instead what we’re able to do is take all of these skill files and go into Claude itself and put them in as skill files. You can literally just say, hey, I’m inside whatever it is I’m doing and I can just call that skill, morning briefing product, and it gives me my briefing right there as opposed to me having to go and call an agent builder.
Aakash: Should people be setting up Claude automations on top of these to be running these? Is your daily morning briefing running on a schedule or something like that?
JZ: I set up a bunch of these scheduled things and what I found was that it was almost overkill. I sat there and said, oh, I might automate this, and so I built it. Oh, I might automate that, and so I built it. We’re in a world where we have information overload. This is why we took the time as a company to say, we can’t just assume that people are going to do this for themselves and second of all that they’re not going to be overwhelmed by the number of automations and scheduled things that happen. That’s how we consolidated it all into having all in one place, because we need to make sure that the adoption of AI is actually consistent across the org. You see a lot of PMs be super AI-native, a lot of engineers be super AI-native. You don’t see the same across all the functions, and potentially sometimes the go-to-market functions. 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 your workflow.
Aakash: I think I get it. The thing that you are encoding that’s most important is not the scheduled tasks or this particular interface in 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?
Company culture and the companywide hackathon (22:51)
JZ: It really starts with culture. It’s really important 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. What we did at this offsite is we did a companywide hackathon. How do we do a companywide hackathon every quarter, every six weeks? How do we even get the go-to-market team to do a hackathon and show what it is that they’re building? The expectation that everyone is a builder is true everywhere in the company, not just in engineering.
What we did is two things. One, we did training around how do you actually ship to production even if you’re not technical. So we created this enablement guide for how to ship features with Devin. Devin essentially is like an agent engineer. You can give it tasks. It started off a year or two ago when we first started using this as almost like intern-level engineer and today I think it’s actually a decent software engineer. As a result, my team is able to ship.
I’ll go through a couple examples. A feature, an end-to-end feature which includes front-end changes and backend changes where we enable people to delete temporary initiatives. When you’re keeping your time, sometimes you don’t know 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. That’s where temporary initiatives is really powerful. Now that’s a front-end and backend feature. It is not just a front-end cosmetic change. It’s actually pretty deeply rooted in how does it interact with other systems and when does it release versus not. There’s a lot of complexity in something like temporary initiatives.
If you look at the person actually knocking down those tickets and committing these PRs, this is actually a PM on my team. Nick, who is awesome, has been at Laurel for some time. Going back to his educational history, many of us didn’t grow up as engineers. And yet Nick, who I would say self-identifies more on the design side than on the engineering side, is able to take this feature end to end. Similarly, this is the empty state for when someone comes in, really thinking about new user onboarding. What is it that they see? How do we make that experience super delightful?
All of this is done by Jessica, who is again a PM on my team, not an engineer and also not a PM who necessarily started their career in engineering or studied computer science. And then there’s Ashley, someone on our customer success team. She deeply understands our customers and their needs. By working with the PMs on the team to really create this enablement guide for Devin, they worked on this together. If you are even less technical than a PM, if you’re on the customer success team, how might you use this guide to be able to really ship in a safe and reliable way?
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.
Going back to the ontology, for every single function in the company, what are all the buckets of work that they’re doing? We actually spend cycles saying, we believe that a product person should be operating like an engineer. All of the things that we expect an engineer to do, we expect them to be doing feature work, testing, actually cranking through the backlog. The exact same things show up in what we want PMs to do. We want them to be doing feature work with agents. We want them to actually be QAing their product and fixing the bugs. What we don’t want them doing is things that were really tedious like synthesizing competitive market intelligence, actually writing these detailed briefs, doing research planning, doing outreach for the research, synthesizing the research. Competitive analysis is a great example. You should be spending the time building the agent to pull the competitive data and you should just be monitoring it. Set up the system instead.
When we create this ontology, we’re able to say, 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 want to see Jess shipping this feature end to end. But what I want you to stop doing is these things that are really tedious, or at the very least be calling an agent every single time that you want to do that. Going back to how do we make that true, by building the skill files, by building the agentic workflows where necessary, and making sure that we’re surfacing them where people work. That’s ultimately the key pieces of the system.
PMs shipping front-end and back-end features (29:02)
Aakash: There is so much gold buried in the various parts of your answer there. The first part I want to double click on is PMs shipping to production. PMs not just shipping a little growth experiment where we change the text in a button, which is a front-end only change, but a front-end plus backend core feature, this temporary initiatives feature for instance that we looked at. That’s crazy. 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 the role of a PM today in an AI-native organization.
The captain model explained (29:44)
JZ: We talk a lot about this in terms of what is engineering anyway, what is product anyway, what is design anyway? We’ve really landed on this concept of we want there always to be a captain of any given initiative. The captain is the person where that skill set is the most important. There are lots of features. If we need to overhaul a system in order to make it much easier for PMs to ship and agents to work in that codebase, usually the captain is an engineering captain because that’s an architectural change. If we have a feature where the interaction is really king, doing really cool stuff on mobile to make it easy and delightful to look at how you spend your time in a given day and get insights from that, that is more so than anything a data problem. Data science is really plugged in there, but really the interaction is the most important thing to really sweat and make sure it’s delightful. As a result, a designer is the captain of that workstream. Then 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? That is a very classic PM thing and so it makes sense for the PM to be the captain of that.
Going back to a feature that might touch the front end and the back end, if we believe that the backend is in a good enough spot, and by the way you can ask Devin, or even anything that’s connected to your GitHub account, to look at the code and say, in what state is this, it actually gives you a pretty good answer. Then you can actually pull in engineering on the parts where you’re like, this is probably the most contentious or this is where it gets the most risky. You don’t do this by yourself because you happen to be the most technical person. You do this through the help of asking Claude Code to look at your codebase, Cursor, 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 this and go back and forth. It’s the same concept.
For the empty state we’re working on here, 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. The content has to do with the user and the business and the firm. That is a very classic PM thing and so it makes sense for the PM to be the captain of that. We still have code review and we make sure that engineers are code reviewing the things that are risky. All of those pieces together makes it so that we can all ship, including customer success, go-to-market, sales. Engineers get to work on the highest leverage backend tasks. PMs get to work on higher leverage features if customer success and go-to-market are enabled.
Aakash: What is the right set of checks and balances you need to put in place in your organization? How do customer success folks or go-to-market for instance make sure that what they’re building isn’t in conflict with something the product team is building, or in 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?
JZ: Something as simple as creating a channel like ask Devin reviewers and making sure that there’s visibility around all of the ways we’re using Devin to ship and then tagging in the right person, tagging in a front-end engineer to really look at something, tagging in a designer to look at something else, making it visible. The first advice I’d give is transparency is everything. The second piece of advice is you do need to set some ground rules. Going back to our enablement guide, we’ve set some ground rules as part of even the way Devin works. We used to do this quick check where whenever someone on support had an idea, they essentially could go into this channel and post their idea and get a really quick check on, is this something that makes sense? Getting people to chime in and say, this makes sense, this doesn’t make sense, I’m on the engineering team and let me give you some feedback, I’m the customer 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.
Two-track product reviews (37:38)
Aakash: 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?
JZ: The same way we have this captain’s model, I think about a framework where we call it two tracks. There’s one track which is much smaller. If you have something that some of the features I just showed you, they’re small enough where a PM, a product captain, or a product builder can take it end to end. Those don’t go through the same degree of rigorous review but they do go through things like that ask Devin channel, someone looking at the PR making sure things are good. You are responsible for end-to-end testing of your features. I think that’s actually really positive. The number of times in a waterfall model where a PM throws over to the designer and the designer throws over to the engineer and then the engineer throws back to the designer to do design QA and the designer says, this is not what I designed. That happens so often. It’s actually really empowering to say, I am the end-to-end product builder, I take something from beginning to end, I own and I’m responsible for the quality and impact of this thing.
Going back to the two tracks, you have things that can really take the product lifecycle and compress it down to a day, an hour, and that’s how you get the velocity. But there are some things where the way that this product is going to behave, what I’m suggesting, a change, the feature that I want to do, it requires much more alignment. A great example is within Laurel, if you’re going to change the complete way that activities are displayed, that’s a pretty radical change. How might a user go zoom in and out of their day? That is not a small thing. It’s the whole user interaction. As a result, we say, we do want to do a product review for that. We want to make sure that we talk about 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.
I really don’t believe in this thing where a lot of so-called AI-native companies say roadmaps are gone, planning is gone, everything is gone. If everyone’s running in different directions, even if you’re running incredibly fast, you’re not really going to get anywhere. I see a lot of great local maximizations, but sometimes it’s really hard to get to the global max. A whole new function change in your product, in your market positioning, without real rigorous thought around what is our strategy, what is our plan, why are we differentiated. Those are the things that require what I call a true product review process, where to me it’s more like a product strategy review. And then there’s architectural review, 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.
Aakash: Did temporary initiatives go through a product review?
JZ: It did not.
Aakash: What have been some of your recent product strategy reviews?
JZ: Today Laurel is beloved in a lot of firms that think about billable hours. We’re starting to find that there are a lot of firms, even if they don’t have billable hours, they still need to think about the concept of time. I think about the concept of time all the time. What are my PMs doing? Going back to this ontology and work map of every single function, 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 I want to be very clear. This is not a therefore we do not hire humans. It is, put the humans on the most important things.
Relationship building. You will never replace a real check-in, a real moment of 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 no one actually wants to do these things, what if the scheduling for the on-site and all of the back and forth and logistics were taken care of?
Even this idea of unreasonable hospitality, and I think this is such a great example. It is such a core value of ours here at Laurel. We want to delight our customers all the time. We want to delight each other. We’ve really codified unreasonable hospitality as almost like a cultural principle that we have as a company value. A lot of companies do this, by the way. They say, this is a cultural company value, and then it’s in a doc somewhere, people read it, and then they forget about it. What we do instead is we say, what does that actually mean? We want to make sure that no matter who you are, 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. Especially if you’re on the customer success team, we expect that you do this with our customers. How do we systematize that?
There are people on our team who, just from who they are as humans, are the kind of people who say, someone told me that they’re going to Mexico, and it’s the first time they’re traveling outside the country, so I bought them an engraved passport holder. That’s a lot of people on the Laurel team, but if I were to scale that to 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 going to happen.
Instead, we actually want to make sure that unreasonable hospitality is a check that we put in. Going back to the OS I was showing you, hey, if you have a check-in with someone and you 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? Here are some ideas that we’ve already pulled for you. We pulled from your Gong transcripts that these are things that they love. 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’re going to systematize that. That’s this real idea of deeply understanding your company’s work, your team’s work. What are the things that make 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.
Aakash: 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 the amount we’re showing here where they have a Devin agent that is shipping frontend and backend features. 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, this is too far away from my reality. Is it true that this just won’t work in certain types of companies, or will they eventually get there?
JZ: I’ll start with the end, which is I do think it is a matter of time that every company is going to 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. There will be pressure to ultimately get there for everyone. What you want to be for the company and for the individual is as advanced as possible in that curve as opposed to just waiting for it to happen to you.
This is where I go back to the first step is just start small. Start with one workflow that you are doing, or go find another team in your company. There’s always somewhere in the org that is hungry for product thinking and hungry for a tool to make their life better. 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. I’m getting into a customer call, I would love to be prepped for that in a way that an agent is serving me that information as opposed to me having to pull from multiple different sources. I write the same email over and over again, it should be auto-populated. These are just small automations or you can call them templates. Whatever it is that makes sense to you, start there.
If you’re ready to take on something bigger, map out your ontology or take your playbook and write that down. These playbooks can be written in an hour. The first draft can be written in sub a minute, but to make it actually right and really reflective of your business, it will take a little bit more time, but we’re talking hours here, maybe days max. When you get a feel for how much you can enable yourself and you can enable others, you’re going to create a culture where it’s celebrated and it’s fun. If you’re leadership, 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.
Aakash: 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 Devin where anyone can ship to production?
JZ: 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 replicate. The first piece I’ve already shared, which is this idea of just doing a hackathon and in the hackathon making everyone participate, because it changes this idea that you have to be technical to build something. The second step is to really think about all the different ways you can automate the workflow. 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 person full-time.
The AI Ops team and the Sasha model (50:08)
JZ: What I really find is a lot of times when you say it’s everyone’s responsibility, it’s no one’s responsibility. What we have at Laurel is we actually have an AI operations team. To me AI ops is the new BizOps. Before BizOps, they were doing really meaningful things, but often it was very high level, all the different hats, a lot of market-level stuff. Now, if you repurpose this idea of having BizOps, which is really 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. 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 shown today. What he did is basically say, I’m going to demonstrate value in having AI operations, and very soon 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. That is how you then get the buy-in to say, okay, maybe we have an 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, finance, RevOps, product ops, research ops, you name it, all of them are changing so dramatically.
Aakash: You guys were founded before the AI revolution. For other companies that were founded before then, where is the right driver? It feels like it probably has to start literally with the CEO.
JZ: I want to give a ton of credit to Ryan. Laurel was founded, it was called Time by Ping previously, was founded in 2018. Ryan actually had the foresight and the courage to say, when I think about what time looks like in a world of AI and LLMs, it’s very different. What does timekeeping look like in a world where you have to enter it manually or just do it through integrations, versus a world where you can actually start to really see everything that’s happening on your computer, synthesize that, and run that through an LLM? He basically had the foresight and courage to say, I’m going to rearchitect my entire product, my entire company, to be AI-native.
It does start with the CEO. But even if people don’t have that degree of change and conviction, I think you can still do it at every single level. If you are not the CEO but you’re an executive, you can say, this is how I expect my function to really operate. I am a marketing leader, I fully expect that this is what we are doing. Let me go color-code everything in here that should be AI-enabled. When you think about copywriting today, you should not be writing copy by hand, you should be editing. If you’re doing videos and you’re not using a lot of the AI tooling out there, you’re spending a lot of money on studio and video in a way that you don’t need to anymore. Being able to go line by line in terms of 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 AI-supercharge them.
Future of PM teams (54:45)
Aakash: As an AI-native 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?
JZ: For many people, 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 how we operate the team today with captains and taking features end to end.
What I do look for specifically in product builders who are product managers by training, I look for a couple of things. 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, if you 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 a lot of people who are very experienced and almost scared that their job is changing. They’re feeling more fear than excitement. There’s another group of people who are very experienced and they’ve never been more excited. I have never been more excited by the way to not be doing all these things I used to do in the past that took me forever and that there was no part of me that wanted to be doing anyway. I love actually shaping a product, really getting hands-on.
Being able to find those people who are excited, who are curious, but yet have the judgment and the reps, is really really important. What I found really interesting was there are a number of people in my team who previously were CPOs, VP of Products, heads of products. They’ve come in and they’re the ones building end to end, they are the ones shipping end to end. 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 it is just coordination cost. Instead they can just be enabled to get right in there and drive the change that they want to see.
Aakash: So you have embraced the super senior ICPM. 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?
JZ: I think so. I’ve had hundreds of people and today I have five PMs and four designers. There isn’t a real reason to grow that. 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 best teams are going to be lean but not so lean that they’re starved. It’s really important to find that line.
The screen-share interview (57:59)
Aakash: You said you do something pretty crazy in your interviews. Can you tell me how you interview people and really find these gem AI-native super senior ICPMs?
JZ: A lot of people are talking about doing a session where people have to build with AI. I think that makes a lot of sense. But what I’ve been doing, and I do this by the way for every function, not just product or design, is I do ask people to screen share. What I found is it is so easy to say, I’m AI-native, we do a bunch of stuff with AI, but as soon as you really peek under the hood, you’re like, actually I think you’re what I call level one.
The 4 levels of AI maturity (59:01)
JZ: Level one is you’re talking to ChatGPT, you’re talking to Claude, you’re really using AI kind of in a chat mode, almost like search mode. I ask a question, you give me an answer. Level two is where you start to automate a workflow. This is what I was showing earlier around just the first step, like start small. An OS does not start necessarily as an OS, but it starts with a first automation, a first little piece of workflow that everyone’s going to start doing. Level three is when you start building apps. This thing is really tedious, I’m going to build an app to make it less tedious. Then level four is where you’re actually building what I call shared apps, or if you really think about the product lifecycle, you’re really shipping to your customers. Those are the four levels that you can assess yourself on, you can assess a given company on, which of those four levels is the majority of the organization operating at.
When you actually ask someone to screen share and show you how they use AI, you can very quickly get a sense of, are you at level one, are you basically just talking to ChatGPT, or have you actually created some way to really scale yourself, some kind of workflow, some kind of agent, or are you starting to build apps, or what are you truly shipping? Getting to see that live on screen is really interesting because otherwise it’s really easy to just say, this is what I do, and you’ve pulled it from LinkedIn or pulled from the latest thing you saw on the internet. But actually peeling it back and seeing what is on your screen is really fascinating.
Aakash: People don’t believe me when I keep saying this is the new interview. You’ve heard it from a CPO herself. A lot of people are feeling pretty bad about this whole transition. There’s a lot of uncertainty going around in the PM field. People are feeling very nervous about this change, saying 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. Can you unpack that for us?
JZ: 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-native, who are fearlessly going through all of these pieces. And by the way, one of the most important things forever that will never change about the PM role is that they have to stay close to their customers. The Venn diagram of all of those traits is not large in terms of the actual number of people that fall into that. That’s what every company’s going to want. Around the edges, why would I go hire someone who is not all of those things? I’m going to have to supplement them in some way and it’s going to create overhead.
I think it’s really finding who I call the orchestrators. The people who are big picture in their thinking, but down to the detail in their execution. Those are the people who are worth their weight in gold. A lot of people who need to be complemented by a designer and complemented by an engineer, complemented by many many other people, it just doesn’t make sense anymore because why go hire all those people when one person can be the end-to-end builder?
Aakash: 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.
JZ teaches at Stanford, Yale, Reforge (1:03:26)
Aakash: JZ is not just doing this though. You actually have so much cool stuff going on. You teach product management at Stanford. You’ve been involved with Reforge. Can you catch us up outside of Laurel?
JZ: I do teach every year at Stanford. I do it for the love of really just getting to meet the next generation of builders. I also get the really awesome benefit of meeting people like the Sashas of the world who once took my class, then TAed for me, and now is at Laurel. Teaching for me has been a combination of passion and honestly of pipeline. I teach at Stanford, I teach at Yale, and I teach at Reforge. When you teach something, you have to know it like the back of your hand in order to actually share that with someone else. A lot of times I’ll teach and then I’ll be like, good reminder, JZ. Were you doing that today in your day-to-day? Were you customer-centric enough? Were you problem space first and not solution first enough? I find it both so gratifying personally but also such a great reminder of what product really is.
I teach AI leadership through Reforge and that curriculum changes literally by the month. We teach every six months and the amount of change between the six months is massive.
PM fundamentals never changed (1:04:44)
JZ: When you actually teach fundamentals, when you teach what I call PM 101, those core principles have not changed. You should still always never jump to the solution. Now that you can build faster than ever before, it doesn’t mean you just build everything. What actually is important is to know why and for whom you’re building and what it is that you’re trying to solve for and what success looks like. Therefore, you actually know you’ve hit your target.
What’s really ironic is that through teaching all these different levels of product people over the years, I find that 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. 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 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.
Aakash: What a way to end it. JZ has absolutely killed it. Thank you so much, JZ.
JZ: Thanks for having me.