Jayesh

1. 0:00 – 2:19

   Intro

   1. AGAakash Gupta0:00

      You created this new term, ADLC.

   2. JGJayesh Govindarajan0:02

      Yeah. If the software you're producing is not just an independent piece of software, but is an agent, how do you build it? How do you test it? How do you evaluate it? How do you deploy it?

   3. AGAakash Gupta0:11

      So what I want to do is kind of build people a recipe for becoming-

   4. JGJayesh Govindarajan0:14

      Yeah

   5. AGAakash Gupta0:14

      ... more AI native. I feel like at the base we've covered that tool layer.

   6. JGJayesh Govindarajan0:18

      We are all in Slack all the time. That is really our primary interface and how we work together with each other.

   7. AGAakash Gupta0:23

      The next layer is roles, and you just talked about it, PMs, and you also referred to it with evals. A lot of people are wondering, what is the future of the product trio? The PM, designer, and engineer roles, they all seem to be converging- [laughs]

   8. JGJayesh Govindarajan0:37

      Yeah. [laughs]

   9. AGAakash Gupta0:37

      ... on top of each other.

   10. JGJayesh Govindarajan0:38

       But these lines that we draw are- don't really exist. I think we create them in our own heads, and then we specialize around them.

   11. AGAakash Gupta0:44

       And I think that third layer now is the life cycle that all of this is under. I think the very last component at the very top of the pyramid is probably where you spend a lot of your time. How engineers, product managers, and executives who are really setting the strategy of what we're working on collaborate to build a roadmap.

   12. JGJayesh Govindarajan1:02

       One piece of advice I have always is...

   13. AGAakash Gupta1:08

       Before we get into today's show, please take a second to check that you're subscribed on YouTube and following on Apple and Spotify podcasts. If you want access to all of my favorite AI tools, I've gotten them to give you an entire year of their paid plans. Check out bundle.aakashg.com for an entire year of Bolt.new, Airtable, Speechify, Descript, Magic Patterns, Linear, Dovetail, Arise, and Mobbin. And now into today's show. Jayesh Govindarajan has spent over 25 years in the tech industry, rising up from being a software engineer to leading a huge 400-person engineering org at Avaya, starting his own four-person startup, which was acquired by Salesforce, and now has worked his way up to leading a 700-person org, which is responsible for Salesforce AI and Agentforce. So he has a ton to teach you about how to build an AI native company, an AI native engineering team, and an AI native product team. Jayesh, welcome to the podcast.

   14. JGJayesh Govindarajan2:17

       Thank you. It's a pleasure to be here.

2. 2:19 – 7:33

   Inside Salesforce's AI org and how agentic coding changed it

   1. AGAakash Gupta2:19

      If someone doesn't know you, can you walk us through what is the org you lead today? What are they responsible for? What do they do?

   2. JGJayesh Govindarajan2:26

      Uh, sure. So I lead the broader AI engineering org at Salesforce. What that means is we, we set the strategy, direction, build and operate AI systems that span predictive AI, generative AI, and now agentic AI. Basically, three flavors of AI that deeply embed into the Salesforce stack, enable our customers to change how they work using predictive AI at its core, generative AI at s- at its core, and now building agents for many, many of our customers.

   3. AGAakash Gupta2:54

      So you've been working on AI and AI products for over 20 years. What does it look like now, here at the end of 2026, to be operating like an AI native organization?

   4. JGJayesh Govindarajan3:07

      That's a great question. I'll color this based on kind of what we're doing at Salesforce, how we are organized, how we're structured. I think there's no better example of an AI native, uh, team than one that is building the foundation of an agentic system that, that customers use to build their agents on. So broadly, the last, uh, two and a half, three years have been, uh, an incredible whirlwind of, of agentic systems as our customers have sought to become an agentic enterprise, and all of that sort of is underlying Agentforce, which is, uh, our harness that we built about two years ago, uh, before the name Harness came along. So from an AI native perspective, uh, the way the team is structured is, is designed to be able to build harnesses, to be able to build models, to be able to use these models in context of a harness, and then, I'll talk more about this later, uh, this emerging life cycle of an agentic system called a- that we like to call ADLC, uh, which is how do you build an agent? How do you test an agent? How do you evaluate an agent? How do you observe an agent in production? So these are tools and, uh, systems that we build that our, that our customers use to go build their own agents for, for the s- for the scenarios and use cases that they use it for.

   5. AGAakash Gupta4:22

      So how has your organization changed in the last couple years? We see everybody talking about Claude Code and Cursor. We see people talking about agentic coding really being the first breakthrough in AI that's really transformed the organization. What has that meant for the roles and types of people in your org?

   6. JGJayesh Govindarajan4:43

      Great question. So I'll take a step back first. We need to color this from the lens of the kind of work people do. So we have teams that basically build and train and tune models. Their world has changed considerably given the kinds of models that they're tuning and training, underlying and working, partnering with frontier clouds, such as OpenAI, who is a great partner of ours, Anthropic, and Gemini. That world looks, uh, a certain way. And then there is a team that is moving really fast and building the harness technologies, which is, uh, which is how context, uh, gets engineered into an agent, which is how tool calling happens within an agentic framework, and these are all tools that we build within the agentic system. That team has a certain rhythm of operating with the tools that they have. Uh, and then there's the very new and emerging agent development life cycle, which is how do you build agents? How do you, how do you evaluate them in production at scale? How do you observe them? What happens when a long-running agentic conversation is going off the rails? How do you, how do you correct it? How do you bring all of that sort of system back? That's sort of the three big layers and, and, and if you look at my org chart, that's kind of what it looks like. I have a team that's responsible, uh, at the model layer, uh, called the AI platform team, and there's a team that's above that which is building harnesses, which is building memory systems for harnesses, and this is t- there's a team on top of that which is the whole ADLC and optimization agent optimization team. Um, and I think- All three teams are working very differently than they were before. We are obviously very AI-pilled here. [laughs] Uh, you know, within our team, we use Claude, we use Codex, uh, for our development processes. We are all in Slack all the time. Uh, that is really our primary interface and how we work together with each other, uh how we work get do- how work gets done within a team and across teams. Increasingly, we are bringing some of our customers also into Slack using this feature called Slack Connect, where they can actually work with us directly on some project. And that's kind of the communication part that's changed considerably with Slack at, at its core. And the great things about Slack is you can basically bring in your agents to come do work on your behalf, and we'll, we'll get into more of that. But at a high level, our, our world has changed in every aspect. How we design products, uh how we work with customers on iterating on what it is that they need to do, uh that we need to build, how we get feedback from them, and then how do we break that into tasks, and then how do we get agents to help us with some of these tasks? I think broadly, in one, in one sentence, I'd say we've had people change how they think about work, and that change is, in essence, how do you manage a team of agents, uh versus doing the work by hand, if that makes sense.

