• Chris Geoghegan on LinkedIn
• Cursor for PMs course from Tal Raviv

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike, and today’s interview is with Chris Geoghegan, often known as Geo. Geo was the first product manager at Zapier, the automation platform, which over the last decade has grown ARR from millions to hundreds of millions, during which time he has earned his way up to VP of Product. Welcome, Geo.

Chris: Thanks for having me, Allen. Excited to be here.

Allen: Yeah, I’m excited to have you. Zapier has long been a fascinating company to me for its unique culture, but now it’s in also this unique position. The world is exploding with potential for automation with AI, and Zapier started that race at the most connected automation platform, so it’s sort of explodes the set of possibilities for the business. So I feel like it’s interesting times to be chatting with somebody who’s helped a bit of build it.

Chris: Yeah, it is really exciting to be a part of a company that gets to be at the forefront of how AI is actually being used in businesses today, so.

Allen: Cool. Yeah, so we’ll dig into that, but first I like to give folks some context on who it is we’re talking to. How do you like to summarize the Geo story in a sound bitey sort of way?

Chris: Yeah. I started out in software development in high school, and my first job out of university was building websites. Back in the day, it was Drupal Content Management System, for anybody that remembers that, and transitioned out of agency work into what I later found out was product management, building product. I don’t think there was a course for it at that point in time. You just sort of became a product manager somehow, magically.

Allen: Yeah. I don’t know even what the courseware would be for that, because I definitely came through computer science and then eventually got into product, but I assume there’s courses.

Chris: Yeah, now there is. Yeah, now there is, for sure. Yeah, I worked in a bunch of different startups locally, and I was commuting back and forth to downtown. It was probably a three-hour commute. And so, one day I was like, “I wonder if there’s any remote jobs out there?” And Zapier is a product I had known and used before and I was like, “Oh wow, they’re remote.” And so, that started my journey with Zapier over the last nine and a half years.

Allen: Yeah, so that’s like a micro version, and let’s peal into the aspects of that ‘cause there’s a lot there. Let’s start with the kind of position of, giving people context for Zapier. I think most people are familiar with the product, at least as a visual automation integration platform, which is more to it than that, but that’s kind of the core original idea. You’ve been on this forefront from early on of being able to then compose that together with LLMs as they’ve gone from novel curiosities to actually useful in recent years. What have you been seeing so far in terms of what people have been building, both customers, to the degree that you can, I’m sure there’s some customers you talk about? But then also, I know you have a culture internally of building tools and automations and stuff like that. So what are some of the things that are getting you excited?

Chris: Yeah, I think one of the fascinating patterns to look at is determinism versus inference and how you mix and match those. And so, one of the things we found, our very, very early strong take was, look, these tools being trapped in a chat window isn’t going to be automation. They need to be connected to the knowledge you have, the tools you use. And so we have that today, but when we first started out down this path with GPT-3 launching, all of those things didn’t exist. And so we were very much trying to figure out, “How do we connect what is happening with AI to the tools that you use for work?” from pretty much day one. Obviously, now we have tools like MCP and agents and things like that. We try to create the platform where all of those pieces can come together.

Allen: Yeah. Well, you mentioned this to play in between the deterministic and non-deterministic, which is topics come up a few times. We had David Hariri from Ada on the show a while back. Everyone learns lessons from their own context, and so then you have adapt them to your context. But he was saying that from their context, they’d originally thought having the deterministic system that would occasionally call into an AI or a non-deterministic system, in this case the AI, was the most robust way, but they’ve moved over time to having a non-deterministic system be in charge, and then have the deterministic stuff be tools for the AI. Whereas when I think of Zapier for the method that I’ve used it, which is probably baby version compared to what some of the customers use it for. I think of Zapier as being inverted, whereas the kind of backbone of it is deterministic, but then it calls into non-deterministic stuff. So do you have a product philosophy of either A, which approach tends to be most effective for certain use cases or just where that’s going?

Chris: Yeah, I think one of the things we’ve seen is starting with non-determinism is a very easy entry point for people who are trying to build. So just start with a purely agentic system and then see what parts become repeatable, and then you start to outsource to the automation workflow, the deterministic component. So that’s what we found, is it’s easiest for people to just wrap their heads around, “Hey, I give an agent a prompt, I see what it does, and then the agent can go and say, “Oh, I actually think this part should be deterministic. Let’s build a Zap around that.” And so, that’s sort of where our copilot comes into play. But where we’ve seen sort of the most scaled usage, where there’s a stats out there of every organization has an AI transformation program, but 80% of them say they haven’t seen the impact that they hoped for. Where we’ve seen real impact is when folks are able to connect the triggers in the real world. You’re not creating these agents that are chat triggered, they’re triggered by something that’s happening behind the scenes, like a new bead comes in or a Jira ticket is created. And so that is a true agent working on your behalf when you’re not at the keyboard. So that’s where we’ve seen the biggest opportunity.

