From Experimentation to Execution: Making AI Work Across Enterprise GTM
Insights from Amrutha Suresh, Head of Enterprise and GTM AI at Asana, on The Revenue Lounge podcast
Executive Summary
The majority of enterprise AI initiatives don’t make it past the pilot stage. They don’t fail because of the technology. They fail because of how they were designed. They start with the wrong question, measure with the wrong metrics, and are handed to teams that were never set up to scale them.
Amrutha Suresh, Head of GTM AI & Innovation at Asana, has spent the last year building one of the most deliberate AI transformation programs in go-to-market. In this episode of The Revenue Lounge, she shares the frameworks, the architecture, and the hard lessons behind making AI actually stick at enterprise scale.
The conversation covers how to graduate pilots to production, why AI transformation requires a complete redesign of how work happens (not just automation layered on top), the three-tiered context architecture that makes agents reliable, a three-tier metrics framework that separates vanity metrics from real ROI, and the most common mistake leaders make when deciding what to automate.
Amrutha has spent fifteen years in B2B tech, leading technology teams and building product functions inside go-to-market organizations. When the AI wave hit, she pivoted from a broader GTM technology role at Asana into running a focused AI innovation pod. What started as a side project became a dedicated function that now reports into the revenue organization with its own product management and engineering layers.
The mandate: not to buy and implement AI tools, but to build proprietary capabilities on top of Asana’s own data and context.
Why AI Pilots Fail to Make it to Production
Most organizations are running pilots. Most of those pilots will never scale. Amrutha’s framing of why is precise and worth sitting with.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
Pilots are typically started as an interesting technology I want to get my hands on, rather than an important business problem I want to solve.
That distinction determines almost everything that follows. A pilot built around technology curiosity generates adoption during the novelty phase. The moment the novelty fades, there’s no business outcome pulling it forward. And it stalls.
The second reason pilots fail to scale is more structural: what works for one person on their laptop doesn’t work for a thousand people in production. The moment you try to scale, you run into security, permissions, data edge cases, business rules, and integration dependencies that the pilot never had to confront. These aren’t reasons not to innovate. They’re the constraints that need to be designed around from the start, not discovered at the point of rollout.
The third is maintenance. AI systems are not one-and-done. They require ongoing optimization, feature releases, and continuous improvement. The token costs, the engineering time, the product management overhead – these are real costs that need to be factored into any build decision. Most pilots don’t account for them, which means they’re built on a foundation that can’t sustain them.
You've got to have this R&D mindset when you think about AI transformation - how do you productize everything and maintain that ongoing.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
What to do: Before starting any pilot, ask: is this solving an important business problem or an interesting technology problem? If you can’t name the business outcome, the friction point, and the persona whose job it changes – stop. Come back when you can.
The Three-Tiered Context Architecture
One of the most technically specific and practically useful frameworks Amrutha shares is how she thinks about context: the layer that makes AI reliable rather than just plausible.
Most organizations think about context as a single thing. Amrutha breaks it into three distinct layers, each built on top of the last:
Layer 1: Data foundations
The starting point is not a perfectly clean dataset. That’s a perfectionist’s trap that delays everything. AI-ready means your data is usable in the context of a decision. Clean enough, connected enough, defined enough to support the specific capability you’re building. Start there. Perfect later.
Layer 2: The semantic layer
This is where most organizations skip ahead and pay for it later. A semantic layer standardizes the definitions that make your data mean something consistent across teams. “Customer” means something different to sales than it does to marketing. “Engagement” means something completely different to sales, marketing, and product. AI needs a common definition of the concepts that matter to the business – without it, the same question asked by two different people returns two different answers.
The example Amrutha gives is telling: raw data might show that a customer logged into the product 70 times. A semantic layer transforms that into: this is a high-intent user in a strategic account whose usage pattern resembles customers who historically have expanded. One is a data point. The other is a business signal.
Layer 3: Context assembly
This is where the intelligence lives. For any given decision – should I prioritize this account? – the context layer dynamically pulls together everything relevant: product usage, past opportunities, conversation history, buying committee composition, ICP definition, territory rules, current strategic plays. The right context for the right decision, assembled in real time.
For each decision, you can dynamically assemble the context that is relevant for that specific use case or agent you want to build.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
The goal Amrutha is building toward is composability: a foundation where new agents can be spun up quickly by referencing the same underlying data components, without rebuilding the pipeline from scratch each time. Each new capability becomes a layer on top of a shared foundation – not a separate system with its own data dependencies.
Who owns this? It’s a triangulated partnership: the AI GTM engineering team, the data engineering organization, and the data warehouse and integrations team. No single owner. Shared accountability. Regular working group cadence separate from the strategic AI council.
AI-fiable vs. Not: The Framework Nobody Talks About
This is the insight that most AI transformation conversations skip over, and it may be the most important one.
Not everything is a candidate for AI transformation. That is the mistake a lot of people make - let's AI-ify everything.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
Amrutha draws a sharp distinction between automation and AI transformation that most leaders conflate. Automation asks: In this ten-step process, which steps can I eliminate? AI transformation asks a fundamentally different question: Given what AI can now do, how should this work be redesigned entirely?
The seller prospecting example makes this concrete. Traditional automation might remove a few manual steps from how a rep gathers data before reaching out. AI transformation changes the motion itself: the seller’s job shifts from information gathering to judgment and action. The AI assembles the data, surfaces the signals, ranks the accounts. The human decides where to invest time and how to engage. That’s not automation of a workflow – it’s a redesign of what the workflow is.
“With AI, the human moves from information gathering to judgment and action. That is the redesign.”
To decide what qualifies, Amrutha uses a rubric built around four questions:
- Who is the persona, and what is their job to be done?
- Where are the friction points in how they work today?
- Is AI the right solution – or would process improvement or role changes solve it first?
- How would the workflow be redesigned (not just automated) with AI?
Technology is never the first answer. The friction point comes first. Then you assess whether AI is the right lever – and only then do you design the solution.
Read the complete transcript for more insights on Amrutha explaining the architecture herself.
The Three-Tier Metrics Framework
Why do so many AI initiatives lose executive support? Because they’re measured with the wrong metrics.
Amrutha’s three-tier framework cuts through this.
Tier 3 – Vanity metrics (useful diagnostics, not ROI): Prompts, weekly active users, adoption rates, chatbot usage. These matter as early signals of engagement, but they tell you nothing about whether the business is better off. “I would put that as tier three. They’re useful diagnostics, but they’re not ROI.”
Tier 2 – Efficiency metrics (productivity gains): Did the account research process go from five hours per week to two? Is forecast preparation faster? Is meeting prep more complete? These are meaningful – they demonstrate that AI is saving real time on real work – but they’re still not the headline number.
Tier 1 – Business outcomes (the only metrics that matter to leadership): Pipeline generated. Conversion rate. Win rate. Churn reduction. CSAT. These are the numbers leadership cares about, and they’re the only ones that sustain executive support and funding over time. Impact can be direct, influenced, or incremental – but it must trace back to a KPI the business already measures.
The incremental framing is particularly useful: some AI capabilities generate outcomes that wouldn’t exist without them. An AI agent that qualifies site visitors during off-hours isn’t improving an existing rep’s performance – it’s creating pipeline that would have been lost entirely. That’s not efficiency. That’s incremental revenue.
When you think about your design, definitely factor in attribution, tracking, and reporting. That way you're able to measure business outcomes, not just activity.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
The critical implication: attribution and measurement need to be built into the solution design from the beginning. Not added after launch. Not figured out when leadership asks for results. Designed in from day one, so that when the question comes – and it will – the answer is ready.
Change Management: The Part That Actually Determines Whether It Works
AI transformation breaks traditional organizational boundaries faster than any previous technology program. Amrutha’s experience at Asana has sharpened her view on what this means in practice.
The instinct in most organizations is to build first and bring stakeholders in for review. Amrutha inverts this entirely.
You've got to be bringing people along in the journey very early. Stakeholders have to be treated as design partners from the very beginning.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
Security, legal, enablement, field leadership – none of these can be afterthoughts. Especially in go-to-market, where the field has been subjected to constant change from every direction, AI transformation cannot be “yet another change.” It has to be designed with the people who will use it, not designed at them.
Field enablement deserves special attention. Amrutha is explicit: enablement partners need to have shared responsibility for the outcome, not just a seat at the launch. When they’re co-designers, they become advocates. When they’re recipients of a finished product, they become friction.
The hardest thing to change, in her view, is mindset and culture – specifically the fear that AI will eliminate jobs. Her response to that fear is two-directional: companies need to enable employees to use AI to do their jobs better, and employees need to be open to evolving into the roles that AI creates rather than protecting the roles it changes.
The roles that say 'I don't want to change and I don't want any help from AI' - those are the roles that are probably going to evolve into something else. You've got to move with the change.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
The RevOps-to-GTM-engineering transition is the example she points to: a function that was historically focused on third-party tool implementation is becoming a function that builds proprietary AI capabilities. That’s not a threat – it’s an upgrade, for the people willing to take it.
Build vs. Buy: The Most Confusing Decision in Enterprise AI Right Now
Amrutha calls this “the most spicy topic in the community” – and she’s right that there’s no clean answer. But she offers the most useful framing we’ve heard.
The rule of thumb: don’t build what you could never build better. You’re not going to build a CRM. You’re not going to build a call intelligence platform from scratch. But the proprietary context layer, the semantic definitions, the multi-agent orchestration, the agentic governance framework – those are builds. Because they’re specific to your business, and no vendor can replicate them.
The gray area is where it gets interesting. A conversation intelligence vendor essentially takes transcripts, passes them to an LLM, and extracts insights. Technically replicable. But should you? That’s where the economic model matters: what does it cost to build and maintain vs. what does the vendor charge? How many reps, how many tokens, what’s the orchestration cost? When you build the model, you often find the vendor is cheaper than the internal cost of maintaining parity.
Could we do that internally? Maybe. But should we? Then we think about the cost of paying the vendor versus us doing it - and we build the economic model.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
The question Amrutha keeps coming back to: what is unique to your business, your context, your data? Build that. Buy everything else.
The One Thing Leaders Should Do Next Week
Amrutha’s most actionable guidance for leaders thinking about AI transformation:
Build a use case rubric. Before touching any technology, map the following for each potential initiative:
- Persona: Who does this serve?
- Jobs to be done: What work are they actually trying to accomplish?
- Friction points: Where does the current process break down?
- AI-fiability assessment: Is this genuinely a candidate for AI, or would process redesign or role changes solve it?
- Workflow redesign: If AI is the answer, how does the work change – not just get faster?
That framework is going to be extremely critical to start with. Jobs to be done, personas, gaps, friction points, and how you would solve for by redesigning the workflow and process.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
The framework doesn’t guarantee success. But it prevents the most common failure mode: starting with a technology and looking for a problem to fit it.
The Bottom Line
Amrutha Suresh’s perspective is distinguished by how rigorously it keeps the business outcome at the center. Every framework she offers – the context architecture, the metrics tiers, the AI-fiability rubric, the build vs. buy model – is designed to answer one question: is this actually making the business better?
Her most durable insight is also her most counterintuitive. The biggest transformation killer isn’t lack of technology, budget, or even data quality. It’s process – the organizational inertia that slows iteration, demands perfection before shipping, and makes a ticket the answer to every request.
It's not perfection, it's iteration that I believe in. Build something quickly and then make it more perfect. I don't want process to stand in my way.

