# In the Spotlight - Building and Operating Your Revenue Machine: transcript

This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage.

Episode: https://yuvalyeret.com/scaling-ai-podcast/in-the-spotlight-building-and-operating-your-revenue-machine/

## The friction around leadership

Great to have you on the podcast. Today on this episode, we have Yuval Yeret, who's the CEO and founder of Yeret Agility. It's a very unique episode, a little bit different than what we've had so far. So this is going to be a great conversation. You've been working for probably over two decades with teams from all disciplines.

You've actually started on the product delivery side of the house, working with teams that are on the platform. are looking to create processes which are self-learning and being able to continuously improve and deliver. And you've moved your practice from the product delivery side of the house through marketing, two sales and the go-to-market teams. And you've carried over a lot of principles that have been working for years in those disciplines. And today you're working with go-to-market teams on that.

So very, very interesting topic to talk about today. Thanks for spending the time today. Always happy to chat through. All right. And I also say we've had the opportunity to work on some of the companies I've been at.

We brought you guys in and it was amazing success. So this is going to be interesting. So why don't we start with talking about the overarching umbrella of what you guys do, which is you constantly talk about operating a team versus building a team. A leader has those two hats that are constantly switching between and specifically in sales. We know it's a heavily operated operation that needs to run flawlessly, but while you do that, you constantly develop the team, develop the skill, develop the tools that develop the tech, and you need to be able to balance the two and know how to make them fit together.

So maybe talk to us about why is this a principle in yerit agility and what is always true regardless whether it's in R&D product marketing or sales. So maybe even going back many, many years in product development, one of the things that I've realized was that in parallel to building the product, you need to build an organization that he's building the product. And personally, I saw that I noticed that I was attracted even more to the notion of developing the organization than developing the software itself. And as I've started helping organizations deal with problems and improve, I noticed that there's a certain pattern of leadership that repeats itself, whether it's an engineering leader, a product leader, a marketing leader, a sales leader or a revenue leader.

They are the sort of proactive leader that doesn't just take care of hiring the right people and to managing the pipeline conversations and managing the campaigns. They also spend the right amount of time and it's, you know, a delicate balance on building the organization, developing the organization figuring out are we working the right way and it's not just about taking the framework of the shelf and slapping it onto the organization, it's about nurturing the garden, stewardship for how your organization works, which I've noticed that when the leader is curious about these things and is trying stuff, it creates a whole different vibe in the organization. So I found myself attracted to helping these sort of leaders build greater organizations.

Interesting. So you're actually bringing the word curiosity, which is a big word in sales. It's one of the big indicators of good salespeople, is the curiosity about their customers, about their pains. And you're using it here saying a good leader keeps the curiosity, but also expands it into, how do I constantly improve the team? What is missing at the bottlenecks?

What are we not seeing? And so when you look at the type of activities that are being done in developing versus operating, is that completely separate activities? Are they doing, you know, Monday I'm operating Tuesday, I'm developing? Or is it as I am operating, I am also developing? And how does that look in the best teams that you worked with?

So let's take an example. Let's take an example from the revenue world. So all of your listeners are probably familiar with something like Meda or Challenger sale. All of these are frameworks, right? Operating it would be running a sales conversation, talking to a prospect, trying to figure out the Meda aspects and capturing it and reflecting after the sales conversation that's running.

There's a second loop of learning which isn't just learning about is this a real prospect. It's, is our process of thinking about our prospects and trying to manage our pipeline. Is that process working for us? Beyond the fact that we're capturing the medic terms in Salesforce or HubSpot or wherever, are salespeople thinking about this? Is it coming up in the right conversations?

Are we using it to actually improve our pipeline predictability or our pipeline health overall? That's the second loop that I'm talking about. Do we have the time to stop and sharpen the axe or do a pit stop to replace the tires while we're racing? How is that different in a sales leader role like a CRO versus a RevOps role that's sort of behind the scenes and constantly driving tool sets, improvements, processes? Where's the difference between those roles and that balance?

So I think it, from what I've seen in many organizations, it is useful to have revops that focus on this and have their full capacity to work on this stuff. But they're all of the Save Leader and their people is to also think about their work on an ongoing basis. I don't expect them to develop a new or adopt a new sales framework necessarily or a marketing approach. But I want them to be part of reflecting on is this working for us. We want the RevOps team to co-create the approach with the actual Salesforce.

