Moving Beyond Experimentation: How Enterprise AI Transformation Really Works
Insights from Pino Soro, Chief Business Transformation Officer at Quickbase, on The Revenue Lounge podcast
Executive Summary
Enterprise AI has moved past the experimentation phase. But for most organizations, the promised transformation still hasn’t arrived. Pilots succeed, executives celebrate, and then nothing changes at scale. Pino Soro, Chief Business Transformation Officer at Quickbase, has a sharp explanation for why: pilots are designed to work. They’re not the problem. The problem is what comes after, and most organizations aren’t building for it.
In this episode of The Revenue Lounge, Pino lays out a framework for what it actually takes to move from isolated AI experiments to durable enterprise transformation. One built around the conviction that the boring foundational work of data, governance, and context is the real job, not a prerequisite to the real job.
The conversation covers why context is the true competitive moat in an AI-commoditized world, how Quickbase restructured its entire go-to-market operations team to operate like a product and engineering organization, how to decide what stays human and what gets automated, and why transformation is ultimately people work, not technology work.
Pino Soro has spent two decades solving messy operational problems across high-growth technology companies. Most recently at Mimecast, he served as Chief of Staff to the CEO and SVP of Business Transformation, where he supported taking the company private and built the Business Transformation Office responsible for driving strategic value-creation programs post-transaction. At Quickbase, he now leads what the company calls Enterprise Transformation, which is a newly unified organization that brings together RevOps, systems and architecture, and data analytics and engineering under one mandate: redesign how the business works, not just bolt new technology on top of old processes.
The Real Reason AI Pilots Fail to Scale
Most conversations about AI failure focus on the wrong thing. The technology didn’t work. The data was bad. The use case was wrong. Pino’s diagnosis is more uncomfortable: most AI pilots don’t fail. They succeed. And that’s exactly what makes scaling them so difficult.

Pino Soro
Chief Business Transformation Officer
The thing about pilots is they're kind of designed to work. You take your best people, you take a really clean use case, you put a bunch of attention on it, and then unsurprisingly you get to whatever metric you assigned to it. The challenge is when you try to scale it, it usually dies. Because the thing that made it work wasn't necessarily the AI. It was the attention and wanting to prove a hypothesis.
The organizations that have moved past this trap, Quickbase included, have discovered that scaling AI requires three things: data and context you can trust, a way to build something once and reuse it across different problems, and someone whose job it is to make sure it still works six months later. Most organizations skip all three.
The shift in mindset Pino describes is counterintuitive: the data work, the governance, the plumbing — the things that sound the least glamorous are actually the most durable parts of the work. The pilots are just proof that it’s worth doing. The foundation is the job.
Context Is the Moat
If there is one idea at the center of Pino’s framework, it’s this: context is the competitive advantage that no competitor can replicate overnight.

Pino Soro
Chief Business Transformation Officer
We are all reading the same literature. It all points to the fact that models are becoming commoditized. What nobody else has is our business context — how our business works, what our data actually means, why the Q2 launch points to this specific thing and not the other three ways it could be interpreted.
The failure mode he describes is a familiar one. Take a best-in-class model. One that knows everything about the world, and drop it into an organization with no internal context. It becomes confidently wrong. It doesn’t know what your ARR definition means, how your pipeline is structured, what your renewal signals look like. Without that context, the model hallucinates plausible-sounding but organizationally false answers at machine speed.
Give that same model your context, your definitions, your connected data, your encoded processes, and it becomes useful almost immediately.
The deeper strategic point is that context has an opposite trajectory to models. Model quality is converging; everyone’s getting access to the same improvements at roughly the same time. Context is diverging. The work you do to make your business legible to both humans and AI compounds over time. A competitor could copy your tools tomorrow. They cannot replicate years of accumulated organizational context.
There’s also a practical infrastructure benefit. By codifying business context in markdown files and systems of record rather than burying it inside a single vendor’s platform, organizations set themselves up to be LLM-agnostic — able to swap underlying models as better ones emerge without rebuilding from scratch every time.
The Four Properties of Data That Actually Works
“We just need clean data” is the operational equivalent of “we just need better communication.” True in principle, not actionable in practice. Pino’s team at Quickbase has broken it down into four distinct requirements, each necessary, none sufficient alone.
- Clean: Canonical and correct. The basics. But this is where most data conversations stop, and it’s only the first of four.
- Connected: Accessible across systems rather than siloed in 40 separate places. The question isn’t just whether the data is accurate; it’s whether the systems that need to use it can reach it in a reasonable way.
- Contextual: Defined. This is the layer most organizations skip. Without semantic definitions that tell an AI model what a number actually means, for example, what “ARR” means in your business, how you define churn, what “expansion” includes etc., the model will use your data and produce answers that are technically derived from your data but organizationally meaningless. Or worse, organizationally misleading.
- Governed: Owned. Someone is responsible for each definition, and that responsibility is ongoing. Data rots. Definitions evolve. Without governance, you build a context layer in Q1 and discover in Q3 that it no longer reflects how the business works.
Point AI at bad data and you're not gonna get an answer slowly. You're gonna get it way faster and it's going to be more disruptive.

Pino Soro
Chief Business Transformation Officer
The four-part framework also changes the question of where data should live. Snowflake as a central data lake is the right architecture for many organizations. But sometimes pulling directly from a source system like Gong’s transcript data, for example, is faster and carries more contextual richness than the cleaned version in the warehouse. Knowing the whole landscape makes it possible to make the right call rather than defaulting to one answer for everything.
The result is that individual customization and organizational consistency stop being in tension. A rep can build their own voice, their own prospecting workflow, their own prep ritual, but when they ask a question that has a definitive organizational answer, they get it right.
Read the complete transcript for more insights on building an operating model for enterprise AI.
Restructuring the Team: From Ticket-Takers to Product Builders
One of the most significant changes Quickbase made wasn’t in its technology stack. It was in how the team that builds and maintains AI systems is organized and how it thinks about its own work.
The old model: RevOps, enterprise business systems, and data engineering in separate silos, operating on a ticket queue. A request comes in, gets resolved, and the team moves on to the next one.
The problem with this model in an AI context is fundamental. AI-powered systems aren’t tasks. They break. They drift. They become less efficient as business processes evolve. They need to be engineered with low latency in mind because they’re often chaining signals across multiple systems. Treating them as tickets means no one owns the outcome, and no one notices when they stop working.
Pino’s team made a deliberate shift to a product and engineering model: scrums, ceremonies, Jira, roadmaps, business product managers who own the relationship with each function, and technical owners who built the system and are responsible for maintaining it.
We stopped looking at it as tickets and tasks. It's all products we're building, and they have to be maintained. They have to work over time. They have to be optimized.