Amrutha Suresh
Head of Enterprise & GTM AI, Asana
In an environment where AI capabilities double every seven months, the organizations that wait for perfect will always be behind the ones that iterate.
Know a GTM leader, CRO, or AI transformation practitioner with a sharp point of view?
We’re looking for practitioners with genuine experience, not polished keynote stories.
Amrutha Suresh is the Head of Enterprise and GTM AI at Asana. Connect with her on LinkedIn.
This post is based on her conversation with Randy Likas on The Revenue Lounge, Nektar’s podcast on the future of go-to-market.
Never miss an episode! Subscribe to The Revenue Buzz newsletter to get weekly episode updates.
If you liked what you read, please share it with your peeps.
In this blog
Get the Revenue Lounge Brief
3 takeaways from every new episode, straight to your inbox.

Episode Transcript
[00:00:00] Randy Likas: AI has quickly become a boardroom priority. As organizations shift from experimenting to embedding it in everyday work, the conversation is no longer just about the models and the algorithms. It’s about building an enterprise operating system that enables AI to make reliable decisions, redesigns how work gets done, aligns business and technology teams, and ultimately delivers measurable business outcomes.
In this episode of the Revenue Lounge, we’ll explore what it really takes to scale AI across the enterprise. And joining me today is Amrutha Suresh.
Read Full Transcript
She is the head of go-to-market, , AI innovation transformation at Asana. With a background spanning AI strategy, enterprise transformation, product innovation, and cross-functional leadership, she brings a practical perspective on turning AI from isolated pilots into a sustainable business capability.
Amrutha, thank you so much for joining us today.
[00:00:49] Amrutha Suresh: Thank you for having me. Excited to share my perspective, so I’m glad I’m here.
[00:00:51] Randy Likas: Yeah. And this is a really special episode of the Revenue Lounge because, I shared this with you in the green room. This is our one hundredth, guest on the recording.
So , very pleased to have you , and, , specifically around a topic that I think is near and dear to many people. Yeah. So I usually like to start these episodes, with just asking a general question, which is maybe you can walk us through a little bit about, your career background or journey, and what led you to your current role at Asana and what is your remit?
[00:01:14] Amrutha Suresh: Yeah. I’ve been about, , fifteen years in tech, specifically on the B2B software business. Come from a systems background. I’ve led technology teams, created product functions within the go-to-market organizations. With the AI boom, I pivoted to basically run a very small pod of, , innovation, , where we think about how do we identify opportunities that truly matter to the business and create value through AI and technology.
So that’s the pod that I’m running currently at Asana. , While I’ve been doing all of this, I also did my MBA at Berkeley Haas, which kind of changed my perspective on how do I, , look at the business overall. So, I’m super excited to see what’s gonna come with all of this cool stuff that we’re building.
[00:01:57] Randy Likas: Yeah. And so how long have you been specifically focused le-leading the AI, ,
[00:02:00] Amrutha Suresh: hub? Yeah., It’s gonna be about a year since we started this. We were doing this as a side gig, but it became so important that,, we decided to actually have a focused group, that is working and building things, in a very streamlined manner.
[00:02:13] Randy Likas: In what areas of the business does that hub , encompass? I’m assuming you probably have, leadership and maybe d-different functional leaders. I’d be curious to understand,, how you guys are designing that hub today.
[00:02:22] Amrutha Suresh: Yeah. So initially we started off thinking about this more of an enterprise AI transformation, where, , this function reported on to the CIO of the company, where we were looking at pockets of, , AI innovation that’s happening across the function and then-
bring more of a AI council where we were governing how things are happening, what are some of the cool stuff that is being built out, the pilots. , And then we started making this as a mandate, where this became a company-wide goal of AI transformation is important and here’s what we wanna be achieving with, doing all these cool stuff.
, And then what happened was we started putting our focus more towards, the revenue side or the go-to-market side of things. And that’s where I moved from the CIO org to the revenue organization, , leading a GTM AI transformation pod, which has a product management layer and also an engineering layer.
Because if you think about the GTM tools tech and AI sort of , a area, there is a third-party tool that is mostly a buy-in and implementation, which was the standard GTM technology prior to the AI boom. And- Mm-hmm … there is an in-house build, which typically is more around the proprietary contacts data and how you train your models and then also make it more connected, , in terms of the architecture and how do you evolve from a single agent to a multi-agent play.
So that is basically the AI pod that, , focuses on the aspect of more in-house build.
[00:03:45] Randy Likas: Got it. Very, very good. , I wanted to ask you a question because , there’s just so much I think, experimentation going on inside of organizations, right? Everybody’s running pilots or POCs, or there’s pockets of things maybe be-before they establish it, , something like an AI council.
And there’s a lot of research out there. I think I might have heard you , a presentation or podcast you gave about a month ago talking about how, , the majority of enterprises struggle to get out of, the pilot mode or the POC mode. And, only about 25, 26% of them move beyond that.
From your perspective, what do you think are the biggest reasons why some of these initiatives lose momentum after the initial pilot or POC? Yeah. Before actually answering the question, I do wanna say that we gotta be thinking of encouraging our, , teams and our companies to actually drive more innovation.
[00:04:33] Amrutha Suresh: What I’m trying to say here is we gotta be building that pipeline of innovation ideas because AI should be democratized, and it should really be like a bottoms-up motion. What needs to happen is we need to have a very clear framework of what actually graduates from a pilot to a production-grade capability.
There is a difference in somebody white coding a very cool idea using Claude, using Codex, or any other cool AI capability on their computer versus thousand-people team running the same capability at scale. So I think that’s the difference, and that is basically the framework, we gotta have, in place when I say you gotta have a system of graduating pilots to production.
I think, , some of the biggest challenges we encounter when you take one person’s sort of a capability and make it more production-grade is how do you address concerns around security, permissions? , Data becomes a really, really important thing, so you gotta think about the different edge cases, business rules, integration dependencies.
So these are some of the constraints that, , you meet, when you start taking in this white-coded sort of an app from a single person’s computer or desktop into- Yeah … more of a production-grade system, right? Another issue that I also see is that, , the pilots are typically started as an interesting technology, and I wanna get my hands on it rather than an important business problem that I wanna be solved after.
Mm-hmm. So, you get all of this adoption, , traction during novelty phase, but I think it’s really important for it to stick, you’ve gotta think about what does this mean in terms of the outcome for my business? Is this important enough that I’ll be talking to my leadership about and be able to measure and show the results?
So really thinking this through from an outcome lens and then all the constraints and dependency to make this a production grade, these would be like the two considerations I would have at a high level when you think of taking in a pilot or an innovation project and making it truly production grade.
, Another thing that I also wanna touch upon is the ongoing maintenance, because if you think about the build versus buy, which is a very spicy topic in the community at the moment- There are companies that exist which are very purpose-built, , for a specific reason, right? So you don’t have to invest your resources for ongoing maintenance.
Yeah. Yes, we do incur cost with building AI, right? There’s LLM token cost, et cetera. But you also gotta think about what does it take for us to maintain this as a product, because this is not a one and done. You’ve gotta be running optimizations. You’ve gotta be, , releasing features, continuous improvements.
So That’s like an invisible sort of a hidden cost. So you’ve gotta be factoring all of these things when you actually say that this is something I wanna take as a side project or a cool innovation idea and make it a production-grade system. You really gotta have this R&D mindset when you think about AI transformation on how do we productize everything and also maintain that ongoing,-
[00:07:25] Randy Likas: Yeah.
[00:07:25] Amrutha Suresh: Yeah.
[00:07:27] Randy Likas: One thing that I wanted, to ask you about is any sort of multi-motion or multi-function AI initiative that truly is enterprise, , touches a lot of stakeholders and a lot of departments. And I think any sort of digital business transformation, there’s , a change management component , to that, right?
And maybe some internal politics , that you have to work around. How do you approach that? And what are some of the watch-outs , that you look for to make sure that you’ve got that right organizational alignment?
[00:07:52] Amrutha Suresh: Yeah. I think it’s a really good question because, , one of the things that I’ve learned while I’ve been doing all of the AI transformation at Asana is, AI transformation, unlike other things that we’ve seen, breaks the traditional organizational boundaries very quickly.
Mm-hmm. So what I mean by that is, you’ve gotta be bringing people along in the journey very early. So think about your stakeholders. Once you identify them, they have to be treated as design partners from the very beginning, right? Whether it’s security, whether it’s legal, whether it is enablement, especially when you think about go-to-market transformation, it has to stick with the field because they have been bogged down with so many changes in multiple directions.
This cannot be yet another change. And also the AI transformation should not be designed as another system implementation. For me, when I think about an AI capability, it’s a complete redesign of how work happens. For that, enabling them and making sure it sticks is gonna be really important. So enablement partners are gonna be a huge, , I would say, lever in making this work.
So bringing them early on and making sure that they have a shared responsibility and als- everybody’s working towards the shared business outcome is gonna be extremely important, and that’s a lesson that I learned in a hard way to make sure that I- Mm-hmm … identify who are the people who matter to make this moving, make any things moving, and make this stick.
And bringing them along as design partners together with a shared outcome is gonna be super, super important. Yeah. Wonderful. There’s something you touched on earlier that I wanted to dig in a little bit, more on, which is, everyone, Talks about the importance of context.
[00:09:29] Randy Likas: Context is really hot topic right now, around,, designing AI into workflow transform-tr-transformation. And I think where people maybe stop short is understanding what context really means, because there’s several different types, right? There’s activity context, which is like what happened.
There’s relationship context, which is, who is this connected to or, what is it connected to, right? There’s knowledge tran- context, like product specs and security docs and architectural diagrams. And then there’s semantic context, which is the business context.
What is the shared definition or shared understanding? , So I’d love for to unpack that a little bit , with you in terms of how do you think about the different contracts , and Does one play more important role than another and how do you design for all those?
[00:10:11] Amrutha Suresh: Yeah. , It’s a relevant question because, , one of the things when I started doing all of this, the first thing, and the biggest challenge we had is, before even getting to the context, it was the underlying data foundations, right? Just like any technology program, , data is a very foundational, component to it because garbage in equals garbage out.
So- Yeah … one, we started off with thinking through , what does like good data hygiene looks like, , for the specific type of capability that we wanna deliver. I think what we also realized in that process is I don’t think AI-ready means we should have a perfectly clean data, right? AI-ready is – your data is usable in the context of a decision for your organization.
So we have this data foundational layer, and then we have, , on top of that, think about this, it’s a more layered architecture is what I’m talking about. So data foundations, and then you have the semantic layer, to your point, which is basically the context of the definitions and standardized way of looking at certain, , business components of your, data layer.
So a customer, for example, could be very different for a sales versus, , what a marketing is addressing as a customer. And a field called, let’s say, engagement may mean something , completely different for sales, marketing, and product. Yeah. So in order for AI to work well, AI needs a common definition of the concepts that matter to the business.
So that’s where we started building out semantic layer on top of our data foundations. , So raw data might, , tell us that, for example, someone logged into the product like 70 times. But what a semantic layer would tell me is that this is a high-intent user in a strategic account whose usage pattern resembles a customer that historically has expanded.
So that is the insights that a semantic layer is gonna basically give me. Now, imagine asking AI, “Should I prioritize this account?” Right? Knowing the company size and industry would just not be enough, right? Mm-hmm. It might need more information that it needs to be bolstered on, like usage of the product or your product telemetry, , past opportunities, conversations with customers, , who is involved in your buying committee, what is your company’s ICP definition-
territory rules, what are some of the current strategic plays in motion? So there’s multiple other data it has to connect to, to make that profile. Mm-hmm. So, , this is what I think about as the context assembly layer. So essentially you have your data foundations, then you have your semantic, which is basically standardizing your, , definitions across the company that you work for.
And then having the context, where, , basically it, , turns the things into like a meaningful sort of a business concept. And then for each decision, you can dynamically assemble the context that is relevant for that specific use case or the agent that you wanna build. So I look at it in a three-tiered architecture on which-
the application agents basically sit. And I think the most important thing that we’re trying to think of and evolve is how do we make this sort of an architecture more composable? Because we wanna start building everything so quickly, we don’t wanna have the pipelines rebuilt, right? Like the , underlying foundations for the agent.
Each time we don’t wanna be replicating or rebuilding that. We wanna really have the standardized sort of a data layer and make our application agents more composable in a way whi-which can be basically referencing the same underlying data components. But very quickly we should be able to layer in like multi-agent sort of a capability in a very composable way.
[00:13:41] Randy Likas: So , the architecture that you described that sort of brings in , all the different, contexts, is there a, , owner? Like who owns that sort of context, , piece? Is that, a single person? Is there multiple people that can contribute to that? I’d love to understand what that looks like inside the organization.
[00:13:57] Amrutha Suresh: Yeah. I believe there’s no one single person who maintains that. I would see this as a partnership. Yes, there’s accountability on the person who’s actually building all of these cool AI stacks within the company, which is the AI GTM engineering organization. . But there is a huge partnership that we have with our data engineering org, who are actually the, owners of, the data warehouse within a company.
Also data governance, data hygiene. There’s a lot of component that comes into it, so I see this as a very clear partnership between, , the AI GTM team, the data engineering, and the data teams, basically, the data warehouse and integrations team. , So I would see this as a triangulated sort of a partnership because even for any projects that we do on AI transformation, data is a big component of it, and we spend most of our time, making sure that we gain trust from the field or the customer that we are building for, – Mm-hmm
to ensure that we do have the trust in the output that we’re producing, and we get a lot of feedback and run a lot of pilots to make sure that component of the program is well sorted through before we do anything. And I think that is the longest sort of, effort in any program-
that we deliver. That takes the biggest amount of time.
[00:15:07] Randy Likas: Yeah. And is that something that’s done, as part of the initial strategy work? And then, , what’s the cadence in which you meet to look at, , how do we evolve this or what’s missing? Or is it part of the AI council?
Do you have a standing monthly , meeting cadence? And how does that evolve over time?
[00:15:23] Amrutha Suresh: Yeah, this is a really good question, so I would say AI council as more of a strategic enterprise-wide initiative where we’re bringing in folks across, we call them champions or activators, right, across different functions- Yeah
to, one, create a shared understanding of what is happening across each function. Are there redundancies that we can avoid by the tool sprawl that’s happening with AI? And governing, right? That’s another one. , What are your programs? , How are you looking at the ROI?
What are the industry benchmarks that you’re looking at? So we have a very strategic conversation at the council level, but when we talk about the program builds, that’s a separate part because we wanna branch that off from the strategic conversation- Got it. And make it real tactical so that we have the right working groups talking about critical decisions that we wanna be making on the program level.
And we run that in sprints, right? So it’s, typically how, we run our GTM R&D org, right? , We have sprints. We wanna make sure that we have the designer, Because every AI program has to be thought through in a very different way from an experience standpoint. So we do definitely have a designer to rethink how work happens.
We have our, customer who we are designing the product for, internal customer. We have our data teams, our Salesforce developers, product managers, and AI engineers. So we assemble a pod, and then we bring in, guest appearances. If we have a data science person who needs to come in for a certain component of work, we bring them in.
So this is the pod. This is like a core team working group that we create, and we meet almost– We create daily standups. , We have weekly, forums where I join and I, , try to guide the team, and I have an understanding of what’s happening and where I can unlock things. And then we report this up on the progress, , to our leadership team.
So we run this in a very sort of a tight, collaboration model- , with regular touch points because we have a global team, and we gotta make sure that people feel included and people feel that they’re brought in to the context and a shared understanding of the progress of the body of work.
[00:17:19] Randy Likas: Got it.
Okay. So let me kind of s-summarize here. So I think , there’s a lot of work early on,, to make sure that we’ve got an AI-ready , data organization or data model. We’ve gotta have the strategy in place. Yeah … we’ve gotta have the right stakeholders involved.
Then we get to a point where we start thinking about, what is the work that we want , , to actually, , have the AI run on top of, right? And , I was speaking with someone recently who said, “Just because we can put AI on top of it doesn’t mean we should do that,” right?
We should think about, , whether or not those processes should even be automated or, , , where should we redesign, our work. So in your experience, so what changes in workflows or operating models, , that become necessary when you think about embedding AI into everyday work?
[00:18:00] Amrutha Suresh: Yeah. I think this is the most important question because to your point, I think it’s really, really important to have a framework of what is AI-fiable or what is not AI-fiable, because not everything is a candidate for AI transformation, and that is the mistake a lot of people do in let’s AI-fy everything and layer an AI here and there, right?
So I wanna talk about the difference between what is automation and what is a candidate for AI, and how actually things change with AI. So if you think about the automation world, right? So let’s say there’s a 10-step process, , where, people are working across these 10 steps, and the question you would ask is: What are the pieces of these 10 steps that I can automate?
That is very different from how do I transform this workflow with AI? Because you can’t ask the same question with AI saying, “Can I add AI in step number six?” That’s not the way you look at AI- Mm-hmm … in my opinion. Mm-hmm. It is really, really an opportunity to rethink how work happens. So what I mean by that is, let’s take an example of a seller’s world, right?
Prospecting. Every company does this. The seller basically goes to multiple places to get different data signals. They assemble it, and then they basically, , figure out a way to go engage with the customer. That’s basic prospecting. , With AI, if you would do this right, the motion of how a human would interact with the systems is gonna change.
So basically, the seller’s job moves from information gathering to judgment and action because the AI is able to bring that data for you. Mm-hmm. And how the human looks at the data and decides where I am gonna be investing my time versus where it’s not worth investing my time. So that is the redesign I’m talking about.
So when I think, I always keep saying about like an operating model change, you start moving away from your static workflows to event-driven workflows. So a rep comes in every day in the morning. The system is able to, as I said, , mention that here are the things that has happened, here are the signals for you, and, the human basically acts on those signals, right?
So basically, it removes all the administrative burden of going into multiple surfaces- and then it’s the judgment that the human needs to make on where they should, , focus the time. And that’s why the design of how you would build this experience really matters. And when I say redesigning how work happens, this is exactly what I mean by that.
[00:20:27] Randy Likas: Yeah. And I was gonna ask you about that. , I saw that you’d posted about the Upvance sales reset y-that y’all had done, and so I’m glad you went into that and shared an example because I think it’s a, a very tangible, , example. So I have a question, maybe , the hindsight, right?
So looking back at your AI transformation journey thus far, , what’s one decision that you made, , and delivered on that, , maybe outsized the impact or one mistake that you would avoid, having that hindsight if you were starting over today?
[00:20:52] Amrutha Suresh: Yeah. I think, , one of the decision, , where, I was able to create an impact was, , thinking about where can I find the opportunity that can actually create true business value, right?
And, to my earlier point on having a very clear framework of what can be AI-fied and what should not be AI-fied. So from there, , we put together like a rubric of here are the personas that I wanna be going after because here’s where the business challenges exist that I wanna solve for.
And then putting together, okay, for this persona, here are the jobs to be done, and here are the friction points. From there you basically start identifying what can I do to rethink how work happens to get this friction point out of their way. So that’s how– That was the genesis of how we created our prospecting engine at scale, which is, having a lot of value at the moment and a lot of adoption within the field, and we are able to report on some of the outcomes that we’ve dealt with for the business.
So what my guidance would be for people who are trying to think through this, , really put together like a map. It all starts with some capability mapping of who are the personas, how does work happen for these personas, and where are some of the friction points. And then assess, is this a candidate for AI or could you be solving this, through other process improvements, role changes?
, It has to be looked at a 360 perspective because I believe technology is not the answer always. , We gotta first assess if this can be solved otherwise, and then insert technology and AI , into the plan. And,, yeah. So that’s the biggest, , I would say impact that, we’ve done with AI.
[00:22:29] Randy Likas: The part that I wanna talk about is, , the measurement or the impact, right? , to go back to where we talked about,, why a lot of pilots or POCs maybe fail is that it wasn’t able to demonstrate enough of an impact, right? People were measuring the wrong things.
They were measuring adoption or, chatbot usage But they weren’t looking at, how is this actually moving the needle, , on the outcomes that we’re trying to drive. And I know you’ve got a pers-perspective on that. Can you share more in terms of where do you identify, wh-when work that does need to be , re-redesigned, how do we measure that impact beyond some of those , simple metrics to ones that actually move the needle?
[00:23:02] Amrutha Suresh: Yeah. , One, I think there’s a definite hierarchy here because when you think about the , bottom layer of metrics, , you definitely have your, I call them vanity metric, prompts, weekly active users, adoption, all that is important, but I would put that as tier three. , So I would consider them as, useful diagnostics, but they’re not ROI, right?
Then is the tier two metric, which is basically the workflow level metrics, right? Did the account research go from five hours per week to two hours per week? So it’s more around the efficiency gains and a productivity type of a measure. And then I would put tier one, which is a difficult thing to do, and that’s why when you think about your, build, you’ve gotta have attribution and tracking and reporting very much embedded into the solution design that you would be putting together.
That should not be coming as an afterthought. , Tier one would be the actual business outcomes. Because you’re solving for an important problem that the business cares about, it better have some sort of a tie back to the key metrics that you care about as a business. Pipeline, conversion, win rates, churn, CSAT.
So that’s the way you would start measuring your tier one. It could be direct impact or it could be influence, , because we do have something around pipeline influence by XYZ products that we’ve built, so that could be another way of reporting it. Or it could be incremental, right? Because we’ve g- we’ve been given X amount of target, we are gonna be doing more to supplement that.
So it’s an incremental number that you can, produce with some of the products that we build. A classic example would be, , a lot of companies are doing this AI SDR because, you have your, , quotas and targets for inbound pipeline generation number. One of the use cases that we have is if a site visitor comes offline hours when our reps are not around and they wanna chat and they wanna understand our product, could we deploy an agent that can actually qualify them?
So this is basically a number that we would not be generating if we did not have AI. So this is incremental to what we have. Yeah. So that could be another way of thinking about your, ROI for AI. So I look at it in three tiers, basically. And, business KPI would be like my tier one metrics.
And I know it’s hard to get there, so that’s why when you, as I said, when you think about the design, definitely factor in attribution tracking and reporting. That way you’re able to actually do it when you release the product.
[00:25:23] Randy Likas: Yeah. I love that framing of the different tiers and how to prioritize them and look at them.
I have one more question for you before we, transition to our lightning round, which is a little bit more fun and, and just o- off the cuff, if you will. W-w-what’s the one question that I haven’t asked you about , that you think is really important as people think about, this transformation?
Maybe I have two questions. What is the one thing I haven’t asked you about? And then the second thing is, what’s the one thing That, you hope people to take away from , this conversation today , or the most actionable thing that they’ll be able to do come, , next week?
[00:25:51] Amrutha Suresh: Yeah. I think the one question that I was hoping you’re gonna ask for is What does success look like, right? In terms of the executive buy-in. I think most of the times I’ve seen a lot of the, companies that do transformation for the sake of it, but it’s super important to have that as a mandate from the top because you’re trying to make this work superficially, and you’re trying to strive for it, and you are trying to scream that this is important.
But I feel like it should be a nice combination of bottoms up and tops down, where- you gotta have that executive buy-in support, resources, budget, because this is a program that requires investment. And again, to my earlier point, this cannot be like a side function. You are not gonna be able to do full justice to it.
It has to be a dedicated organization and run like a function. So for that, you do need that tops-down support and hoping every company or most companies will have this in their enterprise, , a company-wide charter. And in our company- . we report this to the board on how we are basically running agentification internally.
So if that is the level that this needs to be talked about, if this needs to be seriously implemented, and we really wanna see the results. So, , tops-down push and support sponsorship is extremely, extremely critical for this to work. To answer the other part of your question, if you don’t as a company, I highly recommend that you sit down and talk about what that plan is to make sure that it integrates into both these motions, bottoms up as well as tops down.
[00:27:20] Randy Likas: Yeah. Which I think also probably gets at, why maybe these- pilots fail, right? They don’t have that right executive support. The pilots don’t show enough of the movement , and what , the board or the executives care about, so they lose interest. They lose interest, you lose funding and so on and so forth.
Would you agree with that? Yeah
[00:27:34] Amrutha Suresh: I 100% agree with that. , And that’s super, super important, , for this to be successful. The other question I was hoping for is the build versus buy. As I said, I saw- Oh, let’s– Yeah,
[00:27:44] Randy Likas: let’s talk about that, for sure.
[00:27:46] Amrutha Suresh: So th- this is the most confusing and interesting topic, and I don’t think anybody would have one right answer.
It’s such a case-to-case sort of a evaluation at the moment. And I think everybody who’s doing what I’m doing will agree with that, that , it’s probably the most sort of a tricky time that we are in because this is a new era of building with economics being so cheap, with, , AI being so accessible.
But at the same time, how do you strike the balance? Which one should be a build? Which one should be a buy? , Where do you build that? And also the roles that are evolving with that, right? Because the technology or GTM technology teams that have historically supported third-party vendor tooling are there, and there are also, roles like internal AI builds which have formed.
So how do these two organizations collaborate? Where is the line? So that’s just been a very interesting sort of a dynamic across many organizations I’m talking to. Yeah . I was very curious that you would be asking me this
[00:28:45] Randy Likas: question. I’m glad you brought it up because I do wanna talk about it.
So what I’ve heard a lot of, , folks say is what’s unique to our business, , th-that’s like the things that we necessarily wanna own. And anything that’s more plumbing or infrastructure or more horizontal you kinda got at this a little bit earlier, is like, what is it that we don’t wanna maintain, right?
Because, , things that we need to maintain, you know, requires work, people leave. And , so when you think about what it is that we buy versus what it is that , we build ourselves, – I’d be interested to get your perspective. What are some of those c-core principles that you look at to make that decision?
[00:29:18] Amrutha Suresh: Yeah. The way I think about a build versus buy is I really don’t wanna replicate a very purpose-built tool which is extremely complex. I probably am never gonna build a CRM. However, if there is context that we need to be building, right? And if your point around the foundations, the, semantic layer, the context layer, the agentic sort of handoff, governance, how does a human and an agent, sort of a graduation happens, how do we maintain all of this multi-agent orchestration?
That is something that is a very classic case of build. Now, the interesting set of things or capabilities that come in bet- in, in between this blurry area is I was… Yesterday– This is a very recent conversation. Yesterday, I was, , having conversations with my team around how do you mine the insights and intelligence from a CI type of capability, right?
The call recording happens, , it’s all there, the raw transcripts. When you look at, , some of the vendors out there, all they do is they take the transcripts, they passage to LLM to get that insights. Obviously, they connect it to other sources of data to create the sort of a revenue, , context, right?
[00:30:29] Randy Likas: Mm-hmm. Mm-hmm.
[00:30:30] Amrutha Suresh: Could we do that internally? Now, interesting question. Yes, maybe. But should we do it? Mm-hmm. Then we think about what is, , the cost associated with it of paying vendor a higher bill versus us doing it, and we’ve gotta think about the scalability of how many reps do we have, how many tokens should we process, what is the orchestration cost.
So that way we start building in, , the economic model of a build and a buy. There are a lot of capabilities like that we could potentially replicate, but do we wanna do that? Is it cost effective for us? So those are the type of things that we start thinking of. But the other class of tools, like Salesforces, we probably don’t even wanna be thinking of building something like that and buy like an AI native or a Salesforce like, CRMs, which can do that.
So that’s where we start putting in, like, this gray area of tools. We gotta be very, , cognizant of do we choose to build or do we choose to actually buy a third-party vendor?
[00:31:27] Randy Likas: Yep. I think that’s a great perspective and,, the point around like we can probably build it, do we want to, right?
, Is it the right use of time? What about, the, the last question, which is around what is the one thing that you hope that either people take away from this or maybe the most actionable thing that they could do next week as they’re thinking about, , AI transformation?
[00:31:46] Amrutha Suresh: I think one is definitely have a clear framework on what are the use cases that you wanna go after for building and why. Have the clear intent, have the clear outcome, have a sizing, opportunity sizing of what you’re gonna get if you build that. And then who you are serving for is gonna be really important.
Based on that, you’ll have to plan how, who, what are the personas that you wanna bring very early as design partners. As I said, in the go-to-market world, field readiness is an absolute critical partner for you to start working with very closely. , So having that rubric and framework of what are the U- AI use cases that are absolutely AI-fiable versus not, versus what you should not be AI-fying, that’s another sort of a dimension that you gotta think of.
So jobs to be done, personas, gaps, friction points, and how you would solve for by redesigning the workflow and process. So that framework is gonna be extremely critical to start with.
[00:32:45] Randy Likas: Great. Let’s, let’s transition. I wanna do, a couple questions on lightning round.
First thing that kinda comes to your mind, , biggest transformation killer.
[00:32:54] Amrutha Suresh: Process ,
[00:32:56] Randy Likas: tell me more about that. Why process?
[00:32:59] Amrutha Suresh: I just feel like a lot of companies, overdo process. For example, if I want a quick change, submit a ticket, and somebody needs to look at it, there’s an SLA.
Just– Me just being a impatient person, I have very less appreciation for that. So if you want things to happen quickly, you’ve gotta be doing things quickly. Like, meaning it’s not perfection, it’s iteration that I believe in. So let’s build something quickly and then make it more perfect. So I don’t want process to stand in my way of delivering that perfect result and waiting for three, four, five, six months.
Yeah.
[00:33:32] Randy Likas: Yep. Got it. What’s more important, strategy or execution?
[00:33:37] Amrutha Suresh: Execution.
[00:33:39] Randy Likas: Yep. Even if me being an- Hardest thing to change in– It was good.
[00:33:43] Amrutha Suresh: I was like, me being an operator, I believe in doing stuff and-
[00:33:48] Randy Likas: Yeah. Yeah, we could, .. We could talk about it all we want. We gotta actually get moving , and start seeing results, right?
[00:33:53] Amrutha Suresh: Yeah. Bias to action is what I truly believe in.
[00:33:56] Randy Likas: Yeah. What’s the hardest thing to change inside a company as part of a transformation like this?
[00:34:01] Amrutha Suresh: Mindset and culture.
[00:34:03] Randy Likas: Mindset and culture.
[00:34:04] Amrutha Suresh: Especially in the age of AI, I believe- Yeah … there’s a lot of sensitivity. Is AI gonna take my job?
So people become detractors in a deliberate way, , to adopt the things, and I think that is a very difficult change to bring in.
[00:34:18] Randy Likas: And how do you do that? How do you change mi-mindset?
[00:34:20] Amrutha Suresh: Yeah. I think it’s very important to, one, make them more aware and enable them, to adopt to AI to give that confidence that this is not here to take your job, but it’s here to make your job better and make you more efficient.
And then I also feel like people should be a little more open-minded to stay more relevant because there’s so much of opportunity for the evolution in terms of the roles to happen in the age of AI, right? If you think about like a core, standard administration type of a job, even in RevOps, that sort of evolve into the GTM engineering type of a function where you become more savvier.
So you, as a person, need to be open-minded to stay relevant so that you can use this as an opportunity to evolve into much more relevant roles rather than, “I don’t wanna change, and I don’t want any help with AI. I’m gonna be stuck here.” Those are the roles that probably are gonna evolve into something else, so you’ve gotta move with the change.
Yeah. So it’s kind of two bi-direction, I would say. The companies need to be, , enabling, , the employees at all levels to make sure that they can do their job better, and the employees need to evolve to stay more relevant into what are the job functions that they can transition into, , in the age of AI.
Yeah. Yeah.
[00:35:34] Randy Likas: Yeah. Okay, last question for you. Not AI related at all,, but when you are, not busy inside, – an organization and trying to d-drive change and drive AI, what is it you like to do? Like, how do you decompress outside of work?
[00:35:46] Amrutha Suresh: I do a lot of traveling., I have two young children, so take them out, travel, s- spend…
It’s more of a family time that’s basically where I wear out all my stress.
[00:35:56] Randy Likas: Yeah. I’ve got two young children as well,, and, fortunately work at work, , my daughter’s over here waiting for me to talk to me, and I’m like, “I… Give me a minute.”, But yeah, no, I, I do, I same thing.
Love to spend time with the family. So, if someone wants to reach out to you after listening to this episode and get in touch with you, best way to do so?
[00:36:12] Amrutha Suresh: LinkedIn. I’m on LinkedIn. LinkedIn. Very active, so feel free to reach out anytime.
[00:36:16] Randy Likas: Great. Well, , Mridula, thank you so much for your time.
, I think it was a really, insightful episode. , You’ve obviously have a lot of great wisdom, so thank you for sharing that , with the audience and I appreciate your time.
[00:36:27] Amrutha Suresh: And thank you so much for having me. It was a pleasure.
[00:36:30] Randy Likas: Of course. Well, that’s another episode of Revenue Lounge. Thanks so much for everyone, , listening.
Take care.




