The GitHub Repo That Runs Her $100M Startup

1. 0:00 – 1:46

   Intro

   1. JZJiaona Zhang0:00

      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.

   2. AGAakash Gupta0:09

      Meet JZ. She's the chief product officer at Laurel, the $100M AI time platform. She teaches PMs at Stanford. Before J- 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?

   3. JZJiaona Zhang0:32

      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.

   4. AGAakash Gupta0:42

      How should people be thinking about, in an AI-native organization, this is the role of a PM?

   5. JZJiaona Zhang0:47

      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 what I call shared apps.

   6. AGAakash Gupta1:02

      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 want to 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 Mobbin, Arise, Relayapp, Dovetail, Linear, Magic Patterns, DeepSky, Reforge Build, Descript, and Speechify. So be sure to check that out at bundle.aakashg.com. And now into today's episode.

2. 1:46 – 2:04

   Episode begins

   1. AGAakash Gupta1:46

      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

3. 2:04 – 5:40

   The Company OS: GitHub structure screenshare

   1. AGAakash Gupta2:04

      it does?

   2. JZJiaona Zhang2:04

      Of course. All right. 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 companywide 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 c- 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 sh- be sharing, so this is a little bit more mock, but it shows you exactly how our, h- 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 s- uh, experience, that makes, um, your company, you know, much more unified, and, um, 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, um, in their day and really seeing, um... 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, uh, 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, um, Claude, for example, and I'll just go into, um, I'll g- 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,

4. 5:40 – 9:00

   The 1% vs 99% problem

   1. JZJiaona Zhang5:40

      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 b- 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 function's 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, you know, the ontology or the work map of a product manager is starting to lo- look a lot more like an engineer. But there are a lot of things that used to be in the, um, 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, et cetera. 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? Um, 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.

   2. AGAakash Gupta8:25

      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

5. 9:00 – 10:05

   3 steps to build your own Company OS

   1. AGAakash Gupta9:00

      system?

   2. JZJiaona Zhang9:00

      I like to think about it as three different steps, and so let me sh- screen share again, and I will, um, share how do I think about essentially, um, getting your steps in, going from s- 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-to-day, 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-

6. 10:05 – 12:30

   Ads

   1. AGAakash Gupta10:05

      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 where I already work. Check it out at ariso.ai/aakash. That's A-R-I-S-O.A-I/A-A-K-A-S-H. 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 mockup. You're building real front-end code that integrates with your existing design system. 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 2:00 AM 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 Bolt at bolt.new/aakash. That's B-O-L-T.N-E-W/A-A-K-A-S-H. 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 gen AI, but just as many have 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 roadmap. 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/aakash. That's P-E-N-D-O.I-O/A-A-K-A-S-H.

7. 12:30 – 14:31

   Slack automation demo: feature request triage

   1. JZJiaona Zhang12:30

      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 s- 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 can 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, requester 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 101, I would say, right? Is 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

8. 14:31 – 22:51

   Playbook to agent pipeline

   1. JZJiaona Zhang14:31

      automate based on a bunch of things that your team is doing. And so the example here I have is, you know, again, a, a team that usually has a lot of people, a lot of humans. Um, at Laurel, uh, we have a, a large, you know, GTM team, and 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-

   2. AGAakash Gupta15:08

      Whoa

   3. JZJiaona Zhang15:08

      ... from implementation to onboarding to user onboarding and, and depending on who you are, is it the admin? Is it the actual, um, timekeeper, et cetera, 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, um, model, this is where you can say, "Okay, well, I've created a playbook. I've went through and I've audit 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, 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, and that's, by the way, where we, um, we started to, 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, um, yeah, 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, which is there are a lot of, um, agent builders out there today in the world. So you could use, you know, Claude itself. They've launched obviously a lot of, um, agents. You can use, um, 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.

   4. AGAakash Gupta16:59

      So if somebody hasn't heard of Dust, yeah, this is an agent building tool?

   5. JZJiaona Zhang17:03

      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. [laughs] I don't think anyone's gonna read anything here. Um, what you can certainly 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, um, 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 f- like 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. [lip smack] 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 Dusk and asking it questions is, is really low. Ins- instead, actually going into your, um, your Slacks, your emails, and delivering people, um, 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.

   6. AGAakash Gupta19:02

      So help me understand this part. Why use Dust instead of just all Claude or Claude Code?

   7. JZJiaona Zhang19:07

      Yeah, that's a great, uh, question. We started using Dust back in fall of last year, and so I think there was just a maturity of the tools. Um, 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's, um... 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. Um, and, and this is actually a little bit where we're going, which is, um, 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. Um, 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/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.

   8. AGAakash Gupta20:13

      Mm. And then should people be setting up like Cl- odd automations on top of these to be running these? Is your daily morning like running on a schedule or something like that?

   9. JZJiaona Zhang20:23

      Yeah, that's a great question. It's so funny. Um, I'll go... I'll share a little bit my personal experience. So I set up a bunch of these scheduled things, and even if I just go to Scheduled, um, 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 [chuckles] 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 was 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, scheduled 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, y- your workflow. And the, 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-

   10. AGAakash Gupta22:04

       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 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?

   11. JZJiaona Zhang22:29

       Yeah, absolutely. I think it really starts with culture, and I just have a few photos from, um, our offsite, um, about three months ago. And, um, it, 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