3. 7:33 – 9:30

   Ads

   1. AGAakash Gupta7:33

      Yeah. I used to think I had a retention problem. Turns out I had a messaging problem. I was sending the same onboarding emails to every new user, whether they activated on day one or never logged in again. I had no idea who was slipping or why. Customer.io changed that. Every message I send is now based on what users actually do in the product. Someone hits a key activation moment, they get nudged to the next one. Someone goes quiet, they get a different path entirely. Their AI agent makes it fast. I describe the campaign I want, and it builds the full journey for me. Triggers, timing, copy, even branching logic. And when I want to know how something is performing, I just ask the agent directly and it tells me what to do next. They also have an MCP server, which means AI tools like Claude can see directly what's happening in your Customer.io workspace. Your segments, your customer data, your attribution, all of it. So instead of explaining your business context every time you need help, Claude already knows it. Notion used Customer.io to personalize their onboarding and hit nearly fifty percent open rates, improved conversion by six to seven percent with localized campaigns, and pushed open rates up another twenty percent through AB testing. The idea is simple. Customer.io helps you deliver more impact from every message you send. If you're a PM or founder and your onboarding is still one size fits all, try Customer.io at customer.io. Here's the problem with most AI tools. They just sit there waiting for you to prompt them. You do all the remembering, they do the typing. Ari from Ariso flipped that for me. It connects to my email, calendar, Slack, and it works the other way around. It comes to me. Monday morning, there's a briefing waiting. Before a call, it reminds me what we covered last time and what I promised to send. When a follow-up slips, it nudges me before the other person asks to. Every commitment, every thread, every contact tracked and organized without lifting a finger. And because it has continuous memory, it actually gets smarter the longer I use it. It's not a chat window. It's one AI partner that knows my whole working life, and it keeps me prepared for all of it. If you're tired of being your own chief of staff, try Ari at ariso.ai/aakash.

4. 9:30 – 12:56

   How to pick and roll out AI tools

   1. AGAakash Gupta9:30

      That's A-R-I-S-O.A-I/A-A-K-A-S-H. You mentioned a bunch of tools there, so I want to dive deeper on those tools. And from your perspective at the executive layer, when do you decide, "Okay, we need to get this tool into the organization"? What are the proof points you need to see externally? How do you roll out a new tool? Let's say you talked about orchestrating agents. The new craze right now is GroqBot or Hermes Bot Mode. So when you're evaluating, "Okay, do I need to bring GroqBot into my organization?" What is the thought process you're going through?

   2. JGJayesh Govindarajan10:06

      Yeah. So firstly, I think there is, we have to acknowledge that tools are moving at a rate that is unprecedented. There's no doubt about that. What does that-- That implies that one cannot make a bet forever, right? I think you need to make bets, and you need to f- you need give them some space to play out, and then you need to back something and push that sort of tool and technology through, but remain open to change. As an example, uh, we started off using Cursor. Uh, that was the primary sort of interface of choice for engineers. Then Claude happened, and, you know, this sort of family of agents doing work, talking to each other, get, get it done, uh, in particular, uh, Claude Code, the harness for coding, you know, became something that our engineers loved using. Our-- The way I look at this is you need to give people a choice to pick the tool they want, and often the best engineers, the best PMs pick the best tools to get the job done. Uh, and then you look at data. Then you look at what's actually driving adoption more, and then you lean towards the best practices which emerge from just real usage on a daily basis.

   3. AGAakash Gupta11:14

      So it sounds like you're of the camp that don't prescribe, "Okay, guys, we're all gonna use Claude Code now." Give people access to multiple sets of tools, whether that's Codex, Claude Code, Cursor. If there's something new that comes up, give them access to that, and don't be super restrictive on your IT corporate security policy. Is that fair?

   4. JGJayesh Govindarajan11:38

      Be very, very careful about corporate security, but be open about the tools that are given to users as a choice. So every single tool in the Salesforce ecosystem has to go through security. So we make sure that, you know, all the security criteria is met, but we give our teams a choice for a while, and then we watch to see what works. And often the best practices emerge from real usage. Uh, and as I said, things keep changing. Uh, it used to be that you'd, you know, the IDE of choice I don't think it changed in a decade, um, from an engineering perspective. Uh, the tools that a PMs, uh, has used, Excel, Docs, uh, Google Docs, Figma, these tools haven't changed a whole lot in the last decade or so. Uh, but now they have. And not only have they changed, the change isn't singular. It's gonna keep evolving. So I think, like, you need to think of not just where you are on the graph, but what the slope looks like, and, and, like, try to hug the tangent as the slope changes continuously. And the way to do that is to have a process and a methodology and some trust that your teams will be able to figure it out, so long as you give them access to the best tools that are available, and then watch what works, what doesn't. And that sort of served us, served us quite

5. 12:56 – 15:14

   Headless Salesforce inside Claude

   1. JGJayesh Govindarajan12:56

      well, actually.

   2. AGAakash Gupta12:56

      One of the most interesting things that I think Salesforce has done recently is this idea of being headless.

   3. JGJayesh Govindarajan13:04

      Mm.

   4. AGAakash Gupta13:05

      And you guys just recently announced Claude Force.

   5. JGJayesh Govindarajan13:07

      Yes.

   6. AGAakash Gupta13:08

      So basically, where your users for your $60 billion revenue or $50 billion revenue business u- they used to live inside your tools. They used to live inside salesforce.com, but now increasingly they're living inside Claude, or like you mentioned, they're living inside Slack. What does that transformation look like on the ground for people internally? How do they make that shift towards living outside of the SaaS products they used to buy, and then more living inside of these centralized operating systems, whether they're Claude or Slack?

   7. JGJayesh Govindarajan13:41

      Liberating, in one word. I think a lot of the Salesforce magic was never in the interface, although we did that well. It was always in the layer that powered the interface. Um, so when we say headless, all of the metadata, all of the business logic, all of that is actually captured in the API. And when Claude came along, it, it's really an unshackling of these, of these subsystems that do powerful things, understanding what the flow of sales process looks like that ends up with a 70% probability of a close, or a ticket resolution looks like that has an 80% chance of being resolved successfully, with this ability to bring in a human at the right time. These are powerful workflows that have been perfected over decades with Salesforce and its customers. Uh, they've customized it for their own needs. What headless does is it lets our customers bring that into Claude using skills that we adapt these around, and basically use it in any context that they want. So Claude is doing this abil- you know, this, this bit of bringing all of these things together, you know, into Claude Force with this ability to build an interface that is very custom for their need. Uh, again, I think the magic was never just in the user interface. It was what was underlying the user interface. And what Claude basically does is helps you code one up for your bespoke, um, you know, need, which is very specific to what you want to do, and you're basically using the same technology in the back.