Pino Soro
Chief Business Transformation Officer
The roadmap change matters as much as the structural one. When you have a roadmap that’s aligned to business outcomes, one you can bring to the executive team and have them see where their goals fit in, the team stops being reactive and starts being a strategic partner. The goal is to stop firefighting and start building.
What Stays Human, What Gets Automated
The question of where human judgment ends and automation begins is one Pino comes at from an unusual angle. Most organizations start by asking: where can AI help? His team starts from the opposite end.
If we started from where can AI help, we're gonna find a hundred things we could do. And then we're gonna spread ourselves thin. We end up a little bit better at everything but we didn't really transform anything.

Pino Soro
Chief Business Transformation Officer
The more useful question is: what must stay human? Everything else becomes a target for automation or augmentation.
The framework he applies: deterministic work with a right answer goes to automation. Open-ended reasoning gets AI with a human in the loop. The genuinely human work like judgment, customer relationships, accountability, and reading the room, is where people should be spending their time.
AI is really good at deterministic work. An agent is just like an employee. You still have to give it guardrails and tell it what it can and can't do. Deterministic is a lot easier there.

Pino Soro
Chief Business Transformation Officer
The practical application in go-to-market: a rep’s actual value is in the non-deterministic work – how to sell, how to have the conversation, how to read a room. Everything that gets them to those conversations like maintaining processes, finding data, pulling transcripts, or building prep is a candidate for automation. The goal isn’t fewer reps. It’s reps who can carry a larger book of business because the friction that used to occupy their time has been removed.
Change Management: The Part Nobody Talks About Enough
Every transformation requires it, and it’s consistently the part that receives the least systematic attention. Pino is direct about what makes it work.
Executive alignment is the prerequisite. Without a CEO and leadership team who are genuinely committed to redesigning how the business works including the parts that change roles and break existing processes — the transformation will stall at the first point of resistance.
If it's just you thinking about it, the executives and their subteams are gonna continue their day jobs. There has to be a unified front that says we need to change the way we're operating.

Pino Soro
Chief Business Transformation Officer
Below the executive level, the work is about helping the people who live inside these processes understand that the change is being done for them, not to them. Quickbase’s RevOps leader built this trust by being proactive rather than reactive — not waiting for problems to escalate but coming to sales and customer success with a view of where processes were breaking and how they were going to fix them.
The third element is communication. It has to be constant, specific, and honest. Celebrate small wins. Break large projects into visible weekly progress. Show the organization that things are actually changing.
Celebrate every win, no matter how small. You unlock an automation that helps somebody do their job, talk about it. Break down the work smaller. People lose the thread on nine-month projects.

Pino Soro
Chief Business Transformation Officer
The hardest thing to change, in Pino’s experience, isn’t technology or process. It’s the human instinct to protect what was built before.
When you're doing transformation, you're usually telling somebody the thing they did forever is no longer viable. People hold on to that history. You have to acknowledge that what got us to this point was all goodness. But it's not going to get us to where we need to go.

Pino Soro
Chief Business Transformation Officer
The Build vs. Buy Decision in an AI-Native World
The traditional logic for buying software was simple: building was too expensive and too slow. That calculus is shifting, and Pino’s team is actively renegotiating it.
His heuristic: buy when the effort to build would pull resources away from the core roadmap, or when a vendor is already solving the problem better than your team could in reasonable time. Build when the use case is specific enough to your business context that a generic solution won’t capture the nuance you need. And when you have the architecture to build it right.
The bigger strategic question he’s wrestling with is about legacy vendor footprint. When a platform like Salesforce moves toward a headless model, it’s an acknowledgment that the interface layer is being abstracted away. Reps already aren’t going into Salesforce to do their work, they’re using other tools that feed data back into it. The question isn’t whether to use Salesforce; it’s how much of the platform you actually need.
On the build side, the product-mindset shift applies here too: every system needs a named business owner, a named technical owner, and documentation of what it’s integrated with and what data it touches. This is how you avoid the recurring nightmare of an integration built by someone who left and nobody knows how to fix it. It’s also, as Pino notes, how you become best friends with your CISO.
What Pino Wishes More Organizations Would Ask Themselves
Before closing, he returns to the thing he finds himself repeating most often with his own team.
Figure out what your AI operating system is, the foundations you need in place around data, systems, and governance. Because what you'll find is the business is gonna come at you with: Claude just released this new connector, I want it tomorrow. If you don't have those foundations in place, you're gonna be the office of no, because you're just trying to protect the business."

Pino Soro
Chief Business Transformation Officer
Getting the foundation right is what transforms the AI team from a bottleneck into an accelerant. Without it, every new capability becomes a fire to triage rather than a building block to plug in.
The Bottom Line
Pino Soro’s framework cuts through a lot of the noise around enterprise AI transformation because it starts with an uncomfortable truth: the technology is the easy part. The hard part is the organizational work like the data definitions, the governance structures, the team redesigns, the change management, the communication. The things that don’t show up in a demo.
His most important point is also his most counterintuitive: the competitive moat in an AI-commoditized world isn’t the model you use. It’s the context you’ve built around it. The years of work you’ve invested in making your business legible to both humans and AI. Nobody can buy that. Nobody can replicate it overnight.
This work is actually people work more than it's technology work. All of this is anchored on people. And going into this purely we're gonna bring in tech and reduce cost. That's a shorter path in the sense that you're gonna find it's really hard. Anchoring on the people and what outcomes they're meant to drive helps you answer a lot of questions a lot faster.