Allen: Yeah, it sounds like you’re seeing the potential in the same direction that David was, which is this sort of backbone, for lack of a better term. Being the agentic system, that’s how you prototype. You can have in this non-deterministic thing that will, on vibes, get you 90% of the way, but then you superpower it and you wire in and actually kind of build out the parts where it’s like either this part doesn’t always work, or actually, the LLMs are bad at this part or whatever, and then you slowly build out the parts that are worth making deterministic.

Chris: Determinism is going to be cheaper, it’s going to be more reliable. It’s going to happen the same way every time. And so, where that makes sense, default to that is kind of how we think about it.

Allen: Yeah, that makes a lot of sense. Any tool that’s low code or builders or workflow things, always there’s this huge challenge of, “You can build almost anything.” And then a lot of people look at it and they’re like, “Okay, but I don’t know if I need to build anything.” It’s like there’s always things you could build that would get you a lot of leverage, but it’s often that gap in between the potential, and then actually going in and someone feeling the pain acutely enough that they go and then actually try to solve the problem up maybe long after it was worth it. Are there any internal tools or things that you in even in your own work that you’re finding have been helpful for you that you’ve been able to build with this stuff?

Chris: Yeah, taking a step back a little bit, this is one of the hardest things about being a product manager for a very horizontal product, because honestly, you’re building a bunch of Lego blocks that people could assemble in any different way. Whereas if you’re building an applicant tracking system, you know exactly who you’re selling to that to, you know exactly what problem you’re solving. Whereas you could build an applicant tracking system on Zapier. Right?

Allen: Sure, you could.

Chris: And so, one of the things I’m-

Allen: I’m sure someone has.

Chris: Yeah, definitely they have. And so, one of the things that Zapier tries to lean into is every department leaning into what we call a Zapier on Zapier, using the product for their own thing. And so, a lot of our HR team are some of the best salespeople, because they know exactly what to build for HR and they can go and help other organizations, other HR departments deploy that. And so, there’s a lot of hands-on building for your own department. Our rev ops team are some of our best salespeople to rev ops professionals.

Allen: Of course.

Chris: For product management, one of the things that I’ve been playing around a lot with is MCP. If you’re familiar with Tal Raviv, he’s got this whole program on AI, PM, and Cursor.

Allen: I haven’t seen that one.

Chris: Yeah, worth checking out. Shout out to that course. I believe it’s on Maven. And one of the things you can do, is with MCP, you can bring all the tools you use for knowledge management right into Cursor. So, maybe you’re writing a spec inside of Cursor. Well, you have Glean search there, you have Google Docs search there. You can sort of bring all of those tools into one spot. So that’s an area I’ve been personally poking around a lot recently with bringing MCP and doing a lot of the work, just non-dev work instead of Cursor. So you have access to all those tools and yeah.

Allen: Yeah, I love it. You mentioned Glean, and so I’ll put a point on this, because I think as someone who’s building an AI, I’m very familiar with the different tools that people have, but I think a lot of people don’t yet know about Glean if their organization doesn’t have it. And also, it fits into kind of this thesis that we talk about at Forestwalk, where organization like Zapier especially was very transparent. You post a lot of information internally about discussions and things that are happening, but it’s kind of a fire hose. And then people will say, “Well, why post all this stuff if you can’t find anything?” Could you just briefly explain what Glean is and how it might be useful to people?

Chris: Glean, I think of as just being really, really great at searching across all of the artifacts you have inside of your organization. So, if it exists on Slack or Google Docs, or we use Coda as an internal documentation tool, or any other number of places, Glean is going to be really good at finding that. They have built some AI capabilities on top of it, but what it’s really good at is just searching across your documents. And like you said, I think one of the hardest parts about a highly transparent organization like Zapier, you have this fire hose of information, so how do you stay up to date on it? And having a tool where you can just sort of say, “Hey, what’s the latest…” I’m preparing for the podcast and I’m like, “Hey, what are our guidelines on speaking on a podcast?”

Allen: “Am I even allowed to talk to Allen?”

Chris: Yeah, exactly, exactly. So I can just go and ask that question and not have to figure out, “Oh, where do I track that down again?”

Allen: Oh, that’s super useful. Almost every organization I talk to about their docs, there’s some amount of angst about they’re out of date an, “Where do I find anything?” And then it just ends up being a mess. And then there’ll be a new product that comes along that claims to be a better place to organize them, but at the end of the day, it often ends up being a human problem rather than a technology problem. And so, it’s cool to see a technology solution maybe to that.