6. 15:14 – 19:22

   Getting ground truth from probabilistic AI

   1. AGAakash Gupta15:14

      So what I want to do is kind of build people a recipe for becoming-

   2. JGJayesh Govindarajan15:17

      Yeah

   3. AGAakash Gupta15:17

      ... more AI native. So we kind of talked a little bit about you need to hug the tangent of how tools are adopting.

   4. JGJayesh Govindarajan15:24

      Mm.

   5. AGAakash Gupta15:25

      Then we talked about you need to let people operate inside these centralized tools like Claude and Slack. And the first sort of thing that I worry about when somebody's using Salesforce in Claude is that it's not really as deterministic as Salesforce was. If you think about it, the way Salesforce is identifying how much open pipeline you have, there's clear data fields that it's referencing. But we all know using LLMs, they can be probabilistic. They, they can have variations, but you can't really have two pipeline numbers- [laughs]

   6. JGJayesh Govindarajan15:57

      That's right

   7. AGAakash Gupta15:58

      ... right?

   8. JGJayesh Govindarajan15:58

      Exactly.

   9. AGAakash Gupta15:58

      You can't have 25 million and 20 million. Which one is it, right?

   10. JGJayesh Govindarajan16:01

       Yep.

   11. AGAakash Gupta16:01

       You actually need to know. So if people are moving into these tools, how do you build the harness in the right way, or how do you use Claude or Slack in the right way so that you can get to a ground truth?

   12. JGJayesh Govindarajan16:15

       Yeah. With, so with Agentforce, we, we saw this need arise just as soon as we launched, which is this need to bring in some degree of control and determinism to an agent specification. What does that look like? It looks like a, uh, a language that you can describe your agent in, which then translates into tool calls. Uh, it translates into context, um, lookups, uh, and it translates to reduced hallucination because it's relying on tool calls. Um, we designed the language around it called Agent Script. Um, and basically it transpiles to plain English, so you can describe what an agent should do in plain English. It transpiles to Agent Script, which then has all the logic and the metadata for tool calling for, for getting the right, uh, context in the right place. That reduces hallucination rates by a massive, massive amount because you're not using Claude to generate code when there is already a piece of code and an API that is exactly what you want deterministically every time, tried, tested, uh, and good to go. You are still using Claude to bring the right systems together for that sort of task, right? But that's kind of the, the, the magic, which is in the agentic world with Agentforce, you can bring in more than that. You can bring in a set of controls, uh, with Agent Script to be able to pull all of that together.

   13. AGAakash Gupta17:39

       So in our recipe card, it sounds like what's really important is giving the connections to the right data.

   14. JGJayesh Govindarajan17:45

       Mm-hmm.

   15. AGAakash Gupta17:45

       But on top of that, defining how those tool calls work-

   16. JGJayesh Govindarajan17:50

       Right

   17. AGAakash Gupta17:50

       ... and building the right skill files so that when Claude makes those tool calls, it does it correctly.

   18. JGJayesh Govindarajan17:56

       Perfectly. Perfectly right. One other thing I would add, which is a really important insight that we, that we gleaned away, is if you look across my teams, we have teams that think eval first by nature. These are all the data science teams that have been doing predictive AI and generative AI and, and, uh, generative AI and then into the agentic world. For them, they are what I call eval native. They look at a system probabilistically. They, they understand that it's not gonna work all the time, so their test cases or evals that they've written tied to outcomes is a superpower now. Um, and there are other teams that are more sort of code-focused, engineering-focused. They've built the infrastructure. They've always worked in the d- deterministic world, and very quickly you asked, you know, earlier you asked what are the big changes that you're seeing with the teams? This is one of the changes we're seeing. We're seeing a lot of people becoming eval-first, uh, and that means thinking through not just the test cases, but outcomes, and having these custom scorers using both LLMs and other models to score the output. Um, and these are not generic. These are very specific to the agent you're building or the code you're writing. This is the other sort of ... This is a cultural shift. It is a tool set shift. It is a mindset shift in how you sort of design software that is probabilistic and you

7. 19:22 – 21:25

   Why Slack is the AI native work hub

   1. JGJayesh Govindarajan19:22

      want it to work e- you know, want it to work every time. So I'd, I'd add one more, which is the eval part around it.

   2. AGAakash Gupta19:27

      Let's circle back to evals in a second. I wanna close the tools component of this-

   3. JGJayesh Govindarajan19:31

      Sure

   4. AGAakash Gupta19:32

      ... with Slack.

   5. JGJayesh Govindarajan19:33

      Yeah.

   6. AGAakash Gupta19:34

      Because I'd say a lot of people listening who are trying to come up with an AI native organization, they're probably still stuck in the Microsoft Teams world. They haven't ... They don't even understand why Slack is important or what it enables. So can you talk to me about, as far as I understand it, people are spending, like you said, 50, 60% of the, percent of their time in Slack now.

   7. JGJayesh Govindarajan19:56

      That's right.

   8. AGAakash Gupta19:57

      Whereas it might have been in an IDE before. So how do you get that set up correct, and what is involved in that set up so that you're s- doing so much out of Slack?

   9. JGJayesh Govindarajan20:07

      That's a great question. I use Slack every day, and I am just a mad fanboy. Uh, uh, so two things. One is, what's the one place that people are available asynchronously all the time? It's Slack. In most enterprises, that's where people are. That's where work is organized. That's where conversations around work are organized. That context is gold dust. Um, especially taken longitudinally over the long period of time, that just is the amazing bit of missing piece that's needed for getting something done. Serendipitous discovery is possible in such a system. Uh, Slack will routinely find someone that has that answer in some channel that, that is a public channel that I had no idea existed. Um, and that's context for an agent to work on. So, so what does the tool set look like? It looks like a great implementation of Slack within the organization. It, it is a, uh, i- it is a Slack where people are using it every day, which is, you know, super high utilization, which is leaving a lot of data traces behind. And then it is plugging in this agentic tool set within Slack. We ship with one that is magical, called Slackbot. If you haven't used it, please do.

   10. AGAakash Gupta21:24

       I want to take a second