Pino Soro
Chief Business Transformation Officer
Know a transformation leader, RevOps practitioner, or enterprise operator with a real point of view?
We’re looking for practitioners with genuine experience, not polished keynote stories.
Pino Soro is the Chief Business Transformation Officer at Quickbase. He can be reached on LinkedIn.
This blog is based on his 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
Randy Likas (00:03.148)
Enterprise AI and go-to-market has moved beyond experimentation and hype. But for most organizations, the promised transformation still hasn’t arrived. Despite massive amounts of investment, many AI initiatives remain stuck in pilots, held back by fragmented data, misses business context, and operating models that were never designed for AI.
Hello everyone, welcome to another episode of the Revenue Lounge Podcast. I’m your host, Randy Likas. And in today’s episode, we explore what it really takes to move from AI experimentation to enterprise transformation.
Read Full Transcript
Joining me today is Pino Soro. Pino is the Chief Business Transformation Officer at Quickbase. With a career spanning across go-to-market strategy, operations, and enterprise transformation, Pino has led large-scale organizational change across high-growth technology companies. At Quickbase, he’s focused on building the operating model, data foundation, and organizational capabilities that enable AI to move beyond isolated experiments and deliver measurable business outcomes at enterprise scale. Pino, thanks so much for joining me today.
Pino (00:59.591)
Thanks for having me. You make me sound so impressive. Thank you. It’s excellent.
Randy Likas (01:02.08)
Well, you know, you are impressive and that’s why we want to have you today. So Pino, I usually like to start these podcasts just kind of getting to know you a little bit. So maybe you can start and walk us through a little bit about your background, maybe your career journey and what your current role is at Quickbase.
Pino (01:16.125)
Yeah. Look, I think like a lot of operators, I’ve had a thread through my career is just, you know, solving messy problems and trying to make businesses run better. It’s what I enjoy doing. It’s I think why a lot of people end up in operational roles. You mentioned what I’m doing at Quickbase. We just actually restructured into this organization called we’re calling it Enterprise Transformation. It’s actually RevOps, it’s systems and architecture, and it’s data analytics and data engineering. And essentially
The job of this team is to transform how the company operates, right? Using AI and automation, really getting ahead of like how do we actually truly redesign the way the work is done, not just buying technology and layering on top. And so that’s it’s either where, you know, we look at this from the perspective of like how work gets done, where’s their friction in the systems, which roles need to change, and ultimately what the business gets out of it. So that’s what I’m doing here. I mean, I think if I just look back.
My entire career’s been the same thing on repeat. It’s like take a bunch of messy stuff and see if you can make it better. And like, look, it’s an it’s not an understatement. Like, AI is allowing us to do this at a speed we never thought possible. And so, you know, the interesting thing about it, AI is fairly overhyped. And that’s what keeps the job interesting. You know, there’s a lot of promise. It’s not all real. I mean, I think we all have to realize that.
Randy Likas (02:35.214)
Yeah, and I agree with that. I think there is a lot of hype out there and there’s a lot of people who are doing what I would consider like tactical AI or you know, just sort of looking at what’s available through like third party systems. I think where it really starts getting difficult is when they start trying to embed it into like workflows and and sort of internal transformation. And that’s the part I wanna kinda d d dig a little bit deeper with you, sort of the next question. So I think you know, a lot of AI pilots or projects have either been stuck in pilot mode or they can’t quite haven’t delivered the on the hype that they were hoping that would deliver on. Why is it do you think that many initiatives fail or to make that leap from sort of experimentation to true enterprise transformation?
Pino (03:23.923)
Yeah, that’s a question. I actually think a lot of pilots succeed, which is kind of the problem, which is, you know, the thing about pilots is they’re kind of designed to work, right? You take your best people, you take a really clean use case, you put a bunch of attention on it, and then unsurprisingly it’s like, hey, look at all the sour hours we saved, and whatever metric you assign to it, you’re probably gonna find you got to that metric. I think the challenge is like when you try to scale it, it usually dies. And it’s because the thing that made it work.
Wasn’t necessarily the AI, the AI part of it. It was like the attention and wanting to prove a hypothesis. And so, look, we’ve made the same mistake ourselves. Like I will tell you throughout this conversation, none of us have it figured out. We’re still trying to figure it out. And like we’re trying to work through what works and what doesn’t. I think that what we found is that scaling it and getting out of a pilot to making it work requires a few things. It needs data and context you can trust with AI. Like I just think those foundations.
It needs a way to build something once and then reuse it across different problems and use cases. And I think it also needs somebody to own it to make sure it still works six months later. And so, like most companies, we were skipping all three of those things, honestly. Like, we were in that same position. We’re like, hey, there’s a bunch of scattered stuff. Some of it works. The stuff we put attention on worked better than others. But then we were left wondering like, why are we making any real and durable progress?
And we made a real change in April this year and even like in the back half of last year. And so we started to run it the other way. Like all that perceived, like really boring foundational work, data, governance, plumbing, that’s actually really the job. That’s the stuff that’s actually gonna make this stuff work in the long run. And so then the pilots are just proof of it’s worth doing it. But that like that sounds way less glamorous, but it’s actually the more durable aspect of this is like putting that foundational work in place. And that’s what we’re finding is working for us.
Randy Likas (05:21.74)
Yeah. So I wanna I want to dig into that context in a moment, but before I do, where do you start, right? So cause very rarely do you start with the technology. Do you start with the data? Do you start with the ownership or do you start at like the business? So like what are we trying to solve? Or we’re trying to where are we trying to get more efficient and in in where it’s sort of like you how do you prioritize? ‘Cause they’re all very, very important, right? But sort of how do where does it originate from?
Pino (05:43.708)
Yeah, yeah. So it’s a little bit parallel in some cases, meaning two paths run at the same time. There were clear foundational things we know we had to get done, right? We needed to understand what signals were we trying to build automations and workflows on top of. And do we have that data in a place we can access it? And is it canonical? And have we built like semantics over it to help us understand it? And so there were some things that were obvious, like.
Things like ARR and pipeline and Gong transcripts, like those are like sort of foundational. You’re gonna probably use in a lot of different areas. And so we started doing that anyway. We also took it from the business side of it too, where our RevOps team was really trying to look at where is the friction? Where are the workflows not working? Because then that was like, okay, we need to go build those foundations just as fast. And when those things mapped together, it worked out really well. I also think.
The structure of the team actually does matter. We went from a very traditional structure where we had operations here, we had call it enterprise business systems, which was systems and architecture, data engineering, we had analytics over here, and we restructured to say, how is the work actually getting done in an AI native world? And the reality is we’re like, we have to pull all this together and really think about how do these how do these products flow through? And that that’s a real sea change because.
We stopped looking at it as tickets and tasks. It’s all products we’re building and they have to be maintained. They have to work over the time. They have to be optimized. You have to engineer them the right way. So the latency is low because a lot of times you’ve got systems jumping to systems and pulling signals from different areas. And so the simple math is: I think it depends on your current maturity as a business. For us, we saw we kind of had to do with those all at the same time because we just we had a mandate to transform quickly and we’re like,
We really have to go solve this in a different way. So we started with the restructure and then we really went through the paces of how do you get this in place. The one last point I’d love to make, governance was key. It’s really hard to do this if you don’t have tight partnership with security, SRE if you have an SRE organization, legal if you have a strong legal organization. They’re all on the hook to keeping the business safe, just as we are. And so we really wanted to build that partnership and put that in place too.
Randy Likas (08:04.214)
Yeah. When you started to build this out and you started to identify some of that friction, I’m curious like where that friction was. Was it in the data? Was the friction in the processes? Was the friction in the change management, right? In terms of what we’re trying to do. Can you unpack that a little bit?
Pino (08:18.769)
Yeah, yeah. Foundationally it was at the business process level. It is, I’m an AE and I have to do my job. And my job is really to find and close business. But what I spend a lot of time doing is maintaining process and trying to find the data and getting into gong and pulling transcripts out and dumping in the GPT, like all of that human glue was what we’re really targeting. Because that’s if you want to drive impact, go-to-market roles.
Are great place to start because they touch revenue and they touch customer value. And then engineering as well, right? Because engineering organizations are quite large. We’re lucky to have a really strong CTO who’s really thought through how do you superpower engineers as well. But we focus a lot of our time on the go-to-market side because it touches revenue. And so we started with those basic problems of reps struggling, CSM struggling, renewal specialists, you know, not knowing what the health signals are and how do we get ahead of the next renewal. And so a lot of that.
Foundational data and semantics started with those data sets because we knew those are the ones we had to unlock and build automations on top of. So it really did start at business problems and like specifically role based problems.
Randy Likas (09:31.832)
Very good. All right, let’s dig into that context comment because one comment you had made in the in the green room was and I think it was really interesting. Context is the moat, right? What does that mean in practice and why do you believe that context is becoming more and more important specifically in the AI models themselves?
Pino (09:48.04)
Yeah, it’s a great question. And I’m sure we’re not the only person that coined that. It just really made sense when we started to contextualize what we were trying to do. So, like, look, we are all reading the same literature. And it all points to the facts that models are gonna they’re becoming commoditized, right? You know, Claude gets better, and then you’re like, it’s all about Claude, and I’m sure GPT will jump up and something else will happen in between. And the reality is we all know we’re all buying the same ones. Everybody’s standardizing on these.
What we realize is what nobody else has is our business context, how our business works, what our data actually means, why something like the Q2 launch, which is a real thing, right? Like the Q2 launch points to this specific thing and not like the other three ways it could be interpreted. And like the thing about Claude is it’s amazing. We love it, we’re building federated skills on it, we’re doing really interesting stuff, but it’s a great model that like knows everything
Pino (10:44.049)
Everything about the world and like nothing about your company or your context. Like without company and context, that’s all it is. And so if you drop a really good model into a company with no context, we joke about this, it’s confidently wrong, right? Because it doesn’t know what any of your numbers mean. And so, you know, you give that same model, and this is what we’re finding ourselves, you give that same model your context, your definitions, your connected data, your encoded processes so it can use it, it gets useful very fast. And so for us.
Context as the moat wins because we know the model gap will be keep closing and everybody’s model is gonna get better at the same time and it’s gonna stop being an advantage. But context we think is the opposite. It’s like it’s the work we did to make our business legible to humans and AI. And nobody else can do that. You can’t replicate that. That’s really our secret sauce. And so a competitor could copy our tools tomorrow.
Pino (11:36.412)
It’d be really hard for them to build our entire context from scratch and like because that’s like years of work. And so that’s where we thought the effort was really going to be put in place. And I’m very very grateful our head of ops intelligence and engineering is a a guy by the name of Tim Familari who really saw this thread and really started to build that muscle in the organization. It’s paid off dividends. It’s like some of the best foundational work we’ve been able to do.
Randy Likas (12:00.297)
You know, I love that because I was I was speaking with another one of our clients who leads transformation and he said a very similar sentiment to what you what you just shared, which is like eventually we’re gonna get to this place where everybody’s going to be using AI. We’re all gonna be using the same models, right? What you know, if we’re all using the same models, like what is left?
What’s left is our data in in and our in the context of our data and how we are able to capitalize on that is really what’s gonna be sort of that strategic advantage. And I think that we just can’t you know, but your to your earlier point, like what does the individual definition of ARR or churn or like what does that mean to us and not, you know, generally is the really important thing. So the data and the context of that data I think is is really important.
Pino (12:49.073)
And and one point to add there is that’s we think that’s what’s gonna allow us to be LLM agnostic eventually. Because like at the end of the day, if you codify all that in markdown files and in your systems of record, then you can swap in LLMs a lot easier, right? It just becomes less of you less of a lock-in from that respect.
Randy Likas (13:08.832)
Yes. So you reorganized enterprise transformation to operate more like a product in an engineering team. You referenced that. Can you tell more some more a little bit about that? Like what prompted that shift and what advantages does that create sort of as you scale?
Pino (13:23.089)
Yeah, it’s a really good question. It was a it was a learning, honestly, that we said, look, if so actually where this started, Randy, is we started this with an AI Scrum team where we said, No, we’re gonna do, we’re struggling with connecting the dots and getting work through the system. Let’s pull some of our best people, put a scrum team together and say, Forget what function you’re in. Let’s go tackle a handful of problems. And we saw an unlock happening really quickly. They were working real time, they were knocking down data layers and
And systems automation and working with security on integrations. And the signals was like, okay, this is telling us something. It’s telling us our old, old siloed model wasn’t working. And so we said, let’s think about how the work has to get done. That’s what started the structure. In there, we said, one of the things we have to break is the old model of we operate based on tickets. You get a ticket in, you knock it out, you move on to the next one.
The reality is these things don’t get done instantly. And so we started to say if we keep operating a ticket model, we’re constantly chasing a problem or very reactive. We have to shift it to say, what is the business need? And like, let’s build a roadmap that’s very aligned with business problems and business outcomes. To the point we can bring that roadmap to our executive team and they can understand it and say, Yeah, I can see where our goals fit in there. And so, in doing that, we said, okay, you go down that path, these things.
Are really products. And what we’ve actually replicated is a product and engineering organization. We operate scrums and ceremonies. We operate out a Jira. We have roadmaps. We have business product managers that work closely with the business and kind of own what has to get built. We have teams that then take those and build it out. And the whole goal was these things have to sustain over time because they’re gonna break. They’re gonna be no longer be efficient. We may see latency issues, we may see
Pino (15:12.753)
You know what, we built it this way. We now have a new way. We can make it faster by doing this. And we just thought that was a good model to replicate. And so that’s what we’ve been doing. And it’s really working. Is it perfect? It’s never gonna be perfect, but we’re moving faster than we would have been otherwise.
Randy Likas (15:27.66)
Yeah. You know, I wanted ask you about the change that’s involved, right? Any transformation always requires change and there’s a change management piece to that, but you guys are doing it at a scale right now where it’s you know really impacting sort of you know every aspect of revenue and change is hard, right? And there’s a lot of stakeholders that you that you that you need to align with and and and sort of break the way that we’re doing things. Can you talk about how do you how do you manage that change and what’s critical to manage that change?
Pino (15:55.14)
I think a big piece of this, you have to have an executive team that’s really bought in to go do real transformation and break some glass and recognize that it’s gonna change things. It’s gonna change roles, it’s gonna change processes. We’re very fortunate. We have a CEO, Kim Eaton, who is deeply supportive of we have to redesign how the business works. We have a strong executive team that believes it. So that helps because without that it’s really hard. So that’s one piece of it. I think.
Partnering then the next level down with the people that have to live within these processes daily and helping them understand how we’re gonna make their jobs easier is another big important piece. So for instance, our RevOps team, our head of RevOps is an incredibly talented guy named Tom Van Langen who has really worked with sales and customer success and CX to really be proactive and not reactive to say, here’s how we have to think about where we’re going.
Building skills for them to help them do their jobs, looking at where the breakdowns and process are, and then saying, we’re gonna go target this, changing the way we forecast, and building that trust and partnership where you’re not a you’re not a ticket taking service organization, you’re a proactive looking around the corners business partner that’s helping them change the way they work. And so that’s important. I think the third piece is you have to talk about it constantly within the company and show what’s working, what’s not. And look,
We haven’t perfected this either. Like we were getting better at this of saying, like, hey, celebrate every win, no matter how small it is. You unlock an automation that helps somebody do their job, talk about it. Show the business that you’re capable of moving quickly. And breaking down the work smaller, I think what one thing we learned was we would take projects and be like, this is a nine-month project. People lose the thread.
Pino (17:44.402)
And then they’re just like they’re on to the next thing. It’s like you gotta break it down and say, like every week we’re gonna make progress, even if it’s small, and talk about it so the business sees that you’re actually changing. And so I think you can’t do one of those things. I think you have to do them all. But I really think starting with your executive team is really key because ultimately their teams are gonna take their direction from them. And so they have to be really bothered.
Randy Likas (18:05.11)
Yeah, it’s if you’re thinking about designing it like as a product, it’s almost as if you have to design an internal product marketing team, right? To inform right, to inform the executives in terms of like how things are going and what’s gonna what we’re solved for, right?
Pino (18:14.481)
Yeah, it’s a great way to look at it, yeah.
Pino (18:19.889)
Yeah. I’m gonna steal that by the way. That’s a good way to look at it.
Randy Likas (18:23.31)
So you know, I think one thing that often gets confused or debated is, you know, AI is often positioned as a way to replace work. But the way that you’ve described it is, you know, it’s about redesigning, you know, the roles and the processes. I guess the my question is like, how do you decide which work should be automated and which work we still have to have that?
Randy Likas (18:49.516)
Human judgment layer you know that’s required or or essential.
Pino (18:54.833)
Yeah, it’s a really good question. And honestly, again, as many things I’ve said before, we haven’t fully figured this out, but here’s at least the way we’re thinking about it. We’re trying to ask ourselves the question to your point, what has to stay human versus what AI can do? Because we actually think this exposes what you need to automate and augment around the person, right? I think if like if you fundamentally flip that question, it changes the answer. Because if we started from where can AI help?
We’re gonna find a hundred things we could do. I mean, that’s just natural because it can help in so many ways. And then we’re gonna spread ourselves then. And we’ve been guilty of doing this. And then we end up kind of a little bit better at everything, but we didn’t really transform anything. And so starting from like what must stay human kind of protects the judgment and the relationships and the hard calls and lets us go aggressive on everything else. Because, you know, this idea of deterministic versus non-deterministic is really helpful. There’s AI is really good at deterministic work.
Pino (19:52.53)
It’s not that great at none. Like I think everybody’s got this dream of like the agents can figure it out. An agent’s just like an employee. You still have to give it guardrails and tell it what it can and can’t do. And deterministic is a lot easier there. And so in practice, deterministic work with a right answer goes to automation. Open-ended reasoning gets AI with a person in the loop. And the genuinely human work, like judgment, customer relationships, accountability,
Things like that is where we want people spending their time. And so, like for us, the goal is not to have fewer people. It is to say, one, if you can just make the person more productive, that’s a win in itself, right? If you can give a rep a bigger book of business because they can get through more deals, like that’s a win. If it speeds up cycle times, that’s a win. If it does actually change the role meaningfully, that’s a win as well. But like all of those help, right? Versus just saying,
We’re gonna throw automation everything and hope for the best. That’s like a bolt on approach. We tried it, it doesn’t work. It’s just really hard unless you get to the root of your business and what matters.
Randy Likas (20:51.181)
Yeah. Can you give us a couple of examples to to the degree that you I don’t want you to share anything too confidential, but but I’d love to hear some specific use cases or pro you know problems that you all have been able to solve today and sort of what the what the impact of that has been.
Pino (21:07.729)
Yeah, I mean, one that we’re really deep into is how do you think about what a rep does every day? Reps get up in the morning, they have a quota, they’ve got a prospect list, they’ve got leads coming in, or they have a or they’ve got a book of business if they’re doing expansion. And what do they naturally do is they’re trying to figure out what do I do first? Who do I go talk to? We’re trying to think about breaking that down and like what if a rep
And this is not fully real yet, but like this is what we’re building towards. What if a rep could wake up and using all of this intelligence, transcripts and signals and what a customer’s doing on LinkedIn, you could pull that all together, synthesize it, and give them a playbook that they wake up every day and it’s like, this is exactly where you spend your time. These are the accounts you need to talk to. It sounds like that’s actually possible now in a way it never was before because of the speed of being able to.
You know, actually translate all that. And so that’s a real use case if you think about it, that touches a lot of things. You need a lot of context layer and semantics in place. You need canonical data models. You need MCPs into the right systems of record, whether you’re using Gong or some other tool in Salesforce and you know Gainsight, whatever is you’re using. You need an understanding of how a rep does their job. And if you pull that all together, you could theoretically change the way and we’re building this right now. We’re seeing progress on it, but you can change how they do their job.
Pino (22:31.587)
Pretty meaningfully. And like that’s that’s the end goal. It’s like reps are really important, but what they’re really good at is the non-deterministic stuff. How do you sell a client? How do you have the conversation? How do you read the room? Automate the hell out of everything else to just get them to that point.
Randy Likas (22:44.14)
Yeah. Yep. Yep. So what’s the unit of measurement on on that? Is it is it time saved? Is it ultimately it’s about revenue, right? But there’s two sides, right? There’s revenue and there and there’s efficiency. And I guess maybe it’s a loaded question because it’s probably a a a little bit of both, right.
Pino (23:04.283)
Yeah. I’m gonna be honest with you. The real answer is we’re not getting that wrapped up yet on measuring every detail of it because we have real conviction of we know where the friction points are, we know what matters in terms of how they do their job. And it’s not to say we won’t measure whether this automation’s working and it’s firing properly, but like in terms of the end goal, the end goal we’re trying to build towards is can you know, like one example.
Can you get to your number with the same, like double your number with the same amount of reps? Can you get more bookings per rep? Can you give more books of business to a CSM because they can do their job? Like that’s the way we’re thinking of it. Candidly, we don’t have measurement for all this yet. And we’re actually okay with it because we don’t know what we don’t know yet. We’re trying to get to like really unpacking and rebuilding the processes. And then we’ll know how much the role changes and what really matters from a measurement standpoint. But I think look, we fell down this trap.
Pino (24:04.637)
Can we measure every aspect of this? All your board’s gonna ask the same thing. Can you measure every aspect of it? We’re trying to take it a little bit differently to say, look, here’s what we’re gonna do. We’re gonna go deep on a couple of roles, really redesign them, and then figure out what the eye of the prize eye in the prize is, and then go do that measurement without getting over rotated there. Because it’s just you can really get you can really get down a rat hole pretty quickly trying to figure that out without actually starting to do the work first.
Randy Likas (24:30.848)
Yeah, listen, I appreciate the candor, right? The we haven’t quite figured it out because I don’t think anybody really has. And I think that the way the rate of you know how things are changing makes it really difficult. And what I really like about what you said is like we’ve got the conviction, we know that this is the right thing to do, we know that we’re gonna trip and fall a couple of times, and that’s okay, right? That’s part of the transformation. The journey and the learnings along the way is just as important.
Pino (24:57.233)
Yeah, I the other piece I can tell you on the measurement front, maybe, is one way we’re trying to think about it too is maybe more holistically, right? In terms of like one, first of all, it’s gotta make sense for your business, right? Like every business is at a different maturity or visibility or where they have data. So like put that aside because honestly it’s gotta make sense for where your business is. But like we we’ve sort of looked at like those table stake measures, like I just said, at the use case level and we just weren’t sure. But
I think like if we try to take a step back and say, like, what if we built a maturity score that looks at a variety of metrics that tells us whether we’re going down a path? And like we start to look at a maturity score around like breadth and depth and the value we’re bringing to the org. And we’re gonna try that as a holistic score because we’re trying to say, like, any one of these things could move the needle, but like, what are like the big needle movers that we can actually put real measurement against and then just look on a quarterly basis? So
That’s the approach we’re taking. That may only make sense for our business based on where we are, but it’s just a different way to look at it to say, like, how do you just gauge the overall maturity of AI in your organization and pick some measures that you think are really directional and just measure them maniacally? And as they improve, you can give yourself a sense of like, are we improving as an organization? Not just are we getting more automation out the door.
Randy Likas (26:17.034)
It i want to i want to ask some questions about like the technology side and the data side for a moment because i had a really interesting conversation the other day and right now you the build versus buy conversation is really kind of central and everybody’s kind of thinking about that and you know the traditionally you used to buy software because
Randy Likas (26:40.338)
You know, it required a ton of time and resources to build it. And so it like it made sense for us to go ahead and buy software. But nowadays like with vibe coding and like the it’s easier to build an experience layer, right? And you might not need to have th package solution like I’ll gain cyclong whoever it might be. How do you decide you know the question is how do you decide when you want to build something versus when you want to buy something.
Pino (27:10.065)
Yeah. It’s a easier answer for us because we have too much tech as it is, and we’re actually trying to strip back the amount of tech we have in this business. But part of the way we’re looking at it is one, the effort that goes into it. I mean, if it’s gonna, for instance, were I think everybody’s going down the path of like how do you know your token usage and like how much of these automations and agents are costing you, and like how do you really look at that data? I’m sure we could build that. We’re gonna go buy that.
It’s just an easier thing to buy because I don’t want to take our data engineering resources and other resources to build something that somebody on the market could be doing better. I think though, where it’s where it’s changing our thinking is on our legacy vendors that we have. Salesforce is going completely headless. We’ve all read that headline, right? It’s an acknowledgement that like you maybe don’t need people to go in like our reps really don’t go into Salesforce. They’re really using other tools to get what they need done.
Pino (28:05.425)
And then that feeds into Salesforce. So part of this is like what is the effort to take to build it? Part of it is what tech do we already have? And is that good enough? Or are we already starting to abstract ourselves away from it where we’re gonna probably start to, you know, maybe not churn, but certainly reduce our footprint on that technology. And then on the build front, we also try to look at have enough architecture in place in terms of like what is a good build look like.
So we have clarity on what is worth building. So for instance, we’re a Workato house. We have Workato, we have Snowflake, we have Claude. We are deciding where we build and what’s worth building. Because to your point, sometimes you get down the path where you’re like, should we really build this? Or is like, is it just easier to go buy what we need? And so I don’t know if there’s any perfect answer. I think some of it’s anchored on how much resource is it gonna take you? And does that, does doing that?
Take you away from your core roadmap of what you’re trying to deliver to the business and what you’ve committed to. And then I think the bigger question we’re all gonna ask ourselves is, do we need all this SaaS? And it’s not like the whole SaaS apocalypse. Like that’s, you I think that’s a lot of hyper hyperbole. It’s more about what is your footprint on that technology? Do you really need all that coverage? Are you just kind of like using a claw scale to get what you need in and out of it?
Randy Likas (29:25.302)
Yeah. I think the other thing I would build on that as well and I and I want to get your perspective on it is the total cost of ownership, right? Is do we wanna own that moving forward and what happens if the person that builds it leaves and who’s gonna maintain it, right? How does that factor in and play into into the decision?
Pino (29:42.61)
Yeah, I mean it’s one of the reasons we made this shift to try to be more of a product mindset that when we build something, there’s somebody name on it. There’s a business owner’s name on it who sort of owns a business outcome. There’s a technical owner’s name on it who built it from a technology standpoint. We’ve documented how it was built. And so we don’t lose it. Cause we’ve run into it ourselves, right? You buy technology, you integrate it, that person leaves, and everybody’s like.
What was it integrated into and who did it and what is it touching? And like now all this stuff is breaking. And so we’ve learned our lesson there. I think it there is some just like hygiene we’re trying to put in place around when we build something, making sure it’s very clear. And on the technologies we own, we have a really strong head of business product manager named Nicole, who she’s built some of this out where every system of record we have clarity of.
Pino (30:34.419)
Who owns the contract, who owns the integrations, who owns the technology, what systems does it talk to, what data does it talk to? And by the way, if you want to be best friends with your CISO, that’s a good way to be best friends because that’s what they need. When something happens, they need that documentation. It’s their job to go to go fix it quickly. And so just doing some of that basic hygiene, I think, is really important.
Randy Likas (30:55.426)
When it comes to hygiene, and I’m specifically gonna ask it in the lens of like date you know, data hygiene. You know, we’ve all got you know, probably messy Salesforce instances, duplicate accounts, duplicate contacts, right? Like how as you’re building this new layer, like is your new source of truth s like a the Snowflake? How important is everything being written to Salesforce versus you know
Randy Likas (31:23.596)
Being having it as a part of Snowflake. Like what what does that look like?
Pino (31:26.767)
Yeah. I I think we’re like a lot of companies where we we’re like we just need clean data. If you get clean data, it’s all good. And like we we always talked about it. Yeah, it’s like it’s like one thing. It’s like clean data, it’s done. It’s like it’s actually I actually think and Tim on our ops team, it’s four things, right? We actually think it’s four things. I think it’s clean, meaning it’s canonical and correct, right? Like there’s that aspect of it. I think there’s a connected aspect of it, meaning like
Randy Likas (31:35.614)
Easier said than done.
Pino (31:56.37)
The systems it talks to, you know, because the it taught like the systems it talks to in like, is it living in 40 silos? Is it living in one? Like where is it connected to, right? Is it contextual? We talked about this. Like, is there a definition layer so the AI knows what a number means before it uses it? And is it governed? Like does somebody own each definition and or
Because if without that, it rots over time. And we all know this. Like you point AI at bad data and you’re just gonna get a you’re not gonna get an answer slowly. You’re gonna just get it way faster and it’s gonna be more disruptive. And so for us, we’re really looking at it as like AI won’t fix bad data unless you’re a data engineer and you’re using as part of your workflow. I think we’re trying to industrialize this by putting those pieces in place and and having a gate a data governance structure we didn’t have that answers those four those four questions. Because I think that gets you a lot closer.
Pino (32:47.249)
And then where it lives be matters less because we are Snowflake House. That is our you know our central data lake. But there is value sometimes like in pulling data from the system that exists, like Gong. Like Gong has a lot of contextual data within their transcripts, right? That we have it in Snowflake, but sometimes it’s better just to get it out of Gong because it has that can can context. Knowing the whole landscape.
Pino (33:13.137)
Makes it easier to say, okay, if we check these boxes, we can make the right decisions of when you pull from. And I think we’re, I’m very fortunate we have a really strong analyst and data engineering team that think through it that way, system wide, of like, it’s not Snowflake always. It’s like, what are we solving for? How do we get the fastest path and then build it that way and then build it repeatably.
Randy Likas (33:32.844)
Yeah, that’s really really interesting . I have one more question for you before we sort of transition into what we call the like the lightning round and more sort of top top of mind thing. What haven’t I asked you or or haven’t we addressed when it comes to to to AI transformation that you think I should have asked or you we we should discuss?
Pino (33:50.854)
I’m gonna I harp on this a lot with with my own team because I think we all funnily believe it. Like figuring out what your like what is your AI operating system, including of the foundations you need in place and data and systems and governance. Get that right. Because what we’ll find, and you’ll find, and I’m sure others are experiencing this: the business is gonna come at you with like, Claude just released this new connector, I want it tomorrow.
I want to start dumping data in it. If you don’t have all those foundations in place, you’re gonna be the office of no, right? Because it’s just you trying to protect the business. And so getting that in place unlocks a lot. And then where we’ve gotten this wrong and we’re trying to get it right now is and then make sure the business understands why we’re doing it the way we are, why we have governance, why we’ve built the foundations they do. We’re trying to keep everybody safe. So I think think about what is your AI operating system and what needs to go into that.
Because without that, you’re gonna be firefighting all the time because everybody wants to experiment all the time. And what they’re gonna end up doing is creating attacks because the minute they had a brick wall of data, they go right to your data team. And now your data team’s triaging that versus doing what they’re meant to be doing, which is driving the roadmap for.
Randy Likas (35:03.532)
Yeah. Very very good. Very helpful. Okay, we’ve got a few minutes left. Let’s go into the the lightning round. So first thing that kinda comes to your to your mind, biggest transformation killer.
Pino (35:14.895)
Ooh, biggest transformation killer. I think the biggest transformation killer is having a company that’s not ready for transformation. You gotta be ready to do it. If you’re not ready, you’re just gonna hit brick walls all day long. You have to have the appetite to do it.
Randy Likas (35:29.004)
And what tells you that that that the company’s not ready?
Pino (35:32.0)
When it’s not an executive level discussion, it’s gotta be almost a board level executive level discussion. If it’s just you thinking about it, the executives and their subteams are gonna continue their day jobs. There has to be a unified front that says like we need to change what way we’re operating. And there’s usually a reason why. I mean, like honestly, sometimes when you’re in financial struggles, you’re not growing, it’s the best time to transform because people are like, okay, what we’re doing isn’t working anymore. We have to rethink it.
Randy Likas (36:00.889)
Yep. Okay, what’s more important? Strategy or execution?
Pino (36:06.467)
Man, that’s a great question. I don’t think you can get this right execution without strategy. I think you have to have a plan. Know what your plan is. Be really like self-critical about what you’re putting on that plan and why it’s on there and the alignment that took to get it there, because then execution gets a lot easier. I think if you start with execution and not know what the point the punchline is or like the goalpost is, you’re just you’re gonna make wrong decisions. The other reason I think it’s important.
As the work cascades of the organization, you want to trust everybody to make judgment calls. Really hard to make judgment calls and trade-offs if they don’t understand the North Star of what you’re driving towards.
Randy Likas (36:43.362)
Yeah. Hard hardest thing to to change, walking into a tr into a transformation.
Pino (36:49.351)
Hardest thing to change. Ooh, man. From my experience, I think the hardest thing to change is people naturally protect their work. And when you’re doing transformation, you’re usually telling somebody the thing they did forever is no longer viable. And people hold on to that history. And it’s natural, right? It’s just pure psychology of like, hey, but I built it this way and it works for me. And it’s like, that’s great. You have to acknowledge with folks that what got us to this point was all goodness.
But it’s not gonna get us to where we need to go and we have to rethink it. And so I think just getting people to let go of the old ways of doing things is the hardest part. But if you can show them the reason why, it gets a lot easier.
Randy Likas (37:30.798)
Perfect. I love that. Okay, two more questions. One business, one personal. I’ll start with the with the business one. So so if if you you wanna if if we hope to leave anyone listening to this with sort of one one key thing, what’s that one thing that you hope remember?
Pino (37:49.844)
The one thing I I want everybody to remember is at the end of the day, this work, it’s actually people work more than it’s technology work. All of this is anchored on people. It’s anchored on people and processes and the way they do their jobs. And every company, your business your biggest expense are your people. Getting them really motivated. And so going into this as just purely we’re gonna bring in tech and reduce cost, I think
That’s certainly a path. I I think it’s a shorter path in the sense that you’re gonna find it’s really hard to do it that way. I think anchoring on like the people and what are the outcomes they’re meant to drive helps you answer a lot of qua questions a lot faster.
Randy Likas (38:29.346)
Yeah, I love that answer. It’s it’s it’s you can do all the change in the world, but if we we we don’t have our people engaged, aligned, it it it’s gonna fail. All right, now the personal question. When you’re not focused on on on change management and in transformation and AI, what do you do to decompress?
Pino (38:49.115)
I listen to music. You can see I’ve got a vinyl collection behind there. I drive a motorcycle. I like to, you know, drive fast in my spare time. So I drive a motorcycle or or my convertible and I spend time with my family. I have two teenage boys, I have a wife, a dog, and in fact you’re catching me right before I head out for vacation next week. So this is the best possible timing. Cabo. Yeah, never
Randy Likas (38:52.332)
Love it.
Randy Likas (39:09.242)
Y where you going? Nice. Nice. I’ve been there several times. My my wife and I went there for our five year a coup a couple of years ago. Cabo’s just such a great place. Really? Yeah. No, you’ll you’ll you’ll love it. It’s just not nothing not to like. So Well listen, Pino, I think this is a great, great conversation. I appreciate every insight and and wisdom that you shared. Next time I’m in Boston, maybe we’ll go grab a grab a beer or something.
Pino (39:19.911)
Okay. It’s our first time, we can’t wait. Cannot wait. Yeah.
Pino (39:27.59)
Excellent.
Pino (39:37.843)
That’d be awesome. Randy, appreciate having me and hope this was helpful and hope you can see. Don’t worry if you don’t have it figured out. Nobody has it figured out. That’s okay. It’s very okay.
Randy Likas (39:47.712)
If if someone listens to this and wants to, you know, follow up and ask you questions, what’s the best way to to connect?
Pino (39:52.851)
Get me on LinkedIn, happy to connect.
Randy Likas (39:54.882)
Sounds great. Pino, thanks so much for your time. All right, take care.
Pino (39:56.903)
Yeah, thank you. Cheers.