That's where it works. When you're inflicting a new change on people, and it's true for salespeople, it's true for marketers, it's true for developers, It's true for everybody, people don't really like being inflicted the change upon. They like to be part of the process. And it's also a better process if they're part of it, because they know what's going on in the trenches more than the RevOps people. The RevOps people might be tool experts or medic experts, but they don't necessarily know the reality that is in the trenches, where the sales people are actually out there having conversations with prospects.

Right, right. And I also think it's part of leadership, right? It's the leadership style that the CRO chooses. A leadership style could be an operated style. I'm just talking to you about your next deal and when it's coming in and what is missing.

## What is really happening in the system

Or as I'm doing this, I'm also pointing out, what are we good at? Where do we need to improve? What are the things that we've learned from the last failure and how do we apply them here, like it's a mindset of a leader to weave in that development activity throughout the operation. And I think that's where the curiosity comes in as a leader. And if the leader does this, this trickles down to every single rep that needs to learn lessons and apply them, and not afraid of change and not afraid of constant improvement.

And the great leaders are like that. I think they're not afraid to point out, hey, remember that last deal we lost. Let's talk about that for a second. Let's not just sweep it out and talk about our wins. Let's talk about that for a second.

Why did we lose it? What happened there? What was missing? We moved too fast. We missed a specific action that came back to bite us in the ass.

How are we doing in this action here? Do we have the right visibility that we didn't have in that last deal? It's essentially being empirical, getting transparency on what is working for us, what's not working for us, inspecting it being open to inspect what's working and not working in the system. It's not about the people. There's a principle that is really important when we're focusing on continuous improvement, which is almost like a first rule.

We trust that people are doing their best in the system that they live in. The role of a leader, whether they're a revenue leader or an engineering leader or a company leader, is to work on the system, to create a system where people can thrive. If people fail, then that's a failure of the system. Even if you hire the wrong salespeople for the role, that's not their failure. That's the failure of the system that brought them in.

the decision to grow the sales force when it actually made sense to continue. We'd found their late sell for a while, even though the VCs are telling you to go spend that money that you raised fast. Let's talk about the success of adopting a change. So you talked before in one of your publications or articles about an average that you see of 30% adoption of change that you put in. That could be 30% of adoption of new tools, of new processes, of new methodologies.

And I'm combining that with the 95% failure to get ROI that we know is very prominent in AI today, but probably not just AI. So there's like a conversion drop. You apply a change, only 30% is actually getting adopted. And out of that, even less gets impact, it creates impact and gets ROI. So what is the reason for that as you look at go-to-market teams today?

So I think it's a space where you and I both worked a lot in the product space, right? We still work in the product space quite a bit. And the statistic in the product space is 70%, 80% of the features that you build don't really get used. A lot of it is because we make assumptions. We make assumptions about the fact that people will want this, the fact that this will be viable, we will be able to make money on it.

And we don't really validate these assumptions. The same challenge applies when you're trying to implement change in an organization, whether that changes a new sales or marketing framework, getting everybody to use generative AI in the organization, whether it's the new edge-all ways of working or to use OKRs or whatever it is. All of these suffer from a couple of problems that we see in the product space as well. If you look at the new startup, before it can deploy, change and hire a scalable Salesforce and just go and sell, they need to validate the use case. They need to get to product market fit, right?

How do we get to product market fit? We need to understand that there is a market with early adopters, we need to see that there's pool, there's demand, if there's no demand, It's pretty hard to get salespeople that know how to harvest demand and get them out. Change inside the organization is similar. You can think of it as a market of people that do want to try new things and people that are willing to try it and with people that will resist and are hoping that the chain will fly over us like a New England storm. We stay inside for a couple of days.

We get water and toilet paper. And after a while we go outside and all of the snow melted and we don't need to shovel it. There are the people that hope we don't need to shovel. And you need to approach these different people in a different approach. Some of them they need a full kit of the change.

Some of them need to see their friends, their colleagues that are succeeding. Some of them just need to see that the incentives are changed, that they're being measured using the new approach. And some of them will just do it on their own. The problem that they see in organizations is a lot of the time, you get the pockets of people that really want to do something. They're really successful because they have the motivation.

And then you try to copy paste that approach to everybody else. And this succeeded in one place, and it was very specific to their context. You say, okay, now it's a playbook. This one team tried Medi in this area of the organization. Now we're gonna do it all over the place, but we're not gonna focus on engaging people.