8. 21:25 – 24:51

   Ads

   1. AGAakash Gupta21:25

      to talk to you about the fourth cohort of Land PM Job. I trained 30 students in cohort one, 50 students in cohort two, and 75 students in cohort three, and I am bringing back the program for cohort four. It starts in August, and it lasts three months, where you're gonna have intense sessions, a Monday morning session where I go over your resume, behavioral interviews, LinkedIn. On top of that, Bart Jaworski is gonna be teaching you the PM fundamentals in 2026, how to write AI PRDs, how to AI prototype with Claude Code, all of the key skills you need to freshen up your knowledge for this market. And Ankit Varmaani is gonna be teaching you AI product management. He is an AI product manager at Uber, and he is gonna teach you how to build AI features that actually work successfully. On top of that, Prasad Reddy is gonna be doing one-on-ones with you for mock interviews, LinkedIn review, candidate market fit review. So it is a full package. It is three courses in one for one low fee. So join at landpmjob.com. Agents and assistants are browsing, shopping, and transacting alongside humans, while fraudsters use AI to build faster, cheaper, and more sophisticated attacks. Technical teams need device intelligence that evolves as quickly as these attacks do. Fingerprint is exactly that. Accuracy is the number one reason customers choose Fingerprint, because their device intelligence goes deeper than identification alone, resolving visitors with precision that holds up through spoofing and evasion attempts for months at a time. Fingerprint collects more than 100 signals across devices, network, and behavior to build a single identifier, then provides signals like bot, agency, proxy, and VPN detection to give technical teams a complete picture of risk. They ship hundreds of product updates a year, so they adapt first as browsers update, privacy requirements change, and fraud tactics change. With one API call, teams can get this running in minutes. Over 6,000 companies rely on Fingerprint every day. Join them now at fingerprint.com. Imagine learning AI product management, AI product strategy, AI product leadership, advanced PM with Claude Code, all from frontier leaders at OpenAI, Anthropic, and Google for less than $10 a day. Actually, you don't have to imagine it. That's exactly what Product Faculty's AI Builder Fellowship gets you. One yearly membership, six live cohorts. It's not recorded videos or another content library you never finish. Real live sessions with frontier AI leaders, hands-on AI build labs, executive insight sessions, capstone projects, unlimited retakes, and continuous access to new programs as the AI landscape evolves. You'll also get every new certification they add while you're a fellow at no extra cost. The goal is simple: help you master frontier AI skills to become an AI native product builder and operator, not just someone who talks about AI. Purchased separately, these programs are worth more than $19,245. The lowest priced certification alone starts at $2,700. But founding members can join the entire fellowship for less than $3,600 per year. That's less than $10 a day. Soon, the price increases to $5,000 a year. So if you're serious about becoming the person your company turns to for AI, this is one of the highest ROI decisions you can make this year. Join the AI Builder Fellowship at productfaculty.com.

9. 24:51 – 25:45

   Prototyping with customers inside Slack

   1. JGJayesh Govindarajan24:51

      You can ask it questions. It can orchestrate other agents for you. Uh, it can bring you the right people. Um, it, it can, it can send emails. It can send other Slack messages. So that's... You're basically building your, your agentic environment, work environment within Slack. Um, and you can build into, bring in third-party agents as well. So that's sort of the, the, the tool set. From a developer perspective, we use, we use Slack code quite a bit. For simple apps, uh, you can write the spec there, and you can actually show, you know, build a simple UI in there. Uh, how cool is it for a PM to be able to go create a small mock in a Slack, you know, thread with their customer and just ask him, "Is this what you had in mind?" Versus writing a PRD, getting an engineer to go build it, and then create a link for it and then send it back to the customer. The customer kind of looks at it and goes, "Eh, not really what I want." You know, so basically,