Chris: I think about, it’s an interesting thought exercise, when you’re just using ChatGPT or Claude on a day-to-day basis, think about what you’re doing. Not what the AI is doing, but what are you as the human doing when you’re interacting with Claude. You’re basically going and gathering documents and context and framing your question, and then realizing it didn’t answer it right because you didn’t give it a very good prompt. So you say, “Your role is this and my role is that, and these are the people in my organization.” So you’re constantly feeding it context. We talk a lot about the verified context that we want the AI to have when we’re working with it. The better you engineer that context, the better results you’re going to get out.

Allen: For those of us that are engineering products on LLMs, I don’t want to say all, but much of the job is literally just figuring out how are we going to get the context, and then how are we going to provide it or not provide it, and explain it and fence it, and redact it and manage it? ‘Cause obviously, the more context you give the agent at first, it’s better and better. And then it actually gets worse and worse as you confuse it with, “Oh, here’s six years of meeting minutes.”

Chris: Totally.

Allen: The attention mechanism blows its mind and you don’t get anything useful at all. So that context engineering thing is up and down the stack all the way now.

Chris: That’s sort of one way we’ve been thinking about how do roles change in this new world? There was this framework, and I’m not going to be able to cite the source, unfortunately, but it was thinking about there’s three levels you might operate at. There’s the operator, “I’m just using the tool.” Then there’s the engineer, “I am thinking about how to design the tool.” And then there’s the architect level of like, “I am creating the system from which everybody else can work.” And so, when you think about, I don’t know, any given role inside of a tech company, say like tech writing, writing the help doc as operator, creating a Cursor role that allows other people to then go write great help docs might be sort of the engineer, and then thinking about how does that whole system come together in an automated fashion might be sort architect role. And so, I think that’s one thing AI is reshaping in terms of how engineering product and design work together, is we’re all moving into being these architects and having AI as somewhat of a teammate that we can call on.

Allen: Yeah, well, this is one of the common discussion points of leaders when we’re building our teams and thinking about the shape of them, is how much that architect verb and mentality, which previously you would have pretty small slice of your team needing to think that way. Most people, it’s like, “Here’s a little piece of work in front of me and I’m just doing what I’m doing.” But as we can have more surface area and impact, good or bad, right? Because with an LLM, somebody who’s been really thoughtful about what they’re doing can have fairly complicated side effects that maybe have a big surface area. And I’m curious, is this something that you’ve had product side, the way that we have been on the engineering side, thinking about, how do we inculcate architecture thinking earlier and higher, and push down the way you think about systems and architecture further down the stack? It’s not just like a senior principal staff engineer consideration more. It’s like, “Can we assess a junior engineer for their capacity to think about our architecture?” It’s kind of hard but how do you?

Chris: Yeah, I don’t have my head wrapped around what does it look like to enter the job market at this stage? What does it look like to be an entry-level engineer or designer or PM? I think we need to think about it as an industry more deeply. I think a little bit about it, like the framework a lot of people will be familiar with is a T-shaped skill set. Right?

Allen: Mm-hmm.

Chris: You have the horizontal bar of like, “Hey, I’m kind of capable in all these different areas, but there’s maybe one or two areas I can go really deep and I’m expert in.” It is still very hard to become an expert in many things. Becoming an expert still takes a lot of work. However, becoming capable, that horizontal bar has gotten way easier. Obviously, I can become capable of creating prototypes with code. No question. I think goes the other way around, an engineer can probably become a capable PM in many ways just by having AI go back and forth and coach them on how to write a good spec. Right?

Allen: There’s a lot of roles, I mean, almost every role has some just kind of rote routine stuff that you just learn to have the discipline to, “What is the terminology you use for this?” Or you always ask these three questions and then actually follow up on them or whatever. And so LLMs have made a lot of that stuff that was never really the soul of many of these jobs, most of them anyway, it lowers the bar for that. But the stuff where it’s at the actual human portion of it, which of course we keep redefining the human portion to be whatever the LLMs are not good at, but from a product perspective, whatever it takes or rallying a team to feel hopeful that, or I don’t know, I’m-

Chris: Critical thinking.

Allen: Critical thinking. Yeah.

Chris: I think critical thinking has to go way up. Say you are whatever job you’re hiring the AI to help you with in your job, helping you to do some of these PM tasks, you still have to have this really critical lens because it’s like having a junior employee, that every time you hire, it gets onboarded, right? That’s literally how the AI works, is every time you make a call, all the history, all the context you’ve given it get loaded in for the first time. So, you are literally working with somebody who’s just being onboarded every time you chat.

Allen: That’s the underlying reality of the models. But one of the things I’ve been seeing people who are really effective at working with them, and we try to do this on our team, is also try to counteract that by making the context reusable and refining, like in Cursor our Cursor rules or our CloudMD. Or with the templates that we use for our, presumably if it was in a Zapier automation, then it would be the way that we put the prompting around the Zapier thing is definitely it doesn’t remember all the previous times. I can’t just literally say to it, “Okay, well next time do better.” But there is a form of next time do better if you improve the prompts or the examples that get ragged in or whatever. That’s a lot more work than just yelling at the model.