We're not gonna focus on tuning the approach, where you want to rush it. So we're gonna deploy it all over the place and it fails. So that's why it typically, you know, whether you're deploying a new product the market or a new change or tool inside the organization 30% is actually optimistic a lot of the time. It's not even that. A lot of what you said falls in what we call, because we are part of many transformations of our customers going from sporadic like forecast to medic-based forecasts or from opinion-based forecasts to evidence-based forecasts or non-AI to using AI to run deals and forecasts.

## The practical shift

And the number one thing that we work with our customers is we classify bottom-up activities for adoption and top-down activities for adoption. And so a lot of what you said falls into one of those two buckets. up means, you know, let's make sure we validate what does it do for the individual rep. How is the rep working today? Does that fit the workflow of the rep?

Or are we creating a separate workflow now that is that will create friction? Are we showing the rep the benefits that they're going to get? So creating, you know, intrinsic internal motivation for the rep. And so that's a lot of the bottom up. The other piece of the bottom up is, is it making easier for the rep to actually engage with their managers because we're giving them that type of change.

The top down is we're starting from the managers and the executives and trying to see what's the benefit for them. And then after we show them the benefit, we talked to them about, okay, so how are you changing? How are you engaging with individual reps or with the first like manager, individual reps? How are you driving that change down? And so in a way, you could classify it to let's validate that this change actually brings value to the individual persona.

And then let's tie the dots in the change of actions and the change of behavior based on that benefit. So I'm 100% agree. And I think many times people think that this is a great thing. I'm going to just plug it in and great things will happen. and they ignore that you need to sort of screw it all the way into the organization.

I think there's something else here, which I think you're hinting at. A lot of time we treat change as a project. And we treat it as the old way of doing projects. We say, OK, this is the change. Let's figure everything out.

Let's do all of the specification, figure out all of the fields, the software. And then once everything is locked and loaded, let's just deploy it. The problem with that is the change is very, very complex. Even if you're talking about a tool that is out there for a while, that's stable, its application in your organization is complex. People are complex.

Your reality is complex. You have different moving pieces. You don't necessarily know upfront what's going to happen when you're trying it. So an approach that is more empirical, that is, let's try this change. Let's reflect, let's sense.

Is it working for the individuals? Is it working for the leaders? Are the reports, the dashboards that we're showing in the sales pipeline conversation, are they resonating for people? Do we get eye rolls? Are people losing interest in this?

And let's try it. You know, let's adjust it. Let's respond to what we're seeing. You can even think about it like being agile about what's going on in adjusting it. You can think about it similar to how we treat products.

We don't necessarily build the product, deploy it and it works the first time around. We need to try different things until we get to the product that really works. So there's one of the things that I really like to see is how these principles that we've learned in the product world and in the past in the product world we've made these mistakes as well but over the last couple of decades it's a given that you need to iterate to find product market fit and if you don't need and you made it the first round, wow that's magic. The same applies for change so we need to figure out what is the operating system, what is the approach in which you do set a clear goal of this is the outcome that we want to see.

We want to see better forecast predictability. This is more or less the direction that we're taking but how can we adjust it along the way? No, I'm not saying we need the heavy process for that. I'm not saying we need to copy paste processes that have worked in other domains out of the box but there are certain principles that certainly apply an award thinking about as your thinking about deploying change in your organization. So don't think about it as a project.

This is built an iterative journey into it. That's great. Let's talk about an example. Actually, I'd love to take an example of a scaled organization where skilled organization is a little bit less risk-averse, and they would like to see things sort of, boom, plugged in, and everything from that point on works, because they're not built for these extremely flexible and agile iterations. But let's look at an example of an organization you worked with with and actually were able to shift them over to this mindset?

Yeah, so I think an example that might resonate for revenue leaders these days is the computer associates example, not because we're necessarily talking about people in that company, but because of the context that we were at there. So a lot of SaaS leaders these days, when they're not listening to your podcast, they're thinking about what do I do with this doomsday prediction that were irrelevant in the world of AI. Cloud Cod can do everything that we can do. They need to manage that message. They need to declare on where is our added value.

