Check out the conversation on Apple, Spotify and YouTube.
Meet Jayesh Govindarajan (01:40)
Aakash: 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, 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.
Jayesh: Thank you. It’s a pleasure to be here.
Inside Salesforce’s AI org and how agentic coding changed it (02:19)
Aakash: 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?
Jayesh: Sure. So I lead the broader AI engineering org at Salesforce. What that means is we set the strategy and direction, and 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 and enable our customers to change how they work, using predictive AI at its core, generative AI at its core, and now building agents for many, many of our customers.
Aakash: 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?
Jayesh: That’s a great question. I’ll color this based on what we’re doing at Salesforce, how we’re organized, how we’re structured. I think there’s no better example of an AI native team than one that is building the foundation of an agentic system that customers use to build their agents on.
So broadly, the last two and a half, three years have been an incredible whirlwind of agentic systems, as our customers have sought to become an agentic enterprise. And underlying all of that is Agentforce, which is our harness that we built about two years ago, before the name harness came along.
So from an AI native perspective, the team is structured to be able to build harnesses, to be able to build models, to be able to use these models in the context of a harness. And then, and I’ll talk more about this later, there’s this emerging life cycle of an agentic system that we like to call ADLC. 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? These are tools and systems that we build that our customers use to go build their own agents for the scenarios and use cases they have.
Aakash: 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?
Jayesh: 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.
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 and relying on, and partnering with frontier labs such as OpenAI, who is a great partner of ours, Anthropic and Gemini. That world looks a certain way.
Then there is a team that is moving really fast in building the harness technologies. That’s how context gets engineered into an agent, how tool calling happens within an agentic framework. 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.
And then there’s the very new and emerging agent development life cycle. How do you build agents? 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 correct it? How do you bring that whole system back?
Those are the three big layers, and if you look at my org chart, that’s what it looks like. I have a team that’s responsible for the model layer, called the AI platform team. There’s a team above that which is building harnesses and memory systems for harnesses. And there’s a team on top of that which is the whole ADLC and agent optimization team.
All three teams are working very differently than they were before. We are obviously very AI-native here. Within our team, we use Claude, we use Codex for our development processes. We are all in Slack all the time. That is really our primary interface for how we work together with each other, how work gets done within a team and across teams.
Increasingly, we are bringing some of our customers into Slack too, using this feature called Slack Connect, where they can actually work with us directly on a project. That’s the communication part that’s changed considerably, with Slack at its core. One of the great things about Slack is you can basically bring in your agents to come do work on your behalf, and we’ll get into more of that.
But at a high level, our world has changed in every aspect. How we design products. How we work with customers on iterating on what they need us to build. How we get feedback from them, and then how we break that into tasks, and then how we get agents to help us with some of these tasks.
Broadly, in one sentence, I’d say we’ve had people change how they think about work. And that change, in essence, is how do you manage a team of agents versus doing the work by hand, if that makes sense.
How to pick and roll out AI tools (09:30)
Aakash: You mentioned a bunch of tools there, so I want to dive deeper on those tools 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? You talked about orchestrating agents. The new craze right now is likely OpenClaw or Hermes. So when you’re evaluating whether to bring that into your organization, what is the thought process you’re going through?
Jayesh: Yeah. So firstly, we have to acknowledge that tools are moving at a rate that is unprecedented. There’s no doubt about that. What that implies is that one cannot make a bet forever, right? You need to make bets, and you need to give them some space to play out. And then you need to back something and push that tool and technology through, but remain open to change.
As an example, we started off using Cursor. That was the primary interface of choice for engineers. Then Claude happened, and this family of agents doing work, talking to each other, getting it done. In particular, Claude Code, the harness for coding, became something that our engineers loved using.
The way I look at this is you need to give people a choice to pick the tool they want. Often the best engineers and the best PMs pick the best tools to get the job done. And then you look at data. You look at what’s actually driving adoption. And then you lean towards the best practices which emerge from real usage on a daily basis.
Aakash: So it sounds like you’re in the camp that doesn’t prescribe, okay guys, we’re all going to use Claude Code now. Give people access to multiple sets of tools, whether that’s Codex, Claude Code or 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?
Jayesh: Be very, very careful about corporate security, but be open about the tools that are given to users as choice. Every single tool in the Salesforce ecosystem has to go through security. So we make sure that all the security criteria are met, but then we give our teams a choice for a while, and we watch to see what works. Often the best practices emerge from real usage.
And as I said, things keep changing. From an engineering perspective, I don’t think the IDE of choice changed in a decade. The tools that PMs have used, Excel, Docs, Google Docs, Figma, haven’t changed a whole lot in the last decade or so. But now they have. And not only have they changed, the change isn’t singular. It’s going to keep evolving.
So you need to think of not just where you are on the graph but what the slope looks like, and try to hug the tangent as the slope changes continuously. 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 available. Then watch what works and what doesn’t. That has served us quite well.
Headless Salesforce inside Claude (12:56)
Aakash: One of the most interesting things that I think Salesforce has done recently is this idea of being headless, and you guys just recently announced Claude Force.
Jayesh: Yes.
Aakash: So basically, your users for your $50 or $60 billion revenue business 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, 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 more inside of these centralized operating systems, whether that’s Claude or Slack?
Jayesh: Liberating, in one word. 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. So when we say headless, all of the metadata, all of the business logic, is actually captured in the API.
When Claude came along, it was really an unshackling of these subsystems that do powerful things. Understanding what the flow of a sales process looks like that ends up with a 70% probability of a close. Or what a ticket resolution looks like that has an 80% chance of being resolved successfully, with the 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. They’ve customized it for their own needs.
What headless does is it lets our customers bring that into Claude using skills that we wrap around these, and basically use it in any context that they want. So Claude is doing this bit of bringing all of these things together into Claude Force, with the ability to build an interface that is very custom for their need.
Again, the magic was never just in the user interface. It was what was underlying the user interface. What Claude basically does is help you code one up for your bespoke need, which is very specific to what you want to do, and you’re using the same technology in the back.
Getting ground truth from probabilistic AI (15:14)
Aakash: So what I want to do is build people a recipe for becoming more AI native. We talked a little bit about how you need to hug the tangent of how tools are evolving. Then we talked about how you need to let people operate inside these centralized tools like Claude and Slack.
The first 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, when Salesforce is identifying how much open pipeline you have, there are clear data fields that it’s referencing. But we all know LLMs can be probabilistic. They can have variations. And you can’t really have two pipeline numbers, right? You can’t have 25 million and 20 million. Which one is it? You actually need to know. So if people are moving into these tools, how do you build the harness the right way, or use Claude or Slack the right way, so that you can get to a ground truth?
Jayesh: Yeah. So with Agentforce, we saw this need arise just as soon as we launched. This need to bring some degree of control and determinism to an agent specification.
What does that look like? It looks like a language that you can describe your agent in, which then translates into tool calls. It translates into context lookups. And it translates into reduced hallucination, because it’s relying on tool calls. We designed a language around it called Agent Script.
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 getting the right context in the right place. That reduces hallucination rates by a massive amount, because you’re not using Claude to generate code when there is already a piece of code and an API that does exactly what you want, deterministically, every time. Tried, tested and good to go. You are still using Claude to bring the right systems together for that task, right?
That’s the magic. In the agentic world with Agentforce, you can bring in more than that. You can bring in a set of controls with Agent Script to pull all of that together.
Aakash: So in our recipe card, it sounds like what’s really important is giving the connections to the right data, but on top of that, defining how those tool calls work and building the right skill files, so that when Claude makes those tool calls, it does it correctly.
Jayesh: Perfectly right. One other thing I would add, which is a really important insight we gleaned along the way. 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 then moved into the agentic world. They are what I call eval native. They look at a system probabilistically. They understand that it’s not going to work all the time. So test cases or evals tied to outcomes are a superpower.
And there are other teams that are more code focused, engineering focused. They’ve built the infrastructure. They’ve always worked in the deterministic world.
Earlier you asked what big changes I’m seeing with the teams. This is one of them. We’re seeing a lot of people becoming eval first. That means thinking through not just the test cases but outcomes, and having custom scorers that use both LLMs and other models to score the output. These are not generic. They are very specific to the agent you’re building or the code you’re writing.
This is a cultural shift. It is a tool set shift. It is a mindset shift in how you design software that is probabilistic when you want it to work every time. So I’d add one more, which is the eval part around it.
Why Slack is the AI native work hub (19:22)
Aakash: Let’s circle back to evals in a second. I want to close the tools component of this with Slack.
Jayesh: Yeah.
Aakash: Because I’d say a lot of people listening who are trying to build an AI native organization are probably still stuck in the Microsoft Teams world. They don’t even understand why Slack is important or what it enables. As far as I understand it, people are spending 50 or 60% of their time in Slack now, whereas before it might have been in an IDE. So how do you get that setup correct, and what is involved in that setup so that you’re doing so much out of Slack?
Jayesh: That’s a great question. I use Slack every day and I am just a mad fanboy.
So two things. One is, what’s the one place where people are available asynchronously all the time? In most enterprises, it’s Slack. That’s where people are. That’s where work is organized. That’s where conversations around work are organized. That context is gold dust, especially taken longitudinally over a long period of time. That is the missing piece that’s needed for getting something done.
Serendipitous discovery is possible in such a system. Slack will routinely find someone who has the answer in some public channel that I had no idea existed. And that’s context for an agent to work on.
So what does the tool set look like? It looks like a great implementation of Slack within the organization. A Slack where people are using it every day, with super high utilization, leaving a lot of data traces behind. And then it’s plugging this agentic tool set into Slack.
We ship with one that is magical, called Slackbot. If you haven’t used it, please do. You can ask it questions. It can orchestrate other agents for you. It can bring you the right people. It can send emails. It can send other Slack messages. So you’re basically building your agentic work environment within Slack. And you can bring in third-party agents as well. So that’s the tool set.
From a developer perspective, we use Slack quite a bit for simple apps. You can write the spec there and you can actually build a simple UI in there. How cool is it for a PM to be able to create a small mock in a Slack thread with their customer and just ask them, is this what you had in mind? Versus writing a PRD, getting an engineer to go build it, creating a link for it and sending it back to the customer. The customer looks at it and goes, not really what I want. This whole cycle is sped up exponentially, and it’s just a joy to work this way.
The future of the product trio (25:45)
Aakash: So I’m trying to build this recipe card, and I feel like at the base we’ve covered that tool layer, right? The next layer is roles, and you just talked about it with PMs, and you also referred to it with evals. A lot of people are wondering what the future of the product trio is. The PM, designer and engineer roles all seem to be converging on top of each other. We humans are notoriously bad at predictions, but what are you seeing on the ground right now? When you’re staffing up a product team, do you need as many PMs as before, as many designers as before? How are you thinking about that?
Jayesh: Well, that’s a big question, and I think it’s a really important one. Having been an entrepreneur, the one thing that becomes very clear to you is that these lines that we draw don’t really exist. We create them in our own heads, and then we specialize around them. So they do become real after a point.
What the tool sets available to us, what the large language models and 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, take an engineer that has a customer-first mindset, and many do. Many don’t want to build systems that are never going to see the light of day. They want to put their heart and soul into things that have an impact, that customers will use every day. How can they test that? Well, if they have customers that they can work with directly, they can start putting products in front of them and get direct feedback. Do you need a middleman? I don’t think so.
Conversely, if you’re a PM, your bottleneck may be waiting for that engineer. You’ve logged the request, written a PRD, and the engineer is working on something that was written before, and you’re waiting. You don’t have to wait anymore. The product development life cycle can be sped up significantly. Now the bottleneck is, can you find customers fast enough, and can you get to concept market fit and product market fit quickly?
One of the great things about working at Salesforce, and I truly believe this, you’ve seen it here, is the energy here at Dreamforce. We just have incredibly loyal customers, and we couldn’t be more thankful for that. You’ve seen the Trailblazers who have come here. Who are these people? These are people who started out in fairly junior roles, implemented Salesforce, grew with the company, and now are customer service officers of their companies. Tremendous loyalty.
It’s really easy for us to go talk to them, because of the trust Salesforce has built over decades, and say, hey, we’ve built something, we want some feedback, will you try it? It’s super easy for us to get 10 pilot customers for anything we do. And they have the 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 that bottleneck, where you need to go find customers, is completely nonexistent at 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. We can start to build simple demos in Slack. If they love it, you see the hard signs, count them, and go, great, let’s go get this built out. Then we have 10 pilot customers, and we go from there.
Aakash: Just five years ago that process took weeks, if not months, right? Executives and product managers would go off and figure out 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 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 doing these different tasks?
Jayesh: Ideally, we have a group that is doing it with customers. It’s faster. It’s more durable. And they each bring their perspective to design. The point is that the tools let each of them operate in each other’s domains, up to a degree.
There is of course specialization. The ability to abstract out requirements by talking to four customers, having insight, having looked at the market and where the industry is going. That’s something 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 available to them. We each come from a place where there is a strong skill set and experience that we bring to the table.
What the tool set is doing is saying you’re not in that silo anymore. You shouldn’t box yourself into that silo. You can go take the first step with the customer and then pull in the expertise as needed.
A good example here is that often you build something quickly and get feedback on it quickly. The journey from zero to 1,000 customers is very different from the journey from 1,000 to 10,000 customers, where failure modes have a significantly bigger impact. So you need different skill sets to bring into the fold. Would you over-engineer something for 10,000 customers on day one? You wouldn’t.
So what this does is increase the pace at which we can innovate with our customers. Innovation comes from two places. It can come from groundswell, bottoms-up innovation based on new technologies that are coming, and God knows we’ve seen enough of that. But when that’s married with a customer need that exists, which you can quickly test with customers, that’s where the magic is.
So an engineer who has a very deep understanding of the tech and an opinion on where it’s supposed to go, but doesn’t quite know whether the market is there or not, can test it out. Can they bring a PM along? Sure. We’re designed that way. We have a scrum team as the smallest unit of work in our organization. You have a PM, an engineering lead, a few engineers and a fractional designer, and they can go together and get this cycle sorted out pretty quickly.
Aakash: Okay, so we still have that traditional unit of a scrum team. 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 and you’re more in each other’s lane, but the ratios are the same.
Jayesh: I think it’s early days. I don’t think ratios have changed a whole lot. I haven’t seen that happen. I’ve seen work bleeding across a little bit, which is great, and I expect to see more of that.
What I really look for is the pace of zero to one. How quickly can we go from an idea to an implementation of that idea? And is it done in a vacuum? I can go from an idea to implementation really quickly 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 going to work with a team, and you have a set of customers, how quickly can we iterate with them?
I think our velocity has gone up significantly. We are producing more software than we ever were. That is a direct result of using the tools, having a democratic approach to the tools, and bringing customers into the fold so you can iterate fast.
The two AI PM skills and how to hire for them (34:15)
Aakash: What I’ve been talking about a lot in my newsletter and podcast is how a lot of PMs need to become AI PMs. AI PMs, compared to a regular PM, have two really important skills.
Number one, AI prototyping, which you just talked about. 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.
The second skill is AI evals. They really become the subject matter expert who defines, hey, this is our golden data set. These are the 100 input prompts. This is what I expect the output to look like. It should be this quality. This output would not be at quality. This would be an 8 out of 10. This is what a 10 out of 10 output looks like.
Would you say that’s accurate? To become AI native, do you need to hire PMs who have these new skills? And are those the right skills?
Jayesh: You are speaking my language. These are exactly the two things that are absolutely key. Doing that upfront really is the magic bullet. I couldn’t agree with you more, is the short of it. These two skills are invaluable in PMs. So yes, the short answer is yes. We need to do more of that.
Aakash: So we’ve built the tool layer, and people now understand the roles. To close off the role layer, how do you hire this new AI PM? What are you looking for?
Jayesh: One has nothing to do with technology. It’s agency, which I think is going to be the new thing in short supply.
Beyond that, I would say a deep familiarity with agentic tools, and being very agent native. What I mean by that is a mindset where you’re not off doing the work, you’re 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 you are super fast in how you respond to things and iterate on things. So that’s one skill set to look for.
The second one is some degree of skepticism with the tool set, where you love the power it brings but you don’t always believe it, right? The best ones 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 their name to something that has AI slop.
AI slop comes in many different forms. A prototype that looks like any other prototype is AI slop. People checking the box by sending you a really long document is AI slop. So there are clear dos and don’ts. There’s no substitute for craftsmanship. There’s no substitute for agency. Those are two really important things to look for. Do they have attention to detail? That’s a good example of craftsmanship.
And then it’s tooling. How do you translate that skepticism into test cases and evals that fail when you build or test the system you’re working on? Can you set a bar on what good looks like? Because that’s what translates into evals.
And then, like you said, access to all the prototyping tools, which I think is the easy bit now. Pretty much everyone gets that.
ADLC vs SDLC (38:00)
Aakash: Yeah, I think the tools are pretty easy, and we’ve given you some more clarity on the roles. That third layer now is the life cycle that all of this sits under. You created this new term, ADLC, not the SDLC that we all know. Can you define those two terms for us and explain what makes the ADLC different?
Jayesh: Sure. SDLC is the software development life cycle, which those of us who have been building software for years all know and love. ADLC is the equivalent for the agentic world, the agent development life cycle, if you will.
If the software you’re producing is not just a deterministic 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? And then, having deployed it, how do you observe it so that it continually improves? These five elements taken together are what I call the ADLC.
The holy grail, of course, is an agent that you’ve built, that’s in production and can self-heal to some extent. I’m not talking about some fancy rocket science, sci-fi stuff on self-healing. I mean simple things. You have an agent that’s working fine in production, and it starts to drift a little bit. Why does it start to drift? Because it’s grounded on some data on refund policies that just got changed, and somebody wrote it in a way that’s not very clear. Somebody updated the document, and now the agent’s not working. You’re sending refund checks that are bigger than the amount that was needed.
Can it self-heal? It can. It needs to detect what context was changed, and whether that context was changed the right way or the wrong way. That’s the knob you want to get to.
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 make sure that’s what they want, then building it out and deploying it in their environment.
The outer loop starts once the customer starts to use the agent. What is the life cycle once an agent is live? How do you evaluate it in production? How do you update the agent in production? What does that loop look like? That requires a completely new set of tools that haven’t been built or even imagined yet. We’re starting to see some of that come in.
In our world, that looks like a testing center for agents. That looks like an observability center for agents. And we launched something at Dreamforce yesterday called the optimization agent. It looks at all the Agentforce agents running in your org and looks for opportunities to optimize them, maybe by adding new context or refining a prompt that isn’t working well. So think of it as an agent that observes all the other agents and looks to optimize them. That’s what I mean by the ADLC, playing on words with the software development life cycle a little bit.
Aakash: Does the ADLC only apply if you’re building agents?
Jayesh: I think it’s broader than that. It has to do with an AI development life cycle that has an eval mindset baked in. One that understands anything built on data can drift, because data itself drifts. And then having the right tool sets to observe that drift in production and see if it can be corrected in production.
Large-scale AI systems that predate agentic systems have this in spades]. If you look at search, the search algorithm that Google or any other company runs, or a recommender system, they have all of these knobs pre-built and tuned. We are pulling all of that out and making it available at scale in this new agentic era. Everyone’s building agents for doing things, and now they need this skill set. To evaluate these agents. To make sure they work. To observe them. To understand what is drifting, to be told what’s drifting, and then bring the human in to correct it, to steer it, if you will.
Aakash: So it sounds like part of what’s 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 cycle, where it can self-heal whenever it wants.
Jayesh: Yeah. And there’s a very good reason why the pace is this way. Often the substrate layer, the things that you build on, didn’t change as fast as it does today.
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.
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 the current version of Claude and the previous version of Claude are significant, right? So what happens to all the agents 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 you need to simplify.
Imagine being able to do that with no ADLC. You have no test cases, no evals. If you didn’t have all of that infrastructure built, the hugging of the tangent, if you will, is not happening, because you’re mortally afraid of breaking something. But if you do have it, you can really go fast. That’s the mindset change.
Aakash: Everything downstream has to change 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. They’re still shipping every couple of months. How does a company go from zero to 100? How did they completely turn around, and how did you guys do it?
Jayesh: Yeah, I think you nailed it. You have to be building and releasing continuously. 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. A release is just a packaging mechanism, is all it is.
Every scrum team needs to be pushing code and making changes to code as rapidly as they can, as safely as they can. That’s the trade-off. You don’t want to break systems. If all you do is iterate rapidly, once you have the kind of customer base that Salesforce has, things start to break, and that slows you down even further. You want to be able to balance both and move fast.
Aakash: People used to create lots of tech debt when they would switch to this way.
Jayesh: Yeah. And I often tell our PMs, if you have tech debt on your teams, that’s still your problem. You’re going to eventually slow down, and you won’t know why, because your engineers are fixing problems. Every engineer that’s fixing a problem is not adding a new feature that the customer loves. So you have to account for what that means from a tech debt perspective.
But for the first time, we can have agents help protect that too, right? There’s work we do with our amazing security team. There’s work we do with our release management teams on building specialized agents that do code reviews. How do you put up a high-quality PR really fast? What are the bottlenecks? The 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. These are now the bottlenecks, and if you go really deep on each of them, you can start to build agents to speed it up.
Roadmapping with forward deployed teams (46:36)
Aakash: Okay, so I think we covered the life cycle. 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 the executives who are setting the strategy collaborate to build a roadmap. What does that process look like? What does the planning process look like in this AI native organization? What do the different roles own?
Jayesh: Great question. Let me take a step back first. At a high level, I’d say taste and judgment play a much bigger part than they did before. That’s what forms the intuition on the broad vector along which you want to move the organization, the team, the product. But I said broad vector. It’s not a straight line, right? It’s a broad direction.
Once you know what the broad direction looks like, you get a lot more refined using two mechanics.
Mechanic number one is getting customer feedback early in whatever you’re building. As we determined earlier, that feedback isn’t that hard to get anymore, in a very visceral way. You can just put a prototype in front of them. You don’t have to have seven meetings where you’re describing the idea. That’s one dimension of getting the vector right.
The second dimension is existing products that are in the market, being used by customers who love them, but that have some gaps. This is where forward deployed teams are incredibly useful in how they work with customers. Not just to make them successful. They are the first line of defense, and they see what our customers see. And because they’re closer to product, they’re part of the product.
I have customer-facing engineers who work directly with customers. They bring back all kinds of feedback. From paper-cut type things that shouldn’t exist in the product, that we should just fix, to, the way we thought about this particular feature doesn’t seem right, because I work with three customers and they seem to be struggling. So yes, we did set that vector the right way by talking to customers, but when it meets the real world, there are some gaps that need to be tuned, or some things that need to be thought through.
Now imagine doing this at scale across many, many different teams, and you get a picture of what that looks like. Those are key things we need to organize as a team. And as I said, we are in Slack all the time. We have great tools that summarize all of this and roll it up. We have fantastic reports that show up. We have a channel where all the FDEs post exactly what’s happening with the customer, what their pain points are, and whether it’s a paper cut or a feature request. And we have PMs and engineering leaders looking at it all the time, matching it against the roadmap, and seeing if something needs to change or if we need to jump in on the customer side. We’re working more with customers than we ever did before.
Aakash: I want to return to that role layer, because you brought up the forward deployed engineer. It’s got to be the hottest, sexiest new role in tech. And for my audience, it’s the forward deployed product manager that’s super interesting to them. What do you see? Are these roles replacing the traditional ones? Are they a supplement? How do they fit into the broader picture we just described of engineer, designer and PM?
Jayesh: Yeah, 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 expert humans in the middle. We are trying to help our customers catch up, and trying to match the diffusion rate of technology across the customer base in a way that adds value to them. So it’s proportionate 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 forward deployed engineers, PMs, designers, whatever.
Broadly, the main skill is twofold. One is really being able to immerse oneself in the customer’s pain point. They bought us to solve a problem. Falling in love with that problem and then helping the customer solve it using the tool sets available to them.
And often the tool sets are not sufficient. That’s okay. The forward deployment team has the freedom to go find some other bit and plug it in to make the whole thing work. We’ve done that many times. Sometimes we build something custom with them and then bake that into the product.
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. It has the added benefit at roadmap planning of seeing whether that thing was really custom, or whether all customers would need it. And if all customers would need it, how about we take the prototype, since we already have one, out to a bunch of customers and get feedback on it?
So this cycle of getting feedback in, bringing in a PM, designing it the right way with a designer or an engineer, working with a customer to get it built out and making them successful, is really the lens that is different.
Aakash: So what I’m hearing is that the forward deployed group is doing a lot of this rapid prototyping at a custom scale, and then it brings it back to the core group to decide if we want to build it into the product for everyone. Is that right?
Jayesh: That’s right.
Biggest mistakes in AI transformations (52:29)
Aakash: Okay. So you get to see a lot of customers 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 watching this should keep in mind, so they can avoid them in their implementation?
Jayesh: I’m a big believer in starting simple. I’m a big believer in defining value, then defining metrics to capture that value, calling it your ROI metric, and getting it built out end to end. Then scale it out. Scale one, and then scale all.
Often implementations don’t take this flavor. It starts off as a full company transformation story, then very quickly breaks out into this massive plan across the board, and creates a lot of pressure on the teams that are implementing, and even on customers who are trying to derive value.
So one piece of advice I always have is, start with your hardest problem, that’s okay, but be very clear about what value is going to look like. Then break it down into, as we’ve talked about before, clear ROI metrics, clear scorers on the agent, clear evals on the agent that tie to value and ROI.
Keep in mind, this is technology that we built ourselves, so it’s easier for us. But when I look at others building agents, I get the sense that 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 your belt is super important. That’s one key thing.
The other one is that there are a lot of variables when it comes to building the system. What models do we use underneath? Should one train their own models? Should one start with a harness? What is the role of implementing the right context? There are a lot of variables. I’m a big believer that for the very first implementation, you minimize the variables. Get the work done in the simplest way possible, Occam’s razor, and then start to ask what the ways are to make it more efficient. And there are many.
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. One of them was on Mark’s keynote, and they’re one of the customers I work with very, very closely. They’re a recruiting company based in Europe, one of the largest recruiting companies in Europe, and they’re wall-to-wall Agentforce agents. They have pre-screening automated with an agent that calls you, and you can take an interview on a phone call. It keeps state, it can ask questions, it can escalate to a human, all of that baked in. They started with text, wall-to-wall, in 17 different languages. They’re deployed across Europe, and now they’re going voice.
So that’s a good example of setting a high bar, starting with one or two use cases, really going all the way, and then expanding and going wall-to-wall.
Where to find Jayesh (55:49)
Aakash: This has been a master class. Thank you. If people want to learn more about building an AI native product team and organization, where can they find you online?
Jayesh: Online, I’m on LinkedIn. You can find me on LinkedIn. I’m on Twitter. And of course, you can find all about Agentforce on salesforce.com. It’s where I live pretty much all the time.
Aakash: All right, Jayesh, thank you so much for being on the podcast.
Jayesh: Absolutely. My pleasure.