Chris: Totally. In the past, I was a big Claude Projects user because I wanted to create these reusable systems that would get smarter as I use them, but I found Claude Projects to be somewhat lacking, so I started to move all of that over to Cursor. So now, basically instead of Claude Projects, I’ve ported all of that over to Cursor. So, if I’m about to hop into an interview and I need to prepare for that, and I want to come up with a set of really good interview questions, I now have a Cursor role, essentially, that has all my context about me, the roles that I’m hiring for, that sort of thing, and helps me be prep for that without me having to manage distinct projects.

Allen: Yeah. And I’ve been hearing folks using Claude Code for that, too. But I think one thing I keep telling people from our experience, and I think I keep hearing this at Code, is that Claude Code is awesome and Cursor is awesome. And so if you’re like, “No, no, no, I’m sure that Claude Code is really the good one,” it’s like they’re both very useful tools. Don’t worry too much about FOMO if you’re using one and not the other.

Chris: Yeah, and I think what both of those tools are good at isn’t necessarily the fact that they’re development environments. Cursor is just a fork of the most popular development environment, right? What they’re really good at is context management. That’s what their core strength is. And so, that can be applied anywhere there’s written context. It doesn’t have to be code.

Allen: Yeah. Well, the context on one hand is the back and forth, like your conversation that you’re having with the agent, but all what would be code in a code base, but also can just be text documents is also the context, and then it can pull them in, you can at reference them. And so it’s a more flexible version of this Claude Projects concept. And so I think not everyone, but a lot of people are sleeping on the idea of having a Claude Code project or a Cursor project, even if you’re not really a coder, that the quote, unquote, “Code” is documents that you are working on.

Chris: Yeah, company strategy or something like that.

Allen: Exactly, exactly. And obviously MCPs that can access things like Clear Coda or Notion or Google Docs, or whatever, can help when you ask them like, “Hey, we have our company hiring values or whatever, pull that in.” And of course, you can copy and paste them, but hopefully over the next couple of years we get less and less having to copy and paste before we run our inference. You’ve touched on hiring, which is obviously one of the core ways that we build a successful company, like the difference in between a company that has early success and peters out, versus one that keeps scaling, is engaging and retaining really great people. You’ve helped scale Zapier from relatively small to one of the larger tech companies out there. What things have you learned in that process, hiring, especially you have this perspective of building a product or over that time? How has that been changing, if at all, in terms of what you’re looking for and how you assess people as the tools that you’re able to use and the tools that they’ll be using are now changing so quickly?

Chris: In terms of thinking through evaluating candidates and how they’re using AI tools, the thing I keep in mind is, look, we’re all beginners. We’re all pretty much at the beginning stage of this journey, and so I don’t expect folks to have figured out, but I think one of the things I’m always interested to explore is just what are the experiments they’ve tried? What are the things that maybe they’ve tried and failed to use? To use a couple buzzwords is like you have adoption, which is, “Hey, I used the tool to become more efficient in what I did. Same process, but I’m just more efficient.” Whereas transformation might be, “Hey, I’m actually doing the work totally differently.” And so I’m kind of curious to poke at examples like that, where have you tried just doing the work totally differently and maybe breaking some of the past roles? So, I think that’s definitely something to look for, because not only is that helpful in how you leverage AI, but I think adaptability is just a core PM trait that is super important. Can you adapt to the market? Can you adapt to feedback? Can you adapt to what your competitor is doing? And so looking for that adaptability is something that’s been one of the things I keep an eye out for.

Allen: Let me put a pin ‘cause that makes me want to ask two questions. I’ll put pin in the thing how the role is changing. But just on one other thing on hiring I like to ask, do you have any favorite interview questions? You’re talking to PMs, you’re trying to get assess this person, how do they think? Very difficult to do just with questions. Obviously, you want to have them in and do some product work with you and that, but before you get to that point, any favorite questions that you’re just like, “Oh, I love when I get a good answer to this,” or a huge yellow flag out of it?

Chris: Totally. My favorite question hands down is, “What’s the thing you’re most proud of? What’s the thing you delivered you’re most proud of?” Because I want to know what lights them up. The wording is important there because it’s not like, “What is the thing you did that was most impactful for your business?” Or, “What is the thing you are most proud of?” ‘Cause I want to know what gets them going and the motivation internally.

Allen: I like that question too, but talking to different people who ask that question, I’ve noticed some folks I’m more interested in hearing the thing the person is proud resembles the kind of work that they would be doing, and other people simply just want to see the magnitude of how excited they are. Are you looking for both or more one than the other?

Chris: Honestly, it’s probably more the magnitude of passion and motivation behind it, ‘cause I think when people are passionate and motivated, they’re willing to do whatever it takes to make that thing successful, which is a really important part of a PM’s role. A PM’s role isn’t well-define. A lot of the times, it’s fill the gaps to go make this product you’re building successful. That ownership mindset, which I think is tied to passion is what I’m looking for.