10. 25:45 – 34:15

    The future of the product trio

    1. JGJayesh Govindarajan25:45

       this whole cycle is sped up exponentially, and it's just a joy to work.

    2. AGAakash Gupta25:49

       So I'm trying to build this recipe card. I feel like at the base we've covered that tool layer.

    3. JGJayesh Govindarajan25:54

       Right.

    4. AGAakash Gupta25:54

       The next layer is roles, and you just talked about it, PMs, and you also referred to it with evals. So a lot of people are wondering, what is the future of the product trio?

    5. JGJayesh Govindarajan26:06

       Mm.

    6. AGAakash Gupta26:07

       The PM designer and engineer roles, they all seem to be converging- [laughs]

    7. JGJayesh Govindarajan26:11

       Yeah. [laughs]

    8. AGAakash Gupta26:11

       ... on top of each other. So we humans are notoriously bad at predictions, but what are you seeing on the ground right now?

    9. JGJayesh Govindarajan26:18

       Yeah.

    10. AGAakash Gupta26:18

        Are you seeing, when you're staffing up a product team, that you need as many PMs as before, as many designers as before? How are you thinking about that?

    11. JGJayesh Govindarajan26:28

        Well, that's a, that's a big question, and I think it's, it's a really important one. I, having been an entrepreneur for... I think the one thing that becomes very clear to you when you are an entrepreneur is that these lines that we draw are, you know, don't really exist. I think we create them in our own heads, and, and, and then we specialize around them. So, so then they do become real after, after a point. I think what the tool sets that we have available to us, what the large language models and the agents can do effectively now, means that those lines are being blurred. They're being blurred in ways that are incredible to see. As an example, if you're a PM, if you're an engineer that has a customer first mindset, and many do. Many don't want to build systems that are never gonna see light of day. They want to build systems. They want to put their heart and soul into things that has an impact, that customers will use every day. Uh, how can they test that? Well, if they have customers that they can work with directly, they can start putting products out in front of them, get direct feedback. Do you need a middleman? I don't think so. Um, conversely, if you're a PM, um, your bottleneck may be waiting for that engineer. You've logged in the request for that engineer, written a PRD, and the engineer's working on something that was, that was written before, and you're waiting. Uh, you don't have to wait anymore. The product development life cycle has, can be sped up significantly more. And now the bottleneck is, can you find customers fast enough, and can you get to customer success concept market fit, product market fit quickly? And one of the great things about working at Salesforce, I truly believe this, and you've seen here, the energy here at Dreamforce, we just have incredibly loyal customers, and we, you know, we, we couldn't be more thankful for that. You've seen the trailblazers that, that have come here, that... And who are these people? These are people that started out in, you know, you know, roles that, that were, that were sort of fairly junior and implemented Salesforce and then grew with the company, uh, in implementing this, and now are customer service, uh, officers of the company. A tremendous loyalties, and it's really easy for us to go talk to them because of the trust that Salesforce has built over decades and say, "Hey, will you try this? We've built something. We want some feedback. Will you try it?" And it's super easy for us to get 10 pilot customers for anything we do. And we have that trust that once we build it, we will build it right, and we will make them successful with it, no matter how long it takes. So I think that sort of bottleneck, you know, where you need to go find customers is completely nonexistent in Salesforce. So then what's the new bottleneck? The new bottleneck is, are you able to cook with them fast enough? Are you able to get feedback fast enough? Are you able to test the concept fast enough? And yes, you have Slack. They can join your Slack. Uh, we can start to build simple demos in Slack. Um, and if they love it, all you have to see the heart signs, count them, and go, "Great. Let's go get this built out." Um, and then we have 10 pilot customers, and then we go from there.

    12. AGAakash Gupta29:39

        So just five years ago, that process took weeks, if not months, right?

    13. JGJayesh Govindarajan29:45

        Mm-hmm.

    14. AGAakash Gupta29:46

        Executives and product managers would go off, and they'd figure out, this is the direction. Once they got buy-in from everybody, designers would create the prototype. Then it would finally get put in front of customers. Usually, a user research team would be responsible for putting that in front of customers. So we had, like, three specialists touching a prototype and putting it in front of customers. Now engineers can do that. Should engineers be doing that? When should you have a PM or a designer or an engineer be doing these different tasks?

    15. JGJayesh Govindarajan30:23

        I mean, ideally, we have a group that is doing it with customers. It's faster. It is more durable. Um, and they each bring their perspective to design. The point is that the tools make each of them operate in each other's domains, um, up to a degree. There is, of course, specialization. This ability to abstract out, um, requirements by talking to four customers, having insight, having looked at the market, where the industry is going, that's something that the PMs, especially an experienced PM, can really bring to the table. Conversely- An engineer can just build it right the first time, and now super fast given the tools that, that are available to them. Same ditto with designer. So we each come from a place where there is a strong skill set and an experience that, that we bring to the table. What the tool set's doing is that it's saying that you're not in that silo anymore. You shouldn't box yourself in that silo. You need you, that you can go take the first step with the customer, and then pull in the expertise as needed. Um, you know, a good example, uh, here is that often you build something quickly, you get feedback on it quickly. Uh, the journey from zero to 1,000 customers is a very different journey from 1,000 to 10,000 customers, where failure modes have a significantly bigger impact when you have 10,000 customers, right? So that journey is very different, and you need different skill sets to be able to bring that, bring that into the fold. Um, would you over-engineer something for 10,000 customers day one? You wouldn't. So what this does is it basically increases the pace at which we can innovate with our customers. Innovation comes from two places. It can come from, you know, groundswell, bottoms-up innovation based on new technologies that are coming. God knows we've seen enough of that. Uh, but when that's married with the customer need that exists, which you can quickly test with customers, and that's where the magic is, and those two things kind of come together. So an engineer that has a very deep understanding of tech, uh, and has an opinion on where this, this is supposed to go, doesn't quite know whether market is there or not, can test it out. And can they bring a PM along? Sure. We're sort of, uh, designed that way. We have a Scrum team. The smallest unit of work in our organization, my team, is a Scrum team. So you have, you have a PM, you have an engineering lead, a few engineers, you have pa- you have a fractional designer, and they can go together and go get this sort of cycle sorted out pretty quickly.

    16. AGAakash Gupta32:54

        Okay, so we still have that traditional unit of a Scrum team. Has, as you're making the shift to AI native, do the ratios change or do the job descriptions change? It sounds like mainly the job descriptions change in that you're more in each other's lane, but the ratios are the same?

    17. JGJayesh Govindarajan33:11

        Um, I think it's early days. I don't think the ratios have changed a whole lot. I don't think I've seen that, seen that happen. I've seen work bleeding across, uh, a little bit, which is great. Um, and I, I expect to see more of that. Um, what I really look for is the pace of zero to one.

    18. AGAakash Gupta33:33

        Hmm.

    19. JGJayesh Govindarajan33:34

        How quickly can we go from an idea to an implementation of that idea, and is it done in vacuum? I can go from an idea to implementation really, really quickly just by myself on my laptop with no feedback from anybody. Not a great idea. Don't recommend we do that, right? But if you're gonna work with a team, if you have a set of customers, how quickly can we iterate with them? And I think our velocity has gone up significantly. We are producing more software than we ever were, and this is, this is kind of, um, a direct results, result of teams using the tools, having a democratic approach to the tools, and then bringing customers into the fold so we can iterate fast.