9. 22:51 – 29:02

   Company culture and the companywide hackathon

   1. JZJiaona Zhang22:51

      offsite 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, um, every quarter, every six weeks, right? Um, or how do we even get the, just the go-to-market team to do a company, uh, 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, um, enablement guide for how to ship features with Devin. And so, you know, Devin essentially is like an agentic engineer. Um, 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. [chuckles] 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 g- 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 de- to delete temporary initiatives. So when you're keeping your time, sometimes you don't know, um, 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, uh, 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, um- ... 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 is 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, um, w- I, I would say he's probably identifies, self-identifies more on the design side [chuckles] than on the engineering side, is able to take this feature end to end, which I think is just so cool. Um, similar, similarly, um, within, you know, many parts of our product, and I'll just go through another example here, this is, um, the empty state for when someone comes in. So really thinking 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, 'cause I think this is even cooler, is, uh, this little picture here, um, which is, this is someone on our customer success team. Ashley's 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 the success team, how might you use this guide to be able to really ship the way, um, you know, i- 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 again, 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 an- 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 ex- 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, a, an error where, you know, here in ontology, we really have things like we want you to be, you know, doing feature 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 it before. And what we don't want you to be doing is things that were really tedious, like synthesizing competitive market, you know, intelligence, um, actually writing these, like, detailed briefs, doing research planning, doing reach out for the, the research, synthesizing the research. Like, all of that, um, 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 at the very least to be calling an agent every single time that you wanna do that." And it, and then, again, going back to 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 surfix- for surfacing them where people work. And that's ultimately the, the key pieces of the system.

10. 29:02 – 29:44

    PMs shipping front-end and back-end features

    1. AGAakash Gupta29:02

       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 PMs shipping to production. Okay, people have heard about that. But PMs 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?

11. 29:44 – 30:34

    The captain model explained

    1. JZJiaona Zhang29:44

       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, um, l- 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 i- 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

12. 30:34 – 32:37

    Ads

    1. JZJiaona Zhang30:34

       that.

    2. AGAakash Gupta30:34

       I hope you're enjoying today's episode. Are you interested in becoming an AI product manager, making hundreds of thousands of dollars more, joining OpenAI and Anthropic? Then you might wanna do a course that I've taken myself, the AI PM Certificate ran by OpenAI product leader Miqdad 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 want to see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavel Hern, is the Build Labs leader, so you're gonna live build an AI product with Pavel's feedback if you take this AI PM 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 for me, triggers, timing, copy, even branching logic. And when I want to know how something is performing, I just ask the agent directly, and 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 your 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 6 to 7% with localized campaigns, and pushed open rates up another 20% through A/B 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.io at customer.io.

13. 32:37 – 37:38

    Continuation to captain model

    1. JZJiaona Zhang32:37

       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 feature 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-- uh, 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." Um, uh, and then you can actually pull in 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 this 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, um, you know, LLMs, 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.

    2. AGAakash Gupta35:22

       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 does CSMs or, uh, 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 contic- 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?

    3. JZJiaona Zhang36:01

       Yeah, that's a great question. Um, so we, again, I believe in the power of humans, so something as simple as, you know, creating a channel like Ask Devin Reviewers and being able to go through here, um, and making sure that there's visibility around all of the Devin, um, all the ways we're using Devin 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 a designer to look at something else, really going through and, um, making it visible. I think the first, uh, advice I'd 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 oft- we, um, we actually used to, uh, do this quick check where, um, whenever someone, let's say someone on support had an idea, um, they essentially could go into this channel and post their idea and get a really quick check on, um, is this something that, uh, makes sense? And again, I'll just may- zoom in here, like I'm proposing a change to this experience. Um, getting some, some feedback, right? And, and being able to say, "Hey, play around with the first version of it." Um, 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 team, and let me give you some feedback. I'm on the success team, and 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.

    4. AGAakash Gupta37:36

       Double-click on product reviews