Allen: For sure. I appreciate that. So let’s then follow through then on this thread of PM role famously is not very well-defined in between different organizations of different definitions. And then the definitions are often not super consistent in between in an individual PM or group PM. Depending on how your PM or is structured, you will have just quite different literal things that these people are doing based on their strengths and weakness, and based on strengths and weaknesses of the people around them, and based on the immediate product that they’re working on. How have you been thinking about the changes that have been coming in as it’s not just AI, it seems like there’s more to it than just AI that’s been changing the way that product teams are working? But if you go in the Bay Area and you talk to a lot of startups now, which of course there’s always Bay Area startups that will say ridiculous things that don’t pan out, but there’s a lot of Bay Area startups now that are saying, “Oh, well product managers are dead. Everybody’s just a product engineer and the leaders are the strongest product engineers, and everyone’s writing code, and everyone’s influencing product, and everyone’s talking to customers.” But then you can also talk to skilled tech companies who are saying, “Oh, well because of AI, product managers are more important. And it’s actually ‘cause the product manager can now do actual prototyping, and they can be more involved on more surfaces of the product, and they can scale better. And so we actually have a more product management-centric.” Either way, both kind of arguments are threatening the traditional triad. And I guess you and I are sort of biases people who are product people. We want to be like, “But product management is important.” But what is your initial take so far on how that role has been changing at Zapier, if it even is yet?

Chris: I think it’s helpful to distinguish between the role and the capability. It feels very obvious to me that the capability isn’t going anywhere. The idea that you have to deeply understand your customer, make a bunch of hard trade-offs and prioritization calls, think deeply about the strategy that you’re building towards, that is more present than ever. Because what is going to differentiate you from anyone else isn’t that you can write code or that you can write code faster, ‘cause it turns out everybody can write code now and everybody can write it faster. So, I think the thing that really differentiates is going to be can you think deeply about a product strategy that is going to win? And so that capability isn’t going to go anywhere. Now, if that capability is combined with other roles, like maybe a designer who can deeply think about strategy or an engineer who can deeply think about strategy, then honestly the less handoffs you have, the faster you’re going to be able to move and the easier it’s going to be. And so, I do think there is sort of a collapsing of roles. And if our capability bar has all raised, we’re able to be capable, not experts in all the things, we’re going to be able to move a lot quicker. That’s how the framework I think about it, is what are the capabilities you need on a team and how are those encompassed, even if it means one person maybe takes on multiple roles?

Allen: That’s the thing a lot of people are sort of speculating, is maybe even weak projecting planning for is role merging. I haven’t heard many, and if you have a hot take I’ll take it, but also I’m not insisting you have a hot take, but do you have a take on how in 5 years we might, in the way that it emerged, I don’t know, maybe 10 years ago, to typically have this triad system? Which originally was someone’s hot take of like, “Oh, you should have a product leader and design leader, an engineering leader, and they try to make decisions, and there’s a bunch of things that are good about that structure and the division of labor.” Do you have an instinct about in five years how we might be breaking up the roles and any changes to how we refer to them? Or is it too early to have opinion about that at this stage?

Chris: What seems to be true is that going back, I think a few years ago, one of the founders of Zapier, Mike Knoop, was fond of saying he would want to walk into a room and not know who in the room was the designer or the engineering manager or the product manager. And the principle behind that was they all deeply care about the product they’re building and they all have a shared goal. And so, I think that’s sort of the heart of what’s most important, is that you’re going to have these teams of people that are willing to flex into different areas, and they have a shared goal, a common purpose, and they’re all fighting for what’s right for the customer. They’re all fighting for, “What should we build that is going to create more value for customers? And so, if that means in some organizations it makes sense to just get rid of role titles, that’s a great experiment. I would try that. I don’t think that’s the way it has to be, though. I think the more important thing is that you have these teams that are rallied around a goal that serves the needs of customers.

Allen: As a contributor, I love the idea of that, of just, “We’re all just trying to make the best product and how much value it provides to the customers is our success, so let’s just rally towards that and not worry about titles.” That sounds great to me as a generalist, but as a manager, the idea of trying to hold someone accountable for some part of that not working without any outline of… Everything being shared ownership, infamously, can devolve into no one in particular feeling like they’re the one, “We have no DRI or whatever.”

Chris: Totally.

Allen: So that’s always the challenge I think with that, I don’t know.

Chris: Yeah, at Zapier, we have this saying of, “Alignment is greater than autonomy.” And we actually don’t even really encourage the word autonomy.

Allen: Interesting.

Chris: We talk more about empowerment. And so, autonomy has this connotation of like, “Hey, I’m just going to go it alone. Hey, Manager, you tell me what to do and get out of my way and I’m just going to go do that thing.”