11. 34:15 – 38:00

    The two AI PM skills and how to hire for them

    1. AGAakash Gupta34:15

       So what I've been talking a lot about in my newsletter and podcast is how a lot of PMs need to become AI PMs.

    2. JGJayesh Govindarajan34:24

       Hmm.

    3. AGAakash Gupta34:24

       AI PMs spec- compared to a regular PM have two really important skills. Number one, AI prototyping, which you just talked about.

    4. JGJayesh Govindarajan34:33

       Mm-hmm.

    5. AGAakash Gupta34:34

       Instead of waiting on designers and engineers to create prototypes, they prompt the AI themselves in a Slack chat with the customer. They directly get feedback even before they're sharing it with a designer or engineer or UX researcher. And the second skill is AI evals-

    6. JGJayesh Govindarajan34:51

       Hmm

    7. AGAakash Gupta34:51

       ... which is that they really become the subject matter expert to define, hey, these, this is our golden data set. These are the hundred input prompts. This is what I expect the output prompt to look like. It should be this quality. This output prompt would not be at quality. This would be a eight out of 10. This would be what a 10 out of 10 output prompt looks like. Would you say that's accurate? Do, to become an AI native org, do you need to hire these PMs that have these new skills, and are those the right skills?

    8. JGJayesh Govindarajan35:20

       You are speaking my language. This is exactly the two things that are absolutely key. Um, doing that upfront, you know, really is the magic bullet. I think those, I mean, I couldn't agree with you more is the short of it. I think these two skills are invaluable in PMs. So yeah, short answer is yes. [laughs]

    9. AGAakash Gupta35:42

       So-

    10. JGJayesh Govindarajan35:42

        We need to do more of that

    11. AGAakash Gupta35:43

        ... so we've built the tool layer. People now understand the roles. To close off the role layer, how do you hire this new AI PM? What are you looking for?

    12. JGJayesh Govindarajan35:54

        One is nothing to do with technology, uh, it's agency-

    13. AGAakash Gupta35:59

        Hmm

    14. JGJayesh Govindarajan35:59

        ... uh, which I think is, is, is, is gonna be the new short supply, uh, thing. And beyond that, I would say just a deep familiarity with agentic tools and just be very agent native. Uh, what I mean by that is a mindset where you are, you're not off doing the work, but you're sort of teaching an agent to do the work. You maybe do it once and then teach an agent to do it so that from then on forward, you are super fast in how you're responding to things and, and iterating on things. So that's one sort of skill set to look for. Um, second one is some degree of skepticism with the tool set, where, uh, you, you love the power it brings, but you don't always believe it, right? The best ones craft still have that craftsmanship mindset. They're not producing AI slop. They're putting their name to it, and they do not like to put a name to something that has AI slop. AI slop comes in many different forms. You know, a prototype that looks like any other prototype, AI slop. Uh, people just checking the box by sending a really long document, AI slop. Um, so these are sort of the clear dos and don'ts. Um, I think there's no substitute for craftsmanship. There's no substitute for agency. Um, I think those are two really important things to look for. Like, do they have attention to detail is a good example of craftsmanship. Um, and then it's tooling. It is, um, how do you translate that skepticism into test cases and evals that are failing when you build the system that you're building or testing the system that you're testing? Uh, can you, can you set a bar on what good looks like? Um, because that's what translates into evals. And then like you said, I think, uh, access to all the prototyping tools, which I think is the easy bit now. I think that pretty much everyone gets.

12. 38:00 – 46:36

    ADLC vs SDLC

    1. AGAakash Gupta38:00

       Yeah. I think the tools are pretty easy. The roles we've given you some more clarity on. I think that third layer now is the life cycle that all of this is under, and I-- You created this new term, ADLC.

    2. JGJayesh Govindarajan38:12

       Yeah.

    3. AGAakash Gupta38:13

       Not the SDLC that we all know.

    4. JGJayesh Govindarajan38:14

       Uh-huh.

    5. AGAakash Gupta38:15

       So can you define those two terms for us and explain to us what makes the ADLC different?

    6. JGJayesh Govindarajan38:20

       Sure. Um, so, um, S- SDLC is the software development life cycle, which, uh, we all know and love that have been building software for years. Um, ADLC is an equivalent for the agentic world, the, the agent development life cycle, if you will. What is the life-- If, if the software you're producing is not just a deterministic piece of software but is an agent, what does-- how do you build it? How do you test it? How do you evaluate it? How do you deploy it? And then having deployed it, how do you observe it so that it continually improves? Right? So this, these five elements are, you know, taken together is what I call the ADLC life cycle. The holy grail, of course, is an agent that you've built and it's in production and can self-heal to some extent. And I'm not talking some fancy rocket science, um, sci-fi stuff on self-healing. I mean simple things, like you have an agent that's working fine in production and starts to drift a little bit. Why does it start to drift? Because it's grounded on some data, uh, on refund policies that just got changed. But somebody wrote it in a way that, uh, it's not very clear. Somebody updated the document. The agent's not working. The re- the refund, or you're sending refund checks that are bigger than, than the, than the amount that was needed. Can it self-heal? It can. Um, it needs to detect what context was changed, whether that context was changed the right way or wrong way. Um, that's the knob that you wanna get to. You wanna get to a point where if you've designed this right, there are two loops. There's the inner loop, which is you conjuring up an agent from your imagination, working with the customer to s- to make, to make sure that that's what they want, and then going and building it off, and then deploying it in that environment. And the outer loop, that journey starts once the customer starts to use the agent. What is the life cycle once an agent is live? Uh, how do you evaluate in production? Uh, how do you, you know, update the agent in production? What does that loop look like? That requires a completely new set of tools that haven't been built, you know, built or imagined. We're starting to see some of that come in. Uh, but our, in, in, in our world, that looks like a testing center for agent. That looks like an observability center for agent. That looks like a... We launched this at Dreamforce yesterday. It's called optimization agent. It's the one that looks at the, all the agents in your, uh, Agentforce agents that are running in the org and, and looks for opportunities to optimize, maybe by adding new context or refining a prompt that is not working great. So think of this agent as like this, this ob- agent that's observing all the agents and, like, looking to optimize. So that's kinda what I mean by the ADLC life cycle, kind of playing o- on words with the software development life cycle a little bit.

    7. AGAakash Gupta41:08

       Does the ADLC only apply then if you're building agents?

    8. JGJayesh Govindarajan41:12

       I think, I think it's broader than that. I think it, it has to do with an AI development life cycle, which has an eval mindset baked in, which understands that anything built on data can drift because data can drift, because data itself drifts. Um, and then having the right tool sets to, to observe that n- that drift in production and see if that drift can be corrected in production. Large scale AI systems predating agentic systems have this in droves. Like if you look at search, the search algorithm that Google runs or any other company runs, a recommender system that run, they have all of these, you know, knobs built in and pre, uh, pre-built and tuned. We are pulling all of that out and making it available at scale in this new agentic era because everyone's building agents for doing things, and now they need this skill set to be able to evaluate these agents, to be able to make sure that they work, to be able to observe them, to be able to understand what is drifting, to be able to be told what's drifting and, and then bring the human in to correct it, to steer it, if you will.

    9. AGAakash Gupta42:18

       So it sounds like part of what is involved in the ADLC is moving a lot faster. If you were on a six-month ship cycle, it sounds like you need to almost go to a continuous deployment-

    10. JGJayesh Govindarajan42:33

        Yes

    11. AGAakash Gupta42:33

        ... it can self-heal whenever it wants cycle.

    12. JGJayesh Govindarajan42:35

        Yeah. And I think there's a very good reason why the pace is this way, is because often the substrate layer things that you build on don't change as fast as they are today. Now think about it this way. We've built software for decades, and the substrate layer for most software is a database. How often has the database changed? How often has the programming language to program the database changed? Hardly ever. SQL still exists. Um, we are in a world where the substrate layer is a model itself, and it's not staying still. It is evolving at a very rapid rate. The changes between what we saw, you know, in, in the, in the current version of Claude and the previous version of Claude is significant, right? So you have to... So what happens to all the agents that you built that worked great on the previous one? You need to evolve them. You need to simplify them, and there are certain dimensions on which s- which you need to simplify. Imagine being able to do that with no ADLC. You have no test cases, no evals. How are you gonna go flip the... You're gonna, y- you're just gonna... If you didn't have all of that infrastructure built, the rate at which you move, the hugging of the tangent, if you will, it's not happening because you're mortally afraid of breaking something. Um, but if you do, on the other hand, you can really go fast, and that's the mindset change.

    13. AGAakash Gupta44:06

        Hmm. Everything downstream has to change though then, right? Your product marketing, your customer support, everybody has to shift to this much more agile way of working. Some companies are still stuck in the past, right? They're still shipping every couple months. How does a company go from zero to 100, it feels like? [laughs]

    14. JGJayesh Govindarajan44:26

        Yeah.

    15. AGAakash Gupta44:26

        How do they just completely turn around, and how did you guys do it?

    16. JGJayesh Govindarajan44:29

        Yeah, I think the first thing is, uh, uh, I think you nailed it. Uh, you have to be building and releasing continuously. Um, you have to be doing that in discrete chunks that matter to customers. At the end of the day, we're shipping something that we want to have impact with customers, that adds value to customers. Release is a, just a packaging mechanism, is all it is. From every scrum team needs to be pushing code and making changes to code as rapidly as they can, as safely as they can, right? This is the trade-off. The trade-off is you don't wanna break systems, right? If all you're gonna do is iterate rapidly, once you have the kind of customer base that Salesforce has, things start to break, and then that slows you down even further. You wanna be able to balance and do both.

    17. AGAakash Gupta45:19

        Yeah.

    18. JGJayesh Govindarajan45:19

        Move fast in the same-

    19. AGAakash Gupta45:20

        People used to create lots of tech debt when they would switch to this way.

    20. JGJayesh Govindarajan45:23

        Yeah, yeah, and often, like I, I tell, I tell our PMs, like, if you have tech debt on your teams, that's still your problem because you're gonna eventually slow down, and you won't know why because your engineers are fixing problems.

    21. AGAakash Gupta45:37

        Mm-hmm.

    22. JGJayesh Govindarajan45:38

        And that means every engineer that's fixing a problem is not adding a new feature that the customer loves. So taking in, taking that into account, you have to account for what that means from a tech debt perspective. But for the first time, we can have agents help with tech debt too.

    23. AGAakash Gupta45:52

        Mm-hmm.

    24. JGJayesh Govindarajan45:53

        Right? Like, how do you build this, like, this work we do with, with our amazing security team, this work we do with our, our release management teams for building agents that are specialized, that do code reviews. What's, how do you pull a PR, a high quality PR really fast? Um, what are the bottlenecks? The bottlenecks, bottleneck is no longer writing code. The bottleneck is writing quality code, writing code that works all the time, having the test cases that fail before it hits production.

    25. AGAakash Gupta46:24

        Hmm.

    26. JGJayesh Govindarajan46:25

        Right? These are now the bottlenecks, each of which, if you go really deep, you can start to build agents for and speed up by itself. Um, so yeah.

    27. AGAakash Gupta46:35

        Okay.