14. 37:38 – 50:08

    Two-track product reviews

    1. AGAakash Gupta37:38

       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?

    2. JZJiaona Zhang37:50

       Yeah. Um, the same way we have this captain's model, I think about, uh, a framework where we call it two tracks. So there's one track which is much smaller. If you have, um, something that, uh, even some of the features I just showed you, like they're, they're small enough where, um, again, a PM, um, 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, uh, rigorous review, but they do go through things like that #askdevon channel. They go through things, um, you know, like, uh, like someone looking at the PR, making sure things are good. Um, you, by the way, you are responsible for end-to-end testing of your features, and that's actually really positive. The number of times where in a waterfall model you would, PM throws it over to the designer, and the designer throws it over to the engineer, and then engineer throws back to the designer to do design QA, and the designer's like, "This is not [laughs] what I designed." Um, that is just, I think it's just such a, it's like, it's almost a meme 'cause 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 all, 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 as 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 requi- 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. 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, uh, it... 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, "Roadmaps are gone, plannings are 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, 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.

    3. AGAakash Gupta40:49

       Hmm. So did temporary initiatives go through a product review?

    4. JZJiaona Zhang40:52

       It did not.

    5. AGAakash Gupta40:53

       Wow, okay. So what would be the, like, the right aperture? What have been some of your recent product strategy reviews?

    6. JZJiaona Zhang41:00

       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? [laughs] Going back to this ontology, um, 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 hu- 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 onsite, 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 onsite 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 were gone? 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 want to delight our customers. And so we really have codified, um, unreasonable hospitality as, as almost like a, like a cultural principle that we have, a, 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 touchpoint. How might you surprise and delight them? And here are some ideas that we 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?

    7. AGAakash Gupta44:38

       So you, this isn't your first rodeo. You've been in product for a really long time. If we rewind back to some of those experiences, those formative 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. [laughs]

    8. JZJiaona Zhang45:05

       [laughs]

    9. AGAakash Gupta45:06

       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 s- you'd be surprised. Even at companies like Adobe, PMs are still living in that world [laughs] 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, it is just a matter of time.

    10. JZJiaona Zhang45:34

        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, a- 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, um, and/or I really, I really push on this. I think this is really, uh, 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 pre-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, sa- 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 y- 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. [laughs] 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 en- enable others, you're gonna create a culture. Again, even just going back to culture change. You're gonna create a culture where, um, it's celebrated and it's fun. And, and again, if you're 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, um, expectation and you celebrate those wins, you'll get more and more of that behavior.

    11. AGAakash Gupta48:51

        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?

    12. JZJiaona Zhang49:05

        Yeah. Uh, 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. Um, the first piece I've already shared, which is the idea of just doing a hackathon, and in the hackathon, uh, making everyone participate, 'cause it changes this idea of you have to be technical to build something. That... And, 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 the different ways you can, again, s- automate the workflow. I think that a structural thing that I would really recommend is actually making th- this idea of playing with AI tooling, creating workflows, um, automating, you know, 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

15. 50:08 – 57:59

    The AI Ops team and the Sasha model

    1. JZJiaona Zhang50:08

       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 BizOps. Before BizOps, they were doing, um, really meaningful things, but often it was, it was very, um, high level, all the different hats, a lot of, like, market level stuff. Now, if you repurpose this idea of having BizOps, which is really, again, a Swiss Army knife in many ways, to finding people who are insanely curious, tinkering with the latest technology, and, um, 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, um, Sasha, uh, who has built out a lot of the things that I've, I've shown today. Um, 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, a AI operations person just doing go to market, and a separate AI operations person just doing product, um, and a separate op- 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.

    2. AGAakash Gupta51:40

       Mm. That's really interesting. And you guys were founded before the AI revolution, so w- h- I guess, like, for other companies that were founded before then, I think you were 2018, like, where, who is, like, the right driver? It feels to me like it probably has to start, like literally with the CEO, right?

    3. JZJiaona Zhang51:58

       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 TimeByPaying, 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, um, where you have to kind of enter it manually or just do it through call, call it what I call integrations, um, 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 re-architect my entire product, my entire company to be AI native." And so it's, it's really interesting. Like, I really believe that, um, and I experience this day to day, um, I would, you know, like I, I was like, I w- I, I wanna be building at the cutting edge. Um, a- Laurel is AI native, although [chuckles] it was founded pr- like more than three years ago. Um, and so that, it does start with the CEO. Um, but even if it, if, uh, people don't have that degree of change, um, and, 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 m- 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 char- supercharge them?

    4. AGAakash Gupta54:08

       Amazing. So I think that's the key point for a lot of people that I talk to at least, is that they ha- 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-built [chuckles] 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?

    5. JZJiaona Zhang54:45

       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? Um, I'm a big believer of the fact that I think everyone should be a product builder. It goes back to my, um, [lips smack] uh, how we operate the team today with captains and taking features end to end. Um, what I do look for specifically in, in product, uh, builders who are product managers by training, um, I look for a couple things. Um, [lips smack] I found that, uh, if you're incredibly senior in the sense that you have the judgment, you've gone through the hell fire, you've shipped things that haven't worked, and, uh, 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, uh, a little bit of a bifurcation. There are a lot of people who are very experienced and almost scared that their job is changing, and, um, 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, I've never been more excited, by the way, to [chuckles] not be doing all these things I used to do in the past that took me forever, that there was no part of me that wanted to 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 on 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's just coord- 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 want to see.

    6. AGAakash Gupta57:07

       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?

    7. JZJiaona Zhang57:25

       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, um, because again, like when you add more people, you add more coordination costs. You actually, um, 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, um, 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.