Allen: Delegation.

Chris: Whereas we talk a lot about, actually, alignment is really important. You should be syncing up with, if it’s a manager, reporting relationship, being in constant touch with them on, “Here’s what I’m working on,” rather than this sort of management principle that I think is out there of, “Hire great people and get out of their way.” We sort of have a different approach, which is we want managers to be in the details, hands-on, not sort of empty suits, to be hyperbolic. Yeah.

Allen: No, that’s interesting. Let’s dig into that a little, ‘cause for folks who don’t know, or we maybe mentioned it at the top of the show, but Zapier has this very long-standing remote set up with defenders from Wisconsin or something somewhere-

Chris: Missouri. Yeah.

Allen: Missouri. Right. So not the Bay Area. And so then this intentional, “We’re not the stereotypical all in the office in Silicon Valley or San Francisco thing.” And the very common thing that comes out of a remote-first culture is a move towards this asynchronous decision-making, where you have the decisions try to not just be like a bunch of people get into a meeting and then an answer comes out, but people are making decisions that way. So, I’d like to triangulate those two things, the thing you just said about autonomy versus alignment, and then that asynchronous decision-making. But you want to describe a little bit from your own perspective rather than just me as an outsider looking in?

Chris: I think one of the things you can get bogged down in with the, “Alignment is greater than autonomy,” is decision-making, and how do you make decisions fast if you’re having to check in with the next level or that sort of thing?

Allen: Exactly.

Chris: And one of the principles that I think is important here is this concept of, “I intend to.” So, when you have a decision, there’s two ways you can frame it. You can say, “Should we do X or Y?” And it’s a question. And then the person who’s reading it, maybe your manager or the CEO thinks, “Oh, this person doesn’t know whether they should do X or Y.”

Allen: “Now I need to maybe research it or consider.”

Chris: Yeah. Or, “Are they the right person if they don’t know the answer to X or Y?” So, framing it as a question kind of gets you off to the wrong foot, whereas if you say, “Hey, I intend to do X. here’s why I have conviction behind X. We also considered Y, and here’s why we’re not going to do that.” Execs or your manager can still raise their hand and say, “Hey, stop. I think you should reconsider.” They will always know that’s their prerogative, but you’re not waiting for them to do that. You are-

Allen: Yeah, and the formative book on this is called Turn the Ship Around, David Marquet. And so that’s this idea of try to build people that feel like they can propose things instead of just being like, “All right, well tell me what to do, Boss.” I think a lot of people’s instinct when they hear, “Okay, we have an asynchronous organization and therefore decisions are getting made in open, and therefore anyone can chime in on any decision, and now you’re talking about alignment.” And yeah, alignment is good in theory, of course we want to be aligned, we all want to be pulling the same direction, but getting everyone to agree and turning into democracy, and then six months to decide what we’re going to do. So it sounds like that’s that idea of trying to give someone, not necessarily just delegate and, “Do whatever you want,” but giving them a responsibility. And then their default operating mode, and tell me if I’m reflecting back what you’re saying correctly, is to then they’ve been given responsibility and they’re saying, “I would like to fulfill that responsibility by turning the ship around by shipping this next week,” even though there’s still some remaining bugs or whatever the thing they’re going to propose. And then the discussion is not, “Hey, should we ship? When should we ship?” It’s like, “The person who’s kind of leading the charge on this is proposing that we ship. Are we going to get in the way of that?” Or I assume the default that everyone kind of wants to get to is try to get the person who’s proposing the thing to be correct or be able to do that thing, but then we’re going to kind of distribute a sanity check? Is that the kind of-

Chris: Yeah, I think you got it. So we call it responsible decision making. You’re in the position, you own that decision, make the decision, but be responsible by letting people know, “Hey, I’ve made this decision and this is what we’re going to go do.” A helpful heuristic I’ve shared with people or that I think about for myself is, “Hey, if I make this decision on my own and it totally backfires, what will be the result of that? Will it come back and bite me? Should I have done more due diligence? Should I have gotten a couple more people on board?” Or will that just be like, “Oh, you tried a thing and it’s all good, try again”? So, I think that can be a helpful heuristic, but you got to be careful with that, of not getting into cover your butt mode because I think that is what slows organizations down.

Allen: There’s two pieces there. So one, is around mistakes. And so some organizations, especially really transparent ones, can fall into mistakes being bad enough that then people try harder to not make mistakes than they try to achieve things, they worry more about the downside than the upside. Is there any tactics or approaches that you take to kind of avoid that, ‘cause can be obviously just kind of grind everything into bureaucracy?

Chris: Well, one that happened this week, we had just come back from our leadership offsite and we’d been talking a little bit about, “Hey, how can we encourage more risk taking?” And the answer to that was like, “Well, we need to talk about our failures more so that people recognize we are taking risks in the organization.” And one of our data scientists on our machine learning team said, “Hey, why don’t we start this Fail Fast Slack channel?” And he went around to basically a bunch of directors and executives and said, “I want you to populate this channel first before I share it broadly.”