13. 46:36 – 52:29

    Roadmapping with forward deployed teams

    1. AGAakash Gupta46:36

       So I think we covered the life cycle. I think the very last component at the very top of the pyramid is probably where you spend a lot of your time.

    2. JGJayesh Govindarajan46:44

       Mm-hmm.

    3. AGAakash Gupta46:45

       How engineers, product managers, and executives who are really setting the strategy of what we're working on collaborate to build a roadmap.

    4. JGJayesh Govindarajan46:54

       Mm-hmm.

    5. AGAakash Gupta46:54

       So h- what does that process look like? What does the planning process look like in this AI native organization? What do the different roles own?

    6. JGJayesh Govindarajan47:03

       Uh, great question. So, um, let me take a step back first. I think at a high level, I'd say taste, judgment play a much bigger part than they did before. That's what forms the intuition on the, the broad vector along which you wanna move the organization, the team, the product. But I said broad vector. It's not, it's not a, a straight line, right? It's a broad direction. And then once you know what the broad direction looks like, you get a lot more refined using two mechanics. Mechanic number one is just getting customer feedback early in whatever it is that you're building, and that, that feedback, as we determined earlier, isn't that hard to get anymore in a very visceral way. You can just put a prototype in front of them now. It didn't use -- You don't have to have seven meetings where you're describing the idea. That is one dimension of, of getting that vector right. The second dimension is existing products that are in the market that are being used by customers, and they're loving it, but they have some gaps. This is where sort of a forward deployed teams are, are incredibly useful in how they work with customers, uh, not just to make them successful, but they are the first line of defense and see what our customers see. Uh, and because they're closer to product and they're, they're part of the product, and I have customer facing engineers that work directly with customers, they bring back all kinds of feedback from paper cut type things that shouldn't exist in the product, we should just fix it, to, oh, the way we thought about this particular feature doesn't seem right because I worked with three customers, and they seem to be struggling. So yes, we did assign that vector the right way by talking to customers, but when it met- meets the real world, there are some gaps that need to be tuned or maybe some things need to be thought through. Now imagine doing this at scale across many, many, many, many different teams, and you get, get a, get a picture of what, you know, how that sort of looks like. But I feel like those are, those are key things that we need to organize as a team. And from, from our perspective, as I said, we are in Slack all the time. We have great tools that summarize all of this, you know, roll this, roll this up. We have fantastic reports that show up, um- We have a channel where all FDEs basically post exactly what's happening with the customer, what their pain points are, and is it a paper cut or is it a feature request? And we have PMs and engineering leaders looking at it all the time, uh, and matching it against their roadmap, uh, and seeing if something needs to change or, or we need to jump onto the customer side. We're working more with customers than we ever did before.

    7. AGAakash Gupta49:47

       I want to return to that role layer, 'cause you brought up the forward deployed engineer.

    8. JGJayesh Govindarajan49:51

       Mm-hmm.

    9. AGAakash Gupta49:52

       It's got to be the hottest, sexiest-

    10. JGJayesh Govindarajan49:55

        [laughs]

    11. AGAakash Gupta49:55

        ... new role in tech, and for my audience, it's the forward deployed product manager-

    12. JGJayesh Govindarajan50:01

        Uh-huh

    13. AGAakash Gupta50:01

        ... that's super interesting to them. What do you, what do you see-- Are these roles replacing the traditional? Are they a supplement? How do they fit in to the broader picture we just described of engineer, designer, PM?

    14. JGJayesh Govindarajan50:14

        Yeah. I think the reason the role exists is because we are deploying sophisticated technology and evolving that technology at a very fast pace. The pace at which we're building is not the pace at which the technology is being diffused, so we're solving it with, with expert humans in the middle. We are trying to catch up our customers, and we're trying to catch up the diffusion rate of technology with the customer base in a way that adds value to them, so it's righteous in that way, to the pace at which we're innovating within the company. That's the gap, and that's what we're trying to fill with, uh, you know, fill with, with, um, with forward deployed engineers, PMs, designers, whatever. Um, broadly, I think what that means is the main skill is twofold. One, really being able to immerse oneself into the customer's pain point. They bought us to solve a problem, and then falling in love with that problem, and then helping the customer solve it using the tool sets that are available to them. And often, maybe the tool sets are not sufficient. That's okay. We should have the f- the, the forward deployment has the freedom to go find some other bit and be able to plug it in to make the whole work, and we've done that many times. Sometimes we build something custom with them and then bake that into product, right? So do we need PMs there? Yes, because we just designed something custom with them. It'd be nice to have PM input on that, um, which has the added benefit at roadmap planning to see whether that thing was really custom or do we think that all customers would need it. Uh, and if all customers ne- would need it, how about we take a prototype, we already have one, and take it out to c- a bunch of customers and get feedback on it.

    15. AGAakash Gupta52:00

        Mm.

    16. JGJayesh Govindarajan52:00

        Right? So this sort of cycle of getting feedback in, bringing in PMs, designing it directly with a designer, uh, or an engineer just, like, working with a customer to go get it built out, making them successful is really the lens that is different.

    17. AGAakash Gupta52:16

        So what I'm hearing is that the forward deployed group is almost, like, doing a lot of this rapid prototyping on a custom scale, and then it brings it back to the core group to decide if we want to build it in the product for everyone. Is that right?

