Check out the conversation on Apple, Spotify, and YouTube.
Why AI fluency is now the standard expectation (01:43)
Aakash: I’ve been trying to figure out what AI fluency actually means for PMs inside of companies. How do product leaders and CEOs measure you? I could think of no better person than Wade. Wade published what I think was the first AI fluency rubric online, and many companies have modeled it since. Since then, Zapier has updated their thinking. How did they update it? What actually matters day to day? How is Wade actually grading employees?
In today’s episode, he’s not just going to walk through his rubric theoretically. We’ll actually show you some AI behaviors, and Wade will give his take on whether each one is transformative or unacceptable. He’ll also talk about how these expectations have changed over time, so that you can meet the bar at your company or exceed it. Wade, thanks for being on the podcast.
Wade: Yeah, thanks for having me.
How Zapier measures AI fluency (02:39)
Aakash: I have been dying to do this recording. I think we’ve rescheduled a few times, because I think you are the world’s best person to talk to us about AI fluency. How do you measure AI fluency at Zapier?
Wade: It might be most helpful to just show it. We have an AI fluency rubric. This one, published March 31st, 2026, is our updated AI fluency bar at Zapier. So this is the V2. You can see here we basically break things down into four categories. You only see three on the screen here. Capable, adaptive, and transformative. We also have an unacceptable one, which is simply the bar that we choose not to hire at.
Obviously, any company can tweak and tune these to fit their needs. We felt it was really helpful for us to name some of the skills and behaviors that help people stand out in terms of their AI fluency. This is a product podcast, so let’s zoom down here to the product one. I’ll be the first to share that this is the V2 we’ve shared externally, but we’ve even updated some of these things internally since. This space moves fast, and you have to constantly be tuning and tweaking what you’re doing. So you can see here some of the characteristics that make someone unacceptable, capable, adaptive, and transformative at this work.
In 2026, if you’re using AI to do simple tasks like summarization, writing, looking up information, or generating basic PRDs, that’s table stakes for most companies at this point in time. We’re usually looking for somebody that’s operating at a meaningfully higher level.
We want folks that have a really structured approach for generating specs and prototypes, things they’re going to reuse and refine across projects. We want people using it to tap into user insights and quant, being able to operate at a scale that was not possible before with just humans. You should be able to generate tons of different working solutions very rapidly. Those are the types of things that end up being table stakes for these roles.
If you’re really trying to push the needle, you’re starting to stretch into other types of roles. I think PMs are well suited to become generalist super builders inside of an organization. That means you can tap into whole new skills, whether that’s data analysis, marketing skill sets, or sales skill sets. PMs are usually already decent at some of these things, but now you can get to 80 or 90% as good, and it makes you way more valuable to be able to work up and down the life cycle of a project.
As you move up the stack, a lot of this starts to be about systems building. This is the really critical piece. You’re not just thinking about how this feature is going to work. You’re thinking about how to build a pipeline of agents that takes in customer feedback, generates specs, starts to prototype solutions, and ships full features. If you’ve heard of things like software factories, I think this is where PMs start to have a lot of value. You can start to think about how we build the system that builds the ultimate system. That’s where you get into the transformative category, where it’s like, wow, we’ve actually built a product factory here, and we’re changing the way product works at a fundamental level.
So these are the four stages or phases that we’ve put into the rubric. But like I said, you can adapt these to your company. Not everyone has the same standards as us. Maybe you’re not as far along, so you have a different state. Or maybe you’re even more advanced than us, and you’re saying, actually, we need more people in these categories to really push the envelope.
Where the bell curve should sit for a PM team (06:53)
Aakash: So what is the distribution that you want to see at Zapier? Where should the ratings fall for your product crew?
Wade: We’re generally looking for folks that have the bulk of their skill set here, in adaptive. That doesn’t mean they don’t have places where there are gaps, like all of us do. There’s so much new stuff happening every day, new techniques and tactics that people haven’t used. So there are definitely people that are in the capable bucket in places. And then we usually want to see somebody bringing one example of something they’ve done in transformative.
Most people are not hanging out at transformative every day. In fact, it’s probably not helpful to be there 100% of the time, because if you are, you’re not actually getting work done. You’re constantly tweaking your systems and your way of working. You’re probably hitting it on occasion. For our PM org, we’re hanging out in adaptive most of the time and occasionally running experiments to push the envelope.
So that’s where I’d say our bell curve sits. Adaptive is the fat middle of the curve, and we have some folks on either side. But I wouldn’t label it as, you as a person are this. It’s more like, most of the time I’m this, sometimes I’ve got some holes here, and sometimes I’ve got some things up here. That’s what it looks like more often than not.
What a transformative half looks like (08:17)
Aakash: That’s an interesting way to frame it, that maybe you don’t actually want to be transformative, because you wouldn’t have time to do work. Do you do quarters or halves when you give performance reviews?
Wade: Our performance reviews are in halves.
Aakash: So if you can recall a transformative half from a PM, what did that look like?
Wade: I remember at the tail end of last year, we had all these new models come out. The latest Opus series, the latest GPT series, the latest Gemini series all came out, and the reasoning power was so much better than before. You went from these AIs writing code alongside engineers to, over the winter break, basically everyone saying, I’m not writing any code anymore. I’m very rarely writing code anymore.
Alongside that, a thing we started to see a lot of folks doing, both online and even inside of Zapier, was building these second brains. If you haven’t done this, it’s a pretty simple thing. At least the way it started, you’d create a bunch of markdown files that say, here are my goals, here’s the way I want you to work with me, here’s a project I’m working on. Just a bunch of context. Then you’d boot up a coding agent, and the coding agent would have access to all that context to go build projects with. Maybe you have your design system in there. Maybe you have your company strategy in there. Maybe you have coaching files in there where you’re like, help me be better at this.
One of our product leaders said, you know what, this second brain concept is pretty interesting, but it’s limited if those are individual skills. This should be a company brain. So he took it upon himself to build out the V1 of a company brain. He put together all this context that would help anyone in the company, but he started with a lot of the product leaders and product managers and said, we’re going to get everybody using this company brain to go do the work.
You could feel this phase shift happen, where it was not just him, but every product person at Zapier kind of got a jetpack put on their back when he launched this system. That’s a great example of a moment in time where the models had this lurch forward in capabilities, and a product leader said, okay, with these new capabilities, I can lurch forward the way we work as well.
Grading a PRD written with AI (13:22)
Aakash: All right. I want to try some PM artifacts. I’ve gathered some that I created this morning, and I want to put you on the spot. The final rating doesn’t matter as much as how a CEO looks at PM work products, or how a PM inside a company is being graded on this.
So let’s start here. What I thought of was, what if Zapier had an IDE harness for Claude Code? Who knows if this is a good idea at all. That’s why I wrote a PRD on it, and I want to walk you through this PRD as if I were a PM. I’d love to hear your thought process as you’re looking at it.
Obviously I’ve used ChatGPT here, and I’ve given it a few prompts. So I have iterated on it. It’s not my first draft. I’ve included the overview. I said it’s important for automation workflows, and we’re uniquely positioned to solve this because of our thousands of integrations and our deep knowledge about how workflows work. So we combine Claude Code with Zapier’s automation platform. That’s my pitch here.
I feel like the problem is that you might write prompts in Claude Code, configure apps, and deploy, and it’s all fragmented. Claude Code can make mistakes with the API. So what I wanted to do was create a better environment for building these Zapier automations. The target is software engineers and founders. Specifically, as a developer using Claude Code, I want to build and test Zapier automations without constantly switching. That’s the problem we’re solving.
We have this proposed solution where users can interact with Claude Code. A workflow might be that they have this automation, Claude can easily help them build it, and we can test it. I’ve come up with some of the key features, and I won’t go through too much more of the detail, but it’ll have AI slop detection. I’ve come up with a bit of an MVP. For metrics that I think leadership might care about, the number of workflows successfully deployed through the IDE is our north star metric. Of course, developers might prefer Claude Code directly, but I don’t think there’s a huge build cost. My vision is Claude writes the automation, and Zapier helps make sure it actually works.
So I wrote this with AI. What do you think of my work?
Wade: It’s interesting to think about how you would evaluate this, because part of your prompt to me was how this grades on AI fluency, but there’s also a part of this that’s just how you grade the overall product thinking happening here.
The first thing I notice is that I think this is a pretty interesting idea. The product intuition is pretty savvy here. It recognizes that there’s this new way of building automations, and there’s some value in having the Zapier connector library hooked up to Claude or Claude Code to help build. One thing I didn’t see you say here, and maybe it was in there because I couldn’t read quite as fast as you were going through it, is that there’s a lot of value in deploying these things and running them on Zapier, because Zapier can run them in a deterministic manner. That gets you better costs, better accuracy, all that sort of thing. So there’s a lot in here that I like.
Where I think an AI-pilled, AI maximalist product manager could go further is in a couple of dimensions. One, why stop at the PRD? There’s an opportunity to build out the first prototype of what this thing looks like. Fire up your favorite coding agent of choice and start to see what you can prototype and build. The point here is not for product managers to build production-level code. The point is that seeing is believing, and it’s a lot easier now for a product manager to bring some of these ideas to life. A picture says a thousand words. A prototype is that times 10. So that would be one dimension where I wish this could be stronger, and an AI-pilled person would probably do something impressive there.
The second dimension where I would strengthen this, and you could do this in a non-AI way, but I would certainly be using AI to help me, is to figure out where our customer evidence is behind this. However you can find customer evidence, I would try to find it. I would look through Zapier’s Gong recordings or Zendesk tickets. I would sift through subreddits or LinkedIn or X and find where people are complaining about stuff like this or expressing a desire for a thing like this, to figure out whether I’m getting the shape of this product right.
Like I said, you could do a lot of this without AI, but AI is going to make it a lot easier to sift through a mountain of data sources that you just wouldn’t have been able to get through in a short period of time in the past. That’s a second thing you could do to beef up the evidence that you’re heading in the right direction. I think this is a good idea. Are our customers going to think it’s a good idea? What is the pain point they really care about?
You posed the question of whether Claude could just do some of this. So there’s a question of where the unique value is that Zapier brings to the table on top of it. Sifting through a lot of those customer details will start to strengthen that intuition around, ah, there is something here that is uniquely Zapier’s to own and provide value on top of.
Those are the two obvious things I would encourage somebody to strengthen, and I don’t think either of them takes that much more time. In the past, a PM would have said, well, I can’t build a prototype, so I just can’t do it. Or with the customer evidence, it’s like, I can do that, but before I spend a couple of weeks doing it, I want to get some buy-in that this is even directionally interesting. Nowadays, that buy-in step can happen way later. You can go so much farther. By the time you’re asking me or somebody else in the company to put some oomph behind it, you’ve built a mountain of evidence that makes it a lot more likely I’m going to say, yes, let’s go for it. Or maybe you’ve already figured out yourself that this is a bad idea. You thought your intuition was good, you put some effort into it, and you just can’t find something you get super excited about. So you can shelve it.
That’s where I think an AI-powered PM has these superpowers that you didn’t have in the past.
Aakash: Did you all realize you were getting a masterclass in how to write good PM documents? It’s not just AI fluency. Wade just brought up a couple of important points about how it’s not just the PRD. What I tried to do was engineer this document so you would rate it as capable in 2024, but almost adaptive or unacceptable in 2026. Do you feel like that’s fair?
Wade: I think so. If someone came to me with this in 2026, it would feel a little old-fashioned as an answer. I’d be like, yeah, some good product intuition, some good thinking, but gosh, you could have gone a lot further. I’ll tell you what my instinct would be. My instinct would be, just give me the doc and I’ll start doing some of these things. I’ll take your PRD, throw it into Cursor, say build this for me, and see what happens.
Here’s an interesting rule of thumb. In your discipline, you probably want to be farther ahead than your CEO is. I would say my AI fluency is probably adaptive in most places. But what it means for me to be AI fluent in the PM job, the marketing job, or the engineering job, I should be behind you. If there are things I know that you don’t know, that’s probably not a great signal. You should be further ahead than me, because you wake up and breathe this stuff all day, every day. So if I’m spotting things that are obvious to me and not to you, I’m like, ooh, that makes me nervous. How do we go fix that?
Why AI fluency and product thinking can’t be separated (23:12)
Aakash: Okay, so I think we’re aligned there. One other thing I would pull out as an insight for everybody listening is that it’s not easy to separate AI fluency and good product thinking. They almost come together in this era. To do good product thinking, you need to have gone and looked at the Gong calls. You need to have looked at the Reddit comments. Now AI can help filter half of that for you. So you need to put those two skills together.
Wade: Yes. We were talking before the call about AI slop a little bit. There is a version of this where you could do all the things I said. Take this PRD, slap it into a coding agent, have it build the first prototype. You could have AI do all of those steps, but the output you come away with could be pretty mediocre and unexciting.
This is where the human part, what a lot of people call taste or judgment or whatever term we’re using these days, really does matter. There is still something to be said about understanding the customer problem and having some intuition around how to solve those problems. If you combine those, you get excellence. But if you let AI do everything, you’re probably going to get mediocrity. You’re going to get what people call AI slop. You’re going to look at it and go, hmm, I’m not excited about this.
Slop cannon or turbo brain (24:43)
Aakash: Speaking of slop, I want to know your take on this framework from Dan Hockenmaier. If you don’t have good judgment and you use AI, you can become a slop cannon. But if you have good judgment and you use AI, you can become a turbo brain. Is this the right way to think about it?
Wade: It’s definitely funny and evocative. I think it’s a reasonable framework, honestly. I can’t think of an objection to it. I can think of folks I’ve worked with who are using AI and have exceptional judgment, and watching them work, you’re like, wow, this is incredible. It’s almost like you’re witnessing a new species being invented.
I’ve also seen folks that use AI a lot but do not have good judgment. There’s this old saying from the social media wars around disinformation, that a lie can go around the world two times before the truth gets out of bed. I feel like the folks without good judgment who use AI are a little like that. They can generate so much stuff that it takes so much effort just to swat it away and say, that’s not what I’m looking for, that’s not what I’m looking for. So it actually ends up being in some ways more challenging to work with those folks than the bottom left corner, the people who don’t have good judgment and don’t use AI. At least they’re quiet, right?
It’s an interesting framework. I’d probably have to think a bit more about some of the pros and cons, but on the surface, I feel this.
How to share AI-assisted work without passing off slop (26:26)
Aakash: There’s a reason it probably went semi-viral. On my own team, I find that when somebody sends me something that falls in the slop category, they basically didn’t exercise the judgment on their own, and they’re passing that responsibility to me. They’re saying, oh, this might be good, can you judge it? That’s kind of the opposite of what you want to do when you’re moving up a corporate hierarchy. You want to give people filtered information that is quality, versus, what do you think of this?
Wade: Yeah. I think there’s almost some etiquette the workplace is trying to iron out around this right now. I talk to a lot of folks dealing with the rise of slop internally.
Some of the things we’re starting to do is be honest upfront about what level of effort has gone into something. When I share a document, I’ll say, hey, obviously I’ve used AI to help draft this. I’ve done a quick skim through, so I’ve removed the most obviously bad stuff, but maybe I haven’t given it a thorough once-over. I want to share anyway because speed is important now, and I’ve gotten some ideas out there that I want you to take a look at. That might be one thing I’ll do. Or I might say, you know what, I think this is excellent. I stand by every statement. Every sentence has been impeccably reviewed by me.
So we have these stages when we’re sharing things, to help the reader understand what level of effort has been put in. I do think it’s okay at times to share what might be pure AI slop, but you’ve got to set the expectation for the reader about the quality level they should expect. I think that helps. I’m not sure we’ve totally perfected this, to be honest. But the place that is really painful is when you try to pass something off as really good, and the reader can quickly tell you put no effort into it. Now you’re making me do the task. You should have just asked me to do the job, versus trying to pass it off as your own.
Aakash: One thing that surprised me so far in this podcast, that I definitely wasn’t expecting coming in, is that it sounds like it’s okay to use some AI. It’s okay to have a little bit of slop if you’re going for speed. It’s okay to not always be transformative with AI, as long as you’re upfront and transparent about it.
Wade: Yeah, I think so. These are tools. A lot of it depends on the context. If you’re putting out an external product for your customers, there’s a different standard for that versus a quick and dirty task over here, where the level of quality required is different. A lot of it comes down to what’s on the right-hand side of Dan’s framework. Has good judgment. Judgment is kind of the ultimate in a lot of ways. It’s one of the main critical skills right now in the AI era. You’ve got to turn your brain on. If your brain is on, you’re probably going to find yourself in a good camp. If you turn your brain off, you’re probably going to find yourself struggling.
Grading a prototype-first PRD with customer evidence (29:55)
Aakash: Awesome. Let’s go review another work product I’ve prepared. I think we can safely say we would not give the last one a very high rating in 2026. Let’s check out another one I worked on before this. I’m nervous now that it might get a low rating, but that’s the point.
I decided to use the same feature, so it’s easier for us to compare. Again, it’s a Zapier harness for Claude Code. I predicted we should probably start with a prototype, so I came up with a prototype here. I tried to create some Zapier branding, even. My pitch is, your agent has the connections, it just can’t reach them. Since we hold authenticated access to 8,000-plus apps, I think even more now, what would it look like if a coding agent could actually use them?
The whole idea is we just install Zapier into Claude and run Zapier connect. We could approve a Slack message. We start to get this exposed surface area. We could even send out things like a Jira delete issue. All of that happens incredibly fast. The whole point is that it found six connections, and three were selected. It looked at 14 custom Jira fields. It showed us which tools across our cap were preapproved. It gave a preview of the payload.
There was this thing I built in here that happened really fast, where the Jira delete was refused. So what did we do then, and why? It was a destructive action, so it was flagged. That’s one of the things our harness would be able to add that a normal Claude Code wouldn’t, because we have a lot of enterprise customers. We could even replay it in Zapier history. So the whole idea is that this harness would be much more powerful.
This is where I started my PRD, so I’m going to keep going and explain the PRD behind it, and then let’s get your feedback. This time the PRD is a markdown file instead of just a chat window. We just went through the prototype. The whole idea is you install and connect once. It has a policy file, and you just saw it deny an action. The loop we’re talking about unlocking is, let’s say there’s a Sentry issue. It can go read it. It can go edit it. It can create the Jira ticket. It can post a Slack message. All of that can happen using Zapier’s connections and Zapier’s policies. So somebody who is super technical can build it, or somebody who is not technical.
We already went through what this is deliberately proving and the hypothesis, so I won’t talk about it too much, but I’ve written it in a slightly tighter way this time. I also tried to use more evidence, since I predicted we needed it. I’ve added in some Gong information. From 47 calls from February to July, I found that agent tooling came up unprompted in 34 of those 47 calls. That’s just an observation. On Zendesk, we had 312 tickets tagged MCP or AI agent. In our community Discord, there were over 1,800 posts mentioning MCP. With our design partners, we had nine interviews where they had built an MCP server.
What did all this information show? It showed the bottleneck is permission, not connection. It also showed that too many tools make agents worse, and users already know it, and that there is a real tail.
My hypothesis for the little six-design-partner pilot I ran was that devs will let an agent perform writes to production systems if the gate is good. I wasn’t sure if this was going to be true, and I did find evidence to support it. Five of six enabled at least one preapproved write. I went through several other hypotheses and ultimately looked at strategic fit. I came up with this idea that we do a Claude plugin, and this plugin is really a harness, not a connector. I’ve gone through more detail on that, including the metrics and the risks.
What I want to get your permission for in this meeting is that we go to 10 design partners now, we do a legibility bake-off, and we start to look at security. If you approve this, we’ll plan on going forward with a Q4 beta on this project. What do you think of my latest work artifact?
Wade: Based on the critique I gave you on the last one, you basically nailed the two things I called out, which were that this should be a prototype, and where’s the evidence? So right off the bat, this is so much stronger. In fact, it makes me wonder whether Aakash is actually running this live transcript into a coding agent and it’s live-fixing this stuff. I have seen people do that at Zapier, and it always feels magical. You’re taking what the person is telling you and feeding it right back to them, so when they see it come up, they’re like, oh great, that’s amazing. I don’t know if that’s what you did, or if you just anticipated that would be my feedback and guessed it on the way. Either way, that is the magic of good product judgment. You immediately cleared those things up.
The next thing, where I would honestly push you, is the ask. You say, I want to prove this, I want to get these design partners, and I want to get to a Q4 beta. This is where I’m like, why are we waiting for Q4? You’ve already gotten this far. Can you do it faster? This is again one of the magical things about these AI tools. You can go from zero to design partner exceptionally fast. If we’re talking Q4, that’s October. Shoot, you’ve got five weeks. What are we doing for five weeks? You might be able to get there a lot faster than that. So that would be the main thing I would push on. How do we get these iteration cycles going a lot faster? But by and large, this is much better than before.
Aakash: Awesome. What final rating would you give this?
Wade: This feels to me like solidly adaptive. I would be very happy to have this caliber of PM work across Zapier at this moment in time. If you were actually live-listening to my feedback and feeding it back in, that’s an example where I’ve started to see some people doing it, but I don’t think it’s a widely used tactic yet. That starts to look pretty transformative. So if you were doing that, I’d say nicely done. But by and large, this is very solidly adaptive.
Aakash: Okay. I was going for capable, and I didn’t make it. The only thing I did live was add in, really clearly, what I got from Gong. You can even see the prompt that came in just a few minutes before. There you go. It says, pretend you looked at Gong calls.
Wade: That’s what the dead giveaway was. It listed out Gong and Zendesk, and I was like, those are the tools I cited. I think this is an AI hyper-listening to me, because you can tell. AI just has that hyper-specificity to it a lot of the time.
Grading a PM agent stack and product factory (38:03)
Aakash: So the first one was somewhere between unacceptable and adaptive. This one is hopefully somewhere between adaptive and capable. Let’s see where this last one lands, where my agent title kind of gives away what I’m trying to achieve. What we’re seeing is that for my last one, Wade didn’t give it an outright capable. That shows you all that the bar for capable is high. Even though I built this inside a pretty advanced Claude Code harness, the writing was quite a bit better than the last one, there was pretty good evidence, and there was a pretty decent prototype, there’s still a pretty high bar for capable. So let’s see if I can hit transformative.
What I did here is create two images to show what my agent stack looks like. This is my agent stack. The whole idea is that I have a five-layer architecture.
I have skills for our team’s recurring work, like PRD, prep, eval, recall, ingest, impact sizing, launch checklist, weekly review, and 37 more.
Then we have an orchestration layer where subagents fan out in parallel. There’s engineering, design, exec, legal, UX, trust and safety, and a skeptic, which argues everything shouldn’t ship, because we don’t want feature bloat.
Layer three is the tools and MCPs. Of course we use Zendesk and Gong, which was the only update I made once I heard it from you. Reddit. I don’t know if you use Amplitude and Linear, but those are the assumptions I made for analytics and ticketing. Figma for design, although maybe you’re all into Claude Design now. GitHub and Chrome.
Then I think the most important thing is that there’s deterministic enforcement in this environment. It runs hooks on post-tool use. It will reject a memory file if the evidence has no source, so everything we put into memory will have good sourcing. And it will stop the session from ending with our brain being dirty, so the brain is constantly updated.
That feeds into the memory layer, where we have sourcing of everything we’re learning in product across our product team. We have ingestion, and our agents are automatically creating things. These are the hypotheses coming out of, let’s say, Zendesk plus Gong plus Reddit. These are the decisions coming out of Linear tickets and GitHub PRs. This is the research we found from Gong and Reddit. These are what the stakeholders are saying from meeting notes.
So this is my agent setup. That’s part one, and there’s one more thing I want to show you before you give me my rating. The second part is the auto pipeline I’ve created around it.
I basically have a loop running nightly. We take our raw customer signals. Then we have auto agents that run on a nightly cron job. I call this the triage swarm. They dedupe and cluster by job. They populate our source folder, which hopefully you now understand is so important. They tag things as observations, interpretations, or hypotheses. They match things against open hypotheses and flag contradictions. So overnight, for example, we might get nine clusters of insights from all of our signals, and maybe two of those are new. Maybe something came up on a Reddit forum. Maybe one even contradicts a bet made in March. The triage swarm identifies all of that for us.
What happens next is that, using the memory layer, I come in as the PM and ask, do we promote this? Are there independent sources? If it’s just one person on Reddit, we don’t care. But if Reddit and our Amplitude data are both showing it, maybe it’s relevant. So in four to five minutes I look at that, and the system itself helps me document the hypotheses and decisions.
Then, and this is the part that hopefully makes it more powerful than what I’ve shown before, we have an auto-build system. Each step needs the layer above. First, it starts with a quick two-page PRD. Then it does a PRD review panel. Then it creates the prototype. Then it creates the eval. Then it creates the first draft of the code. We get that with the prototype link, the user tests, the draft PR, and the Linear tickets. That’s when we have the next human gate. Human gate one was, do we care about this build chain? Human gate two is, do we merge it? Once it’s done, we put it back into memory. There are hooks that run it all. The idea is that we can go from, let’s say, a 10-day development process to a two-day development process.
So if you saw me running a product team like this, how would you grade my output, Wade?
Wade: This is definitely starting to get into transformative territory. This is not how product and software was built three years ago. Not even close. It is a totally different way of working. It looks a lot more like a factory. You’re saying, my job as a PM or an engineer or whatever your role is in this system is not to do each of these individual tasks. You’ve set up agents who handle these tasks, and now your job is to audit the system. When the agent fails, why did it fail at that task?
Think about a factory. If a factory produces a failed widget, what does the factory worker do? Do they try to individually fix the widgets? Not really. They discard that batch, go back and look at the machine, and ask why the machine generated these failed widgets. And they fix that. That’s where the job is shifting to. Instead of humans stamping out each step of the process, we’re replacing those steps, and now the job of the humans is to audit the overall system and ask whether it’s working. It’s a very different way of running a software and product team.
The question I think all of us are trying to figure out is what the right way to run this factory is. That’s where I was listening intently to see how you’re designing your system. I talk to a lot of folks building these types of things, and I don’t think there’s a consensus yet on the best way to run these loops.
For example, the thing I was trying to figure out is where you’re putting those human gates, and why you’re putting them in those places versus other places. Maybe this is the correct place to put them. Maybe not. Maybe you want to take the first human gate out and say, actually, I want to kick off coding agents for everything, and then I’ll review all the stuff that comes through. Maybe you don’t want to do that, because a lot of these things burn lots of tokens, you’re spending a lot of money on things that could be wasteful, and so it’s worth having a human gate there even though it slows the overall system down.
Those are things I think a lot of teams are trying to figure out. Candidly, a lot of people aren’t at this point yet, but it is becoming more and more common, so you do see it. The exact design of this loop is what I see a lot of teams scratching their heads on, trying to get it working as well as possible. So this is starting to tick into the transformative bucket.
Why not every PM should build the factory (46:07)
Aakash: Awesome. So if a PM really wants to get that rating, although you said at the beginning that you don’t actually need to, because if you’re transformative you might be too focused on the AI tools, let’s say somebody’s manager has told them they should be going for the transformative rating. If in 2026 they build a system that operates like this and it actually works, they’re getting to that transformative level?
Wade: Yes. The thing I would call out is that at a small company, if you’re the only PM at the company, then yeah, you’re probably building out a system like this, because who else will do it? You have to be the one. But at a company of Zapier’s size, where we have quite a few PMs, not everyone’s job is to come up with this thing and build the system. You probably have a team saying, okay, I’m going to go build this. Or maybe you’ve got a couple of teams building a few variants of it. The rest of the PMs come in and say, okay, now help me figure out how to run this system.
So you’ve got a handful of folks in the transformative part, redoing all this stuff. In the meantime, you’ve got some PMs running the old standard playbook and occasionally coming in as the user testers for this new way of working. You can parallel process this new way of working. It depends a little on how your organization is set up.
That’s how I look at it. I don’t need all of my PMs to drop everything and rebuild this system. I think we have something like 30 or 40 PMs at Zapier. I don’t need 30 versions of this loop running. I actually want one way of doing this stuff. Or maybe I want a couple, since there are a few different jobs inside of Zapier and they might need to work slightly differently. But the goal is not that everyone runs their own mini version of this. There is a Zapier product factory that does a lot of this.
Aakash: All right. So now you’ve all gotten the roadmap. You understand, as a PM, how you’re rated on AI fluency.
Wade’s robot staff and the morning brief (48:17)
Aakash: I want to see a bit more of Zapier’s internal sauce. Can you show us some of your internal agent dashboards and how you’re starting to work toward these ways of working?
Wade: Maybe let me show some of my individual use cases. This is what I do the most of with agents today. These are not Zapier production systems. These are just Wade’s personal agents. I’ve built out a little dashboard here so I can show off some of the agents I have set up, which span the gamut from simple use cases to more sophisticated ones. I had my agent build out this demo page for us.
I’ve bucketed them into a few things. I’ve got my robot staff. These are actual agents helping me run my day-to-day systems. I have this CEO CRM, which is a lot closer to the production agent we showed off just now. I have an AI that argues back. That’s a simple thing you can do and probably should do. It’s akin to the skeptic you set up in your product loop. And then I have a bunch of executable skills for real-time assistant stuff that help me with a whole variety of cases. Maybe the most interesting thing is to poke into the robot staff first. What do you think?
Aakash: Yeah, let’s do it.
Wade: So here are five of the more common ones I have set up. The one I always suggest for folks who are just getting into this, the place to start, is the morning brief. It’s kind of a classic. It’s pretty simple to set up. You hook up an agent to your calendar, your inbox, your Slack, and all that other stuff, and say, I want you to build out a daily brief for me every morning. Especially if you’re not used to building agents or connecting them to tools, it’s a very easy one to do.
I have mine run at 6 a.m. every morning. You can see how it runs inside of Zapier. The nice thing is I have this running on Zapier. What’s handy about running these workflows on Zapier, versus having Claude Code or Codex or any of these tools run them, is that Zapier runs them deterministically. You can see it’s kicking off at 6 a.m. every day. It’s fetching these calendar events. This is not an agent running this. This is code. You can poke over here and see there’s code running a lot of this stuff.
The reason you want to run these things deterministically is that it’s reliable. It runs the same way every single time, and it’s way lower cost. None of these steps are burning tokens. You only burn tokens at this stage, where it’s summarizing and drafting the daily brief. When it posts to Slack, that’s just a straight-up API call.
Aakash: Devil’s advocate here, so we can understand how people should engineer this, because I think this is one of the most important agents people need to get right. Couldn’t this miss out on some context because it just has Google Calendar?
Wade: A lot of what it’s doing here is in the code step, where it’s hitting my to-do list. Inside of calendar, a lot of times there are documents attached, so it’s clicking through those links and fetching those documents.
Aakash: Got it. So it has that power.
Wade: Exactly. I think calendar and your to-do list are probably the two biggest things you want to give it access to. It can click through links and attached assets and then summarize those. So having these quasi-deterministic agents that can also fall back to more of an agentic loop, more inference, is really powerful. You get determinism where you care about it, but you get the power of an agent reasoning through the task where you need it most.
Aakash: And I think probably the best thing I’ve seen with Zapier is that you can prompt an AI agent to create these workflows for you. You don’t need to code it yourself.
Wade: Exactly. In fact, these are built inside of Cursor. I’m mostly just talking to Cursor and having it build them, and then I deploy them to Zapier to run. That way I can close my laptop at night and have it run deterministically. I don’t have to deal with a lot of the clunkiness that a lot of these agent products make you deal with right now, because everything’s running locally and you’re burning lots of tokens to do it.
Aakash: It’s like a managed automation in the cloud, essentially.
The scribe and the AI-generated exec agenda (53:17)
Wade: You got it. What else do I have? As much as I tell people to start with the morning brief, because it’s a simple, easy place to start, I actually think it’s only modestly valuable. My favorite is the scribe. I have this set up at the end of my day. You can also run it after meetings, but in my case it runs at 5 p.m. Another way to think about this is the daily recap. The daily recap is way more valuable.
This thing loops over all of my outstanding emails and all of the save-for-later messages I have in Slack. And the biggie, it loops over all of my Granola transcripts and says, here are all the things you need to complete based on today, and I’m going to go ahead and draft anything you need. It’ll actually draft the follow-up emails. If you and I were talking and you said, Wade, can you intro me to so-and-so, Granola catches that, and it drafts a follow-up email for that person. Or, this outstanding action item is on your to-do list, do you want me to take a stab at it?
So the scribe catches all of that from the day and helps me do the end-of-day cleanup that used to take me probably two hours at the end of every day. PMs know this. PMs aggregate to-dos all day, every day. Some are really important, and some are things you want to do to be a good teammate, and how do you fit those in? In the past, you’d just muscle through them. The scribe helps me muscle through them way faster. My end-of-day recap work is now probably 15 minutes instead of two hours. It’s a big quality-of-life improvement for me.
Aakash: I was wondering how you managed to keep up with my emails about a podcast as a CEO. There you go.
Wade: There you go. Here’s a fun one. You probably run a weekly meeting as a PM. How do you set the agenda? What are the important things to talk about? I have a human in the loop, myself, helping with the agenda, but by and large I’m using AI to generate all the agenda items now. I do this for our exec meeting. I do this for our board meetings.
It loops over all my Granola meetings from the week. It loops over Slack. It loops over email. It loops over all my AI sessions, the chat sessions I have with any of my AI tools. And it says, here are the most important things still outstanding that you need to raise. I still audit and approve or disapprove these things, but I find this makes our exec agenda way more relevant than it was in the past.
It also generally has better judgment on what topics we should be talking about. One of the toughest things when you’re in charge of a weekly agenda is that people bring their pet items. Are the pet items actually the most important things? Maybe, maybe not. But if you have it looping over all the metrics from the last week, the AI is going to say, your conversion rate for this was really bad last week. You need to talk about this. Don’t let people get away with not raising it. So the topics tend to be better if you have one of these agents running over all your stuff every week, pointed at the right data sources, with some ability to call out that these topics need to be addressed. Those are some of the more fun items in my robot staff.
Why Wade vibe coded a CEO CRM (57:06)
Wade: The next one worth talking about is the prospector one, but with that, let’s go show off the CEO CRM, because it’s one of my more fun little projects. There’s that debate online about whether you should vibe code your CRM. I am very firmly in the camp of don’t vibe code your CRM. And yet, here I am. I have vibe coded a CRM.
Aakash: Oh man.
Wade: Look, this is super basic. It’s nowhere close to what you get from HubSpot or Salesforce or any of that stuff out of the box. What this really is, is an agent that handles a very specific set of workflows that I personally care about. You’re looking at a demo version of it, but this is what my real CEO CRM looks like.
Here’s the deal. I don’t actually look at this all that often. I started by building it as a CRM to look at, but mostly now it runs as an agent, and I’m only showing the UI because it’s hard to demo agents without showing you something. It has access to all the enterprise accounts we have and how much ARR is in them. It flags what needs my attention based on a whole bunch of signals. Is there a renewal coming up? Is there a usage drop happening in the account? What’s going on? Of course, I can poke into an account and see the apps they’re using, a bit about the account, the people on it, and so on.
But what all this context is really leading up to is that I just want to be talking to these customers more. Who should I be talking to, and why? What this agent does for me now is run every Saturday night. When I wake up in the morning, I’ve got 10 to 20 emails drafted in my inbox for enterprise customers I want to stay in touch with. It tells me, here’s why I think you should talk to this person this week. They’ve got a renewal coming up, or usage has gone down, or usage has gone up, and here’s what I think you should talk to them about.
You’re seeing it in the CRM, but what it actually does is put a literal draft in my email inbox. All I have to do is take a look, say yep, that’s someone I want to talk to, and fire off the emails. Sometimes I’ll make some quick edits, but by and large I’m using this to handle what would otherwise be a pretty cumbersome workflow every week. It helps me keep up with our most important customers and build a personal relationship with them, which in the past would have been really tough for me. You have a CSM team, and the CSM team does all that. Our CSMs are great, but what people love is hearing from the CEO. So now I can build a much stronger relationship with some of our most important customers.
Aakash: And it’s in your voice, which is really cool. Given our conversation about slop earlier, it’s all lowercase. It’s written how you would write it. I think that’s a key component. People probably need to iterate on their agent setup if they want drafts created, to make sure it’s writing at the right level.
Wade: I’ll tell you what, funny enough, that has been the hardest part of this thing. Building the CRM and getting all the agentic logic working is so easy compared to trying to bend these agents to write like a human. They are just not very good at that. Even still, it’s doing okay here. There are still things I think it could do better, but it is really tough.
I don’t have it in my demo, but I do have an agent running analytics on this stuff too. It helps me see that this type of writing or these types of subject lines tend to work better than others, so maybe do more of that. It gets a lot easier to do these types of things. This is the stuff I think we all want to be doing. I want to be spending more time with my customers. I want to be figuring out how to write better emails. But if you’re in a product job, there are a million things you want to be doing, and you just can’t do all of them well enough as one person.
That’s where I get so excited about what AI and agents can do for you. You can have a standard in your head of what great looks like, and ask, how do I use these tools to help me be great even when I’m just a human? I simply can’t be that great all the time. That’s where I get really excited about a lot of this stuff.
How rare a transformative rating should be (1:01:56)
Aakash: That covers our show-and-tell segment. And you personally only rated yourself as adaptive, right?
Wade: Yeah. Honestly, I think I’m adaptive in a lot of places. I feel like I’m a super generalist with a lot of these things, and I have folks on the team who are way better at many of them. When I’m pushing into transformative, honestly, I’m just stealing from them. I’m looking at what they’re doing and how they’re figuring it out, and I’m taking the tactics and applying them to my own workflows. For the stuff we’re doing as a company and as a team, there are people who are far smarter and have figured out far more than me, not just about how to use it themselves, but about how to build systems that work for all of our customers and our whole employee base. So I feel like I’m capable or adaptive at times, and the places I’m transformative are not that many.
Aakash: So interesting. One thing I’m taking away is that the curve I had in mind was that maybe 20 or 30% of people could land in transformative. It’s not like that. You should have a very high bar for that final rating.
Wade: Yeah. I think there aren’t that many people in the world who are truly transformative at this stuff. To me, transformative means you are an n of one. You’re the first of your kind doing this new thing, and you’re figuring it out. That bar is exceptionally high, in my opinion.
Aakash: So if I’m a product leader with a PM team of 30 to 40, should I only be handing out maybe one transformative rating a half?
Wade: Maybe. Yeah. It’s probably a low percentage.
Aakash: Okay, so that covers AI fluency. Hopefully you all got a really good deep dive into that.
Where Zapier’s business sits after the 2021 valuation (1:03:45)
Aakash: We have the CEO and co-founder here, so we get to ask him the tough questions. And the tough question on everybody’s mind. In 2021, you had a huge valuation. Although I think the $5 billion mark in 2021 actually came through some sort of secondary share sale to Sequoia, it was a $5 billion mark that got labeled onto Zapier. People were looking at Air Table, and now it’s less than 10% of that amount for you at Zapier. You’ve been around since 2012, and you had this amazing high in 2021. Where does Zapier’s business sit now? Are you at 10% of your value? Have you grown since 2021? Talk to us about the numbers and what you can share.
Wade: Yeah, we’ve grown since 2021. One thing that’s unique about Zapier is that because we haven’t raised primary capital since 2012, the valuation thing doesn’t matter as much to us. Valuations really only matter at one moment in time, and that’s when a transaction happens. Our goal has always been to build incredible automation products for our customers and let the rest of that stuff take care of itself. For the last couple of years, our driving force has been, how do we wield these incredible AI tools to make it a lot easier for folks to build and run automations in this new way? That’s where we’ve put the lion’s share of our focus.
Why the new no-code is code (1:05:17)
Aakash: If you look at the no-code space in general, people are calling it the no-code apocalypse, and I consider you the leaders of that space. Help me reconcile this. You’re growing, but there was this no-code apocalypse. Did you adapt in a particular way that product people can learn from, or is that apocalypse overblown?
Wade: One of the things we’ve come to believe is that the new no-code is code. In one of the demos I showed, the daily brief, that’s code. That’s not no-code. There’s code under the hood running that workflow. A lot of what these no-code products have to do is rethink the underlying architecture of how these tools work.
In a lot of places, we’re exposing our capabilities, our trigger infrastructure, our action infrastructure, our runtime environments, and our governance layer to coding agents, and allowing them to be the thing that builds on behalf of our customers. There are so many non-engineers using these tools to write code even though they never look at it. I actually don’t know what the code underneath my daily brief is doing. I poked it open to show you, but I’ve never actually looked at it, and I don’t really care, because the daily brief works for me.
That’s the key thing a lot of the SaaS incumbents have to figure out. How do you expose these capabilities to these tools so you can generate value on top of them? Benioff is talking about this with Salesforce. Salesforce is headless now. That’s the value of Salesforce. It’s not the UI you log into. It’s the APIs and the MCP servers and all the stuff under the hood that exposes those capabilities to a coding agent.
Should every SaaS go headless (1:07:05)
Aakash: I think it was a year and a half ago that we had Bryan, your CTO and co-founder, on to talk about the Zapier MCP. Talk to us a little bit about that. Should all SaaS be going headless? Should every SaaS be creating an MCP, and how did that contribute to the growth of your business?
Wade: I think so. One of the things we’ve long stood for is that no one wants to show up to work, log into your SaaS product, and sit there doing data entry into that tool. With all the SaaS we’ve had over the last decade, it was still a human doing the work. I want software that actually does the work for me. That’s what Zapier has always been, a workflow automation tool that does work for you.
But the one place where a human had to do work to use Zapier was building the automation. You had to sit down, log in, and click through a bunch of things. Heck, you had to think about what you wanted to automate. Thinking about what to automate is actually harder in some places than building it, and building was hard enough.
The magic now is that if you can expose all the context, the intelligence, and the tools for building, whether you’re a tool like Zapier or a CRM like Salesforce or any of these other tools, the user of your software is now the agent. The agent comes in and does all that work. That frees up the human for the things that are distinctly human. The judgment parts of the job. Thinking through whether this is actually correct or not. Those are the places where the human gets elevated in their work.
If you’re still thinking of your software as, I have a human user, and the human is going to use my software to do this, that, and the other, I think that’s a little backwards, at least for B2B. In B2C it’s a little different. Consumers behave differently in the way they want to use software. But at work, it’s, I want to delegate this stuff to somebody else to use it for me. Increasingly, that’s a coding agent. So if your software isn’t headless or can’t be run headless, I think you’re going to find yourself swimming against the current.
Aakash: Hmm. This is making me think my PRD might not have been aligned with your strategy, because it was focused on a human user, not an agent user. Very interesting. I’m going to have to think about that a bit more.
Competing with Lindy, Cowork, and n8n (1:09:21)
Aakash: I want to talk about this new breed of competitors. We had the Lindy CEO on. He talked about how Cowork actually had a pretty big negative impact on their business, and they had to reinvent themselves. I’m also recording with Jan, the CEO of n8n. They’ve had an amazing trajectory, from 7 million to 40 million ARR, then 40 million to 100 million ARR, and they just raised at a pretty big valuation. When you think about these new competitors, how have you thought about counterpositioning against the Lindys, the Coworks, and the n8ns? How do you create a unique space for Zapier, which has been around for so long?
Wade: What’s new for us is that, to your point, we’ve been doing this for 15 years, and for most of those 15 years the space was not very crowded. There weren’t a lot of automation players. On one hand, that’s nice. We were sort of the only game in town, and it allowed us to build this incredible integration library that still nobody has matched. We have over 9,000 different tools that we hook into. Folks kept saying it’s easier and easier to write integration code, and yet no one has matched what we’ve done here. That’s the nice part.
Now there’s a good news, bad news story. The good news is the demand for automation is sky-high. It’s never been higher. The markets are so big these days compared to our first decade of existence. But with big markets come new approaches and new ways of doing this stuff, so there are a lot more competitors.
Where this really forces you to put your product head on is that you now have to make strategic choices. What are we going to focus on, what are we going to be good at, and how do we make smart choices there? Let’s use OpenAI and Anthropic as a great example. OpenAI was the early dog in the race, and they were chasing all sorts of different things. Anthropic said, you know what, we’re going to focus on code specifically. We’re going to be great at code. Look at what that did for them. It allowed them to stand out, and now it’s forced OpenAI to be smarter about their strategy. You’re seeing them get a lot more crisp about who they’re for and where they want to win.
When you have markets this big, with many players that are going to be successful, you have to figure out your unique value prop and the set of customers you can build around. I think that’s what we, Lindy, n8n, all of us have to answer. For Zapier, increasingly the answer is that we’re going to help you run these automations. We’re going to help you run them deterministically, so you’re not burning tokens and you don’t have to keep your laptop open. But you still have the power of an agent building them and helping you manage them. So the setup is really easy, and when they break or fail in unpredictable ways, the agent can help you recover. Zapier is going to be really good at that. That’s where we’ve been growing, helping folks with those types of capabilities.
Aakash: We could talk for another hour and a half, but I need to let you get on to the day job of growing Zapier. Wade, thank you so much for being on and teaching us about AI fluency today.
Wade: Thanks for having me.