Allen: Nice.

Chris: And then he went and shared it with the whole, we call it the Build Organization, engineer, product and design. And so, it was just something that happened this week, ‘cause that it is very much like a Zapier culture thing of like, “Hey, I have an idea. Go start the Slack channel, get a bunch of people to contribute to it,” and that’s the way you start a new habit.

Allen: Did you contribute to Fail?

Chris: I did contribute to Fail. Several months ago, we were planning for our big user conference, ZapConnect, and we were talking about, “What is the big launch moment going to be?” And I had this really strong conviction that what we needed to do was launch, what we called at that point, a unified building experience. We started to create all these different products across the suite at Zapier. And my thought, my vision for that launch moment was, “We should bring it all together in just one big builder, and that would be awesome for customers.” And flicking back on it, I am very glad we didn’t sink all of those engineering resources into it, and instead the team sort of started to get very specific about, “Well, what parts need to be unified and why do they need to be unified?” And so, we ended up with a bunch of smaller decision points that maybe came from that, but if it had been purely up to me, we probably would’ve built the wrong thing. So yeah, that was the fail that I shared in that channel.

Allen: Yeah, I love that. I think there’s a lot of value and I try to do as much as I can to err on the side of failing visibly. Small organization, so it’s more like my co-founder knows about all my failures, but I’ll even try to just write about, “Here’s a thing that I did and what went wrong,” because I think it’s just a good… It certainly helped me when I was getting going, and still does hearing other people’s failures on that stuff. One thread I wanted to pull on before we run out of time, we’ve got a couple other things, but ‘cause you mentioned the editor and the product shape of Zapier, which is, again, people are familiar, I think almost everyone is familiar with the core, “Okay, we’re building an automation and I’ve got these points that can connect to each other, and it can fork and how that works.” More than a decade in, there’s a lot of strengths and advantages Zapier has, but we’re in this new generation where there’s n8n and Gumloop and all these other people who’ve ranged from a principle to just a vibe coded attempt to try to compete in that space. From a product perspective, do you see the wealth of integrations, like Zapier has more integrations than probably any product ever? Do you see that as the kind of crown jewel, the biggest differentiator piece in between all the various other people clamoring at trying to compete? Or is there something philosophical or strategic that you see it, Zapier is like, “Well, this is the specific way that we see it, which isn’t the way everyone else necessarily sees it, but we think of Zapier’s angle as being kind of oriented this way”?

Chris: Interesting question. So definitely in the past we’ve thought of our competitive advantages being sort of twofold. One, having the biggest set of integrations for work, and that is still true, and we still continue to invest in that. The other part is being the ease of use. We’ve tried to make Zapier the easiest integration platform on the planet. And we think those two things may be less durable with AI. If you can build integrations rapidly and if you can build integrations just by chatting back and forth, maybe that is less durable. I think we’ve been surprised to see how durable it has been over the last couple of years. But as part of that, we actually called the code red and we said, “Hey, if anybody is going to the business, let it be us.” Right? And that’s one of the things I love about Zapier, and one of the things that I think is really important to think about as a PM, is not falling into that trap of like, “Well, this is the product I own and this is the area I own.” Always have some brain capacity towards, “What if I reinvented this whole thing?” And obviously, you’d drive your engineering team mad if you were constantly doing that, but you have that sort of outlook. And so Agents by Zapier is sort of the outcome, or is clearly the outcome of that, “Hey, let’s reinvent Zapier.” It was actually our take on, “What if Zapier was built today from the ground up, what would that product look like?” Going forward, two of the things we see sort of being clear advantages. One is, the rich data source. I would say not only do we have the largest integration platform on the planet, we also have the largest library of working automations, both AI and non-AI. And we can use that to help people understand what to build or how to build it. So, I think that’s a pretty key piece. And then going forward, we have this strong belief that what AI does is it puts the hands… Sorry. What AI does, is it puts in the hands of the people closest to the problem, the tools to solve that problem. So, you don’t have to wait for your bottle necked IT team to finish Project X. You can, as marketer or HR coordinator, just go solve that problem for yourself. And so, we have this core belief that we should be building tools that make it easy for anyone in the organization to automate with AI, which I think is novel. If you look at the competition, that is not quite the way that other organizations look at it. They’re either, “Hey, we’re going to wall this off and only it can use it,” or they don’t have the governance layer, so there’s a lot of startups that are maybe easy to use, but they don’t have the governance layer that makes it easy for an IT team to deploy.

Allen: Right. They just can have the mental model of, if you are a little startup, you can just be like, “Sure, this automation tool has a complete read and write access to every single one of our systems, to Slack and our HR system, and that’s fine at a certain scale.”