16. 57:59 – 59:01

    The screen-share interview

    1. AGAakash Gupta57:59

       So, you said you do something pretty crazy in your interviews. Can you tell me how you interview people, um, and really find these gemmed AI-pilled super senior ICPMs? [chuckles]

    2. JZJiaona Zhang58:11

       I think a lot of people are talking about, of course, you know, you do a session where people have to build with AI. Um, I, I think that's all fine, and, um, uh, I think it makes a lot of sense to do that. Um, it, it takes cycles, by the way, to even have a standardized interview loop. Um, 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, um, 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, um, what I've been doing, and I, I do this, by the way, for every function, not just product or designer, so, you know, so on and so forth, um, 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

17. 59:01 – 1:06:08

    The 4 levels of AI maturity

    1. JZJiaona Zhang59:01

       as you get into, um, 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, uh, 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, um, I'm, I'm doing this thing. It's really tedious. I'm gonna build an app to make it like less tedious." And then level four, I'd say, is where you're actually building, I call, shared apps and/or, um, if you really think about the product life cycle, you're, 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 which 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 s- get a sense of are you at level one? Are you basically just talking to ChatGPT? Um, or have you actually created, um, like, uh, uh, 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, um- ... 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, you know, pulled from LinkedIn or pulled from the latest thing you saw on the internet. Um, but actually peeling it back and being like, "What is on your screen?" is, is really fascinating.

    2. AGAakash Gupta1:00:58

       Wow. People don't believe me when I keep saying this [laughs] 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. 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?

    3. JZJiaona Zhang1:01:32

       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's 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 it, when, when in, in many ways I can take that piece that is not excellent, and I can build, like, you know, again, a workflow, an 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 or complemented by an engineer, like, you know, complemented 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?

    4. AGAakash Gupta1:02:48

       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.

    5. JZJiaona Zhang1:03:10

       [laughs]

    6. AGAakash Gupta1:03:10

       JZ is not just doing this, though, right? You actually have so much cool stuff going on. You teach product management at Stanford. I think you had, at some point, had been involved with Reforge. Can you catch us up outside of Laurel? What's the world of JZ? What's going on?

    7. JZJiaona Zhang1:03:27

       [laughs] Um, I do teach every year at Stanford. Um, I do it for the love of, um, really just getting to meet the next generation of, of builders. Um, I also get the really awesome benefit of meeting people like the Sashas of the world, who, you know, once took my class, then TA'd for me, and now is at Laurel. Um, and, uh, you know, teaching for me has been a combination of, of passion and honestly, uh, of pipeline. Um, so I teach at Stanford, um, 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 a- and I just find this really funny. A lot of times I'll teach and then I'll be like, "Ah, good reminder, JZ." Like, [laughs] uh, "Were you doing that today in your day-to-day?"

    8. AGAakash Gupta1:04:16

       [laughs]

    9. JZJiaona Zhang1:04:16

       "Um, 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 Reforge, and that curriculum changes literally by the month. Um, you know, we teach every six months, and the amount of change between the six months is massive. But when you actually teach the fundamentals, when you teach the, what I call, like, PM 101, 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, um, 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, um, the speed has changed dramatically. But what you're supposed to be doing at the heart of it, that has not changed.

    10. AGAakash Gupta1:06:06

        What a way to end it. All right,

18. 1:06:08 – 1:07:58

    Outro

    1. AGAakash Gupta1:06:08

       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 AI-pilled CPO like JZ. 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 on 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. JZ has absolutely killed it. Thank you so much, JZ.

    2. JZJiaona Zhang1:07:12

       Thanks for having me.

    3. AGAakash Gupta1:07:13

       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.aakashg.com to get access to nine AI products for an entire year for free. This includes Dovetail, Mobbin, 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

Episode duration: 1:07:59