14. 52:29 – 57:19

    Biggest mistakes in AI transformations

    1. JGJayesh Govindarajan52:29

       That's right.

    2. AGAakash Gupta52:30

       Okay. So you get to see a lot of customers who are going through this transformation from not AI native to AI native. They're basically hiring Agentforce to help them along that journey. What are the biggest mistakes that somebody who's watching this should keep in mind so that they can avoid those in their implementation?

    3. JGJayesh Govindarajan52:53

       Hmm. I'm a big believer in start simple. Uh, I'm a big believer in define value, then define metrics to capture that value, and call it your ROI metric, and get it built out end to end, scale it out, uh, scale one, and then scale all. Often implementations don't take this, uh, this flavor. It starts off as a whole full company transformation story and then very quickly, you know, has, you know, breaks out into this massive plan across the board and creates a lot of pressure on the teams that are implementing, even customers that are trying to derive value. So, um, I think, you know, one piece of advice I have always is, uh, start with your hardest problem. That's okay. But be very clear about what value is gonna look like, and then break it down into, we've talked about this before, clear ROI metrics, clear scorers on the agent, clear evals on the agent that tie to value and ROI. And once a team is successful at building it, keep in mind, this is technology that ha- that has, that we have kind of built ourselves, so it's easier for us. But when I look at others building agents, that tech- I get the sense the technology isn't fully diffused. The teams that are implementing still need a lot of enablement, and what that means is starting with one success under the belt is super important. I'd say that, uh, that is one key thing. The other one I'd say is, um, there are a lot of variables when it comes to building the system. What models do we use underlying? You know, should one train their own models? Uh, should one start with a harness? Uh, what is the role of implementing the right context? Uh, there are a lot of variables. And, uh, and I'm also a big believer in, in saying that the very first implementation, minimize the variables. Get the work done in the simplest way possible, Occam's razor, and then start to ask about what are the ways to make it more efficient. And, and there are many, right? Uh, the best ones that we work with start with two or three really critical implementations, get them right, and then they just go wall to wall with Agentforce. Uh, Deco, uh, Mark, they were in Mark's keynote, and they're one, one of the customers I work with very, very closely. They had, they're wall to wall Agentforce agents, all the way from the recruiting company based in, uh, in Europe, one of the largest recruiting companies in Europe. They have pre-screening automated with a, with an agent that calls you, and you can take a interview on, on a phone call. Uh, keep state, can ask questions, um, um, uh, escalate to human, all of that baked in. They started with text, wall-to-wall, 17 different languages. They deployed across Europe, um, and now they're going voice. So that's a good example of, of what setting a high bar, but starting with one or two use cases, and really going all the way, and then expanding and going wall to wall looks like.

    4. AGAakash Gupta55:53

       This has been a masterclass. Thank you. If people wanna learn more about building an AI native product team and organization, where can they find you online?

    5. JGJayesh Govindarajan56:02

       Online, I am on LinkedIn. You can find me on LinkedIn. I'm on Twitter, Jay. And of course, you can find all about Agentforce on salesforce.com. It's where I live pretty much all the time. [laughs]

    6. AGAakash Gupta56:14

       All right. Jayesh, thank you so much-

    7. JGJayesh Govindarajan56:16

       Thank you. My pleasure

    8. AGAakash Gupta56:16

       ... for being on the podcast.

    9. JGJayesh Govindarajan56:18

       Absolutely. My pleasure.

    10. AGAakash Gupta56:19

        All right. Okay. See you guys next time. I hope you learned as much from today's episode as I did. If you can do one thing that's totally free that would help the show, it would be to check that you're following on Apple and Spotify Podcasts, check that you've left ratings and reviews on those platforms, check that you're subscribed on YouTube, leave a like and a comment on this video, and then share it with your friends. We're trying to make better and better podcasts. After two years, we think we've gotten something pretty good going, so let us know what we can do to make it even better, who else we should interview, and we will put on the best shows we possibly can. Finally, don't forget my offer for the bundle. You get an entire year of my paid newsletter, plus my favorite AI tools, Bolt.new, Airtable, Speechify, Descript, Magic Patterns, Linear, Dovetail, Arise, and Mobbin'. That's $27,000 worth of value for just $150. So check that out at bundle.aakashgee.com if it interests you, and I can't wait to share our next episode soon

Episode duration: 57:29