What are we saying? There's marketing that needs to be developed. There's content and language that the salespeople to have as their approaching sales conversation and there's no time to wait six months to figure it out that you need to start trying different messages and having them out there. Computer associates was in a similar situation when it realized that it needs to be much more aggressive competitively something like seven years ago when they're marketing in sales organization was looking at these ways of working, a specific division within or the marketing and sales group, which is about 50 people out of the 300 in the whole marketing and insights sales organization, decided to try and be more agile, to try and use this approach because they were in a situation where they were merging a couple of different products into this new line of business.

## What leaders should pay attention to

It was a big that they were bringing in. They had to figure out some stuff, how does our portfolio management product interrelate with our agile lifecycle management product, what's the marketing that we're gonna use to win over and protect some of our clients, and they had pipeline health issues. So what they've done is they've said, okay, in parallel to the inside salespeople, making the calls, the leaders of inside sales, and the leaders of those marketing teams. Together with the marketers, the field marketers that actually go to conferences and represent the product, they were also sitting on these teams developing different approaches. They started working in these different teams.

Each team worked in a couple of weeks sprints where they decided this is our goal. Right now our goal is to figure out a new approach for our strategic conference. right now our goal is to figure out some ideas for how to fix the pipeline. One of the things that we've heard from their Insight Sales leaders is this is amazing. Finally, I get to sit in the room and work and be hands on with the people that I really need in order to move the needle on my campaigns to get the copy that I need, the messaging that I need.

Insight Sales together with FieldMarketer, ProductMarketer, IntegratedMarketer, which is their name for digital marketers. And for the CMO looking at this, one of the things that she said to me was, this is exactly the vision, or this is a line with my vision for how I want to see my organization. I don't want every tweet or everything to come to me. I don't want to be the only one that is thinking systemically. She had an issue where even her VP of field marketing or VP of integrated marketing still looked at silos, but what we've started to see with these teams is we've broken the silos.

She created or she started to see her vision of mini CMOs all throughout her organization coming to life and fewer and fewer things requiring the attention of the senior leadership team. One more things were being closed at the level of one team, one multi-disciplinary team that was able to run much faster. And there was a great example of this wasn't the only division that needed to be more competitive. This is a CEO magnet. They were able to have a competitive campaign, a successful competitive campaign up in the air in six weeks or so, while their colleagues from other lines of business were still designing the campaign.

I think even though this example is is coming from marketing, I think the principles are important, which is be able to create teams that can really be self-sustaining from a mindset perspective. Not everything needs to go all the way up for decisions. Again, balance that with a scaled operation, because if you look at an enterprise sales team, obviously some decisions need to be centralized. but if the second line manager has a CRO mindset and they look at their territory as their market, that they need to go strategize, build what they need, and then constantly work with the others to share knowledge and best practices. Like that's a model that I've seen work as well in sales.

So I have another comment about this, which I think is important. I'm not necessarily saying that this approach is the approach that sales teams need to use day in and day out for managing their sales work. We started with this is the work of building and evolving your organization, your machine. One of the things that I've seen is that when you need to work on the system on the machine, you need multidisciplinary teams even more than the day to day. This is why it made sense to bring the marketing and inside sales people on the same teams.

And I think that's true in most cases. I mean in Gillette, in order to really launch a successful exfoliating razor, we needed to bring the commercial people and the R&D people to work on the same teams. changes in the system require the different individuals from the different disciplines. That doesn't mean that they need to work with each other day in and day out, but they need each other in order to make these changes. Yeah, because I think when you're operating, only operating, you're getting very specific to your day-to-day tasks and you don't care about impacting the entire value chain.

When you're building, you want to impact the entire value chain. And so bringing those people together makes a huge difference. So I think some important principles that we touched on that I do want to recap before we conclude. So, first of all, having a mindset of building and operating at the same time is something not trivial. When you build, make sure you don't just have the people who operate, help you build, make sure that when you build, you bring in external knowledge.

It could be your internal customers for the change. It could be people that influence that change from another discipline, but make sure that you bring them in because that's how you look at the entire value chain. And then make sure that once that change has been done, it's not a project. It's an iterative adoption journey. It's a journey, right?

It's not a project, it's a journey and it's iterative. And so be ready to build into your plan the imperfect launch and stay curious on what's not working and constantly evolve it. So amazing, really, really interesting, Yuval. I think what you're doing in many disciplines is transferable and relevant for some of the best sales leaders that I know are doing exactly that intuitively. So really interesting.

Thanks for taking the time. Always a pleasure.