Chris: Yeah. It’s easy but it’s not governed.

Allen: Right. And so Zapier has the tools to allow some of amount of delegation that someone at IT can say, “All right, HR person, you can do HR stuff. I don’t know anything about HR, I’m just an IT person, but I see that you need access to this stuff, so go do that.” Actually, this is a technical question, getting in the weeds slightly. So, one of the core challenges in building LLM power software is with Simon Willison calls the deadly triad. You’re familiar with this. Right?

Chris: Yep.

Allen: Where it’s like if you give an LLM secret information and you give it input from the outside world, which could be malicious, and you give it access to the internet, then we don’t know yet of a way to make it 100% sure that it won’t accidentally take the secret information and put it on the internet. You’re talking about governance, and obviously the simple part of governor, it’s not simple to implement, but the maybe obvious part of governance is to make sure that certain users can only access certain data, and that the data rights that they have in their systems are reflected in Zapier. But is there any awareness at a product level of that deadly triad or the idea of like, “Hey, this is untrusted input, this is LLM, this is network access,” or is that kind of more a user education piece?

Chris: Yeah, no, we definitely have our sights on building that into the product. Right now, the main way you can do that is through app access control, who can send what data where, and being able to control at the action level who can do what. However, there are some things coming in the next months here, both AI guardrails inside of for the builders. So I think of this M2 components. You need guardrails so that the folks building agents or AI automation can build the guardrails right into the thing they’re building. And then you also need sort of the AI guardrails for governance. So, admin, who isn’t building all of the stuff in their account, can go and see, “Oh yeah, where is this…” We call it the lethal trifecta. “Where is this lethal trifecta maybe coming into play?” And they can monitor or make changes to that integration. So having both top-level observability for admins and then the ability for builders to build in the appropriate guardrails along the way.

Allen: Yeah, that makes sense.

Chris: Coming soon. Coming soon.

Allen: Yeah. We’re now a couple of years into those of us who are builders getting used to the mental model, and it’s starting to be intuitive like, “Oh, of course, you don’t want to have a lethal trifecta here, so we wouldn’t do this or do that.” But now, the next generation is platforms, like automation platforms, and making it so now anyone can build. Sounds great, but now we have a much higher bar any software engineer can think through, is more habituated all day, every day, thinking about the implications of what is their code doing when they’re not looking. And so it’s an interesting challenge, I think, to try and get that at the product level that someone in HR or whatever can have that to the degree that that’s possible.

Chris: Yeah. One of the core beliefs we’ve held for many, many years is for every version of a developer tool that exists out there, there should be become a no-code equivalent, possibly on Zapier. And so security, obviously, is something that engineers think about a lot. What is the no-code equivalent that all of these non-engineer builders are going to need to have access to?

Allen: Debugging, automation, evals, monitoring. Last question as we come close to time. Obviously, the growth has been, you’ve seen orders of magnitude at Zapier, and you’ve obviously, presumably, learned a lot doing that. You came in as the first PM and now you’re having an entire team of PMs, and things there’s been successes and challenges and all that. What’s a surprising or maybe hard-won lesson that comes to mind when you think of having gone through that path? Something that maybe you could send in a bottle to Geo a decade ago or to the next Geo who is at the first PM at their startup that they’re hoping to 10x, 100x, 1,000x as they build it?

Chris: This one’s obvious to me. It’s basically that the things you take for granted when you’re 40 people, you don’t get for free when you’re 100 people or 800 people. If you have a culture that is very data-driven or customer-obsessed, and PMs are automatically hopping onto calls three times a week with customers, as the organization scales, that does not scale for free. The things you were good at when you were 40 are not the things you’re going to be good at when you’re 100. You have to go back and invest in those things. If I could tell my past self anything, I would be that, and to go proactively invest in those things that I care most deeply about retaining in the culture so you don’t have to go back and rebuild them.

Allen: Any top ones that you would pick out as the ones that like, “Oh, this is the couple of things that we needed to make sure we retained”?

Chris: Yeah, I think probably the top one was when I got hired into Zapier, I had to write a SQL statement live in the interview. And I think that is maybe a skill that we did not screen for as deeply as we scaled, “Would PMs have that sort of technical ability to go query the data themselves?” And so, that’s an area where I wish I had either hired for that or invested in the capability for folks very early on.

Allen: Awesome. Well, I love that. Thank you so much, Geo, for taking the time. Where can people go to find more and learn more about you and your work?

Chris: Yeah, on LinkedIn, I’m Chris Geoghegan. That’s probably the place to reach out. Yeah, find me there.

Allen: Nice. We’ll put a link to that in the show notes. Thanks for being on the show. It Shipped That Way is brought to you by Forestwalk Labs and Steamclock Software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback, follow us on social media, or rate the show by going to itshipped.fm/contact. Until next time, keep shipping.