E63: A Product-Informed Approach for Go-To-Market (Usha Iyer: Chief Customer & Growth Officer @ Hivebright)

Usha Ahir is the Chief Customer and Growth Officer at Hivebright, but she has a resume that you rarely see in a revenue leader. She started as a C++ developer, became a product leader at Honeywell running a $350 million portfolio, and now runs the entire US market and global revenue for Hivebright.

Winning has a very different meaning in product versus go-to-market side. Either you win or you get out of the way.

Because of her background, Usha treats the sales process like a product, something that must be architected, not just managed. In this episode, we discuss why most revenue leaders fail at experimentation because they ignore the data layer.

You need to be able to bring your business model into a data structure, take your entire customer journey and mirror it into the way you represent your data.

We also cover the specific mistakes leaders make when trying to roll out new initiatives with their ops teams.

You don't want to take that template now and give it to your ops team and say, you know what, go and build it into my system. That's not how you go and apply change.

But she doesn't only share how she improves performance in GTM teams. She also gives insight into how to get your product team to focus on where you need the most.

Don't come with, come with the problem. If you're able to articulate that clearly, your product leader will listen to you.

Welcome to the Revenue Leadership Podcast. Momentum is a powerful tool for turning sales and customer conversations into go-to-market intelligence. Using GenAI, it extracts, analyzes, and automates customer intelligence across your GTM org. The best part, it's not a new platform for your team to adopt. It integrates seamlessly with your existing stack, or it can straight up replace your conversational intelligence tool. At Owner, we ripped out Gong and went all in on Momentum. It writes back to our Salesforce directly, captures forecast and churn risk, autofills CRM fields, shares product signals, and tracks sentiment. Companies like Cursor, Zscaler, Ramp, and ElevenLabs use it every day. Check it out with a free trial at momentum.io. Today's guest is Usha Iyer, who is the Chief Customer and Growth Officer at HiveBrite. And Usha has a very rare career path. She started as a C++ developer, eventually became a product leader at Honeywell running a $350 million portfolio, and now runs go-to-market, CS, revenue strategy, and the US market for HiveBrite. And she has taken this product mindset and stretched it across the entire customer journey. And so today we are going to talk about what sales leaders can steal from this product playbook. Book, how to run real experiments, how to do discovery like a product team, and how to connect what you're doing every day to outcomes that actually matter. It's a topic I am really excited about because I think one of my most formative experiences as a revenue leader was learning how Shopify built product and just being in a, in a world-class product environment. So you're a rare person who can speak about both worlds. And so I'm really excited for this one.

Thank you, Kyle, and thank you for having me. This is great.

What did I miss in your background? Maybe just explain a little bit what Highbright is and some of the career journey, and we'll dive in.

Highbright is a company that makes a private community platform, and we empower a lot of communities across different verticals. It could be in the commercial space, in the nonprofit space, in the education space, the association space, the communities that— when you think about communities, private communities, they're everywhere. And so we have a software platform that enables it. It cuts across very small communities to very large multi-enterprise, multi-network communities. So, as you can imagine, very horizontal product, multi-use case, multi-sector. So bringing a product-oriented mindset to taking a product like that to market really helps because you have to apply, almost apply first principles every single time you're in a situation when you're trying to position your product to the target buyer.

And so how did you go from product to GTM? Like when did that happen and why?

I think it all comes from the same common thread that I always enjoy working with customers, no matter what role I've been in. So even when I was an engineer and I built algorithms for demand planning, I used to work with large companies like Nabisco who at that point in time excelled in demand forecasting, statistical forecasting. Started writing code, working closely with customers, moved into various product management roles where I continued to do the same. Through my product management career, I also then slowly switched into solutions engineering, pre-sales, product marketing, things kind of adjacent to product, which kind of helped me understand the commercialization aspects of product. And from there, moved into product strategy roles. Also took one company from the old school perpetual pricing model to a SaaS model, which helped me understand how do you reposition a product, not just from a messaging standpoint, but how do you even take a product and shrink wrap it into an out-of-the-box product? So, just through that journey, I ended up at Hybrid. Even here as a product leader initially, when they were a tiny little company, sub $2 million in ARR, mostly targeting the SMB market. And as I came in here, it was obvious that frankly, it was a bloodbath in the low end of the market. Community solutions, you know, were very, very cheap, small point solutions were everywhere. And luckily we ended up in a situation where we got into a sales cycle. It was like one of the big schools in the US, Notre Dame University spotted us like a diamond in the rough and said, there's something with this company. They've got a platform that could potentially power our entire alumni association of over 750 alums. And that's when I realized the world of communities can be pretty big in the enterprise world. And so, took the product upmarket. Long story short, over the next 2 years, we built the product to be always vertical agnostic. So we were able to go capture bigger organizations in other verticals as well. We focused a lot during that time on the non-functional aspects of building product, like security, compliance, and all of that. But I was still doing that in my product role. So it was very natural after 2 years, When the board asked me and our CEO to go take over go-to-market, it felt natural because we'd built a product and there was a big unlock opportunity in the market. And so, it was a natural journey for me to go from there to sales first. And then, just last year, the first time in my career ever, I ended up coming full circle and taking over customer success, which honestly has been a very humbling experience because it's one thing to position your product, price your product, sell your product, but then it's another thing to deliver value through your product and be responsible for doing that.

Incrementally stepping closer to revenue.

Exactly.

SE, PMM, strategy, then finally sales and CS.

Yeah, and then I became a very big fan of the bowtie, honestly, because it just is so obvious that it's one thing to drive excellence on acquisition, but unless you're able to really drive adoption and then expansion, using that very same product, right, that got you in the door in the first place, you really don't deliver value. So it's been quite good to have this other side of the bowtie also under me in the last few months.

What were some of the biggest learnings as you came from product into go-to-market? Like what were some of the things that were like least obvious and you needed to figure out? As a new revenue leader?

Winning has a very different meaning in product versus being on the go-to-market side. It's pretty black and white on the GTM side, particularly when you are a sales rep or you're an account manager. You get judged pretty clearly in terms of whether you're a winner or a loser. When you're on the product side, you actually make a big impact. You can potentially make a much bigger impact, but it's often hard to measure results, and you piggyback on the results of the rest of the organization a lot more than on your own individual contribution.

What's one thing that you would take, that you take back to your role as a product leader that you've learned in GTM?

While I always worked very closely with customers, I don't think I had as much empathy for customer problems. Being on the GTM side helps me to put myself in their shoes a lot more, live the day-to-day. And I'll say the thing that product does not see, product sees value pretty clearly because when a product gets used, especially these days, you can measure every single signal. You can get a pretty good sense of adoption of features. You get lots of feedback from your customers. What you don't see is friction. You don't see when friction exists in the use of a product until it's too late. And if you don't tackle that in time, you can't ever recover that customer back. You can't recover their time back. And it's a loss both for you as well as for the customer. So I would say as product leaders, don't just look at the data, don't look at the metrics, don't just— I mean, look at it, but in addition to that, try to really uncover the underlying friction that exists that is not that obvious.

That makes a ton of sense. Yeah. And unless you have a very close proximity to customers and you're talking to them constantly, it's really difficult to know their frustrations.

Yeah. And it's like friction is like tax, right? You have to decide how much tax you want to pay for the money you make. And at some point in time, it's not worth it. So that's the point you got to detect. Is the friction worth it that the customer's getting so much value despite the friction that the customer understands and stays with you? Or is the friction so much versus the value, you're paying so much tax that, you know, it's when they give up.

Yeah. And sometimes product leaders will frame those friction points sort of dismissively. Oh, that's a quality of life improvement. Oh, like, yeah, we'll add that to the roadmap. But it's like, oh, that's a quality of life improvement. It's not a like value creator. But unless you are in front of a customer and you hear them being like, dude, you just have to fix this thing every time I touch it, then I have to do this and this and this. And unless you hear that directly from a customer and see it in their eyes, you understand it's like, oh, that's not, it's not just like a quality of life improvement. That is a, like an existential need. That is driving them nuts.

Yeah, true. And sometimes that friction actually unlocks an opportunity to extend your product beyond what it can do today, right? So I'll give you a simple example. HiveBride is an online community management platform and we enable organizations to plan their events. Events is a big, big part of community engagement. And so people can set up events in HiveBride, issue tickets through HiveBride, collect payments through HiveBride. Post-event materials in hybrid, all of that can be done in hybrid. We never were that event experience platform, which means we don't run the event on our platform ourselves. Like you use Riverside, for example. We don't do that part of the event. However, what we didn't realize is that there can be huge friction in an event check-in experience when it's an in-person event, okay? How do people come back and say, these people have actually checked in, they are attending the event in real time? And people would then have to use our APIs, go and upload all the attendee lists after the event and do all of that work and sometimes even hire temps to go do that work for them. By detecting that piece of friction, we were able to build a small little QR code interface and an event attendee check-in feature, which allowed us to now extend our product to that in-event experiential aspect as well, and not just be the event planning tool or the event management tool. So, I think understanding friction can actually inform your roadmap and help you unlock growth opportunities as well.

What's the one piece of advice you would give to revenue leaders who wish their product leaders would listen to them more?

Don't come with the solution, come with the problem that you're looking to solve. What is the pain point? What is the problem? What is the impact of not solving that problem? And what is the opportunity cost of not solving that problem? If you're able to articulate that clearly, your product leader will listen to you because now you're not coming to them with preconceived notions on how to solve the problem because more often than not, you don't have the best solution for it. You're not the solutioning person. So don't be the solutioning person, be the problem person. Come with ideas, but don't try to solution it all the way.

It's like a product leader coming and telling you how to pitch a deal.

Exactly.

You know, it's just not gonna be that well received.

Yeah, it's not gonna be received. It's also how you price a deal, even worse, right? Like how do you put the offer together?

Yeah, yeah, yeah, yeah. So you've said that you bring this product mindset to the customer journey, but what does that actually mean in practice? How do you juxtapose this with sort of a traditional revenue sales leadership approach versus like the product mindset approach? And maybe just for the revenue leaders listening, like what is a product mindset? Like how does a product leader think?

I think the first thing is you think from first principles. Like when something comes to you as a problem, you don't try to apply patterns right away or frameworks all the time. Try to understand what is the underlying problem as if you're a complete layman. You may not even know anything about that field. It's okay. Just try to understand what it is. Listen carefully. That's number one. Number two, you know, try to do more deeper discovery. Go deep. Try to— the superficial questions of tell me what you want to achieve, Oh, you wanna run an event. Okay. But what kind of event? How long does the event run? How many attendees are gonna be at the event, typical event? What's the typical structure of the agenda of the event? I mean, I'm taking a very simple example.

Yeah, yeah, yeah.

But I'm just saying, don't leave it at a superficial level. Try and ask deeper questions to really understand where is the most value getting created and solving for that problem. Okay, and then actually be an expert in your own product. Okay, the one thing I see missing a lot of times in GTM folks is confidence in knowing what your product can and cannot do. Oftentimes your buyers want to hear it straight from you. When you can't do something, just tell them you can't do it. And you would give them ideas on how they could solve for it, but don't try to do all things and try to yes your way through a deal because More often than not, that doesn't work. So some of these tips I keep reminding our teams that it's okay to say no, just challenge the status quo, you know, and try to go deep. When you don't understand something, tell them you don't understand it. If you need to bring a product person to the call, they'd be more than happy to join the call. So don't try to cover it all on your own. Bring your SMEs into calls. So these are all I guess simple things, but those are the things that I like, I think work really well.

Thinking from first principles, deeper discovery, being an expert in your own product. The other thing I think is really helpful that, that product thinkers bring is a much more humble intellectual mindset. Like I, I find product leaders think in hypotheses and revenue leaders tend to think in like, this is the decision, this is what we're doing, and like it has to be successful. And oftentimes run at an unsuccessful decision for far too long before giving up on it versus saying, hey, like this is the experimentation mentality we'll talk about, but they get committed to a decision as opposed to a decision being like a path which may branch and can be unwound and changed at any point when, you know, the real world.

So right about it. I think our own, within our own company, our Chief Product and Tech Officer, Tariq, who's based in Paris actually, he and I have this constant discussion, right? He says, we always have to find this equilibrium because product is input-driven and GTM is output-driven. Okay, so we start from a place of outputs, whereas product starts from a place of inputs. And we got to find the middle path where product appreciates the outputs that you're looking to get out of it while you go into the process. And GTM needs to be able to appreciate that you may not always land at the same place in terms of outputs. You may end up in a different place based on the route you take to get there, but ultimately you can solve the problem in multiple ways. So you're exactly right. A hypothesis-driven mindset where you come in with a point of view, Trust your inputs, trust your process, and work through it very diligently one step at a time, and then validate your hypothesis and go forward. Or if your hypothesis fails, move backward and start again. That's the mindset that product leaders bring all the time, just iterating, whereas you don't find that too often in the GTM sort of mindset.

Can you just unpack— this is a really interesting stance, like product is input-driven and GTM is output-driven. Can you just explain that in a little more detail and what the implications are?

So in our company, for example, we use a process called the focus process to run discovery, which means you start out with a large problem that you want to solve for, and you don't try to take the problem and narrow it down too soon. It might be, hey, we want to solve for the problem of increasing user engagement on our platform. That's a very broad problem statement. And in a way, that is the outcome you wanna achieve, but you don't know exactly how, what are you gonna do in order to drive engagement? So you start with a series of interviews with your customers. You try to understand what's going on in the market. You study your competition and you try to understand how could you navigate or establish that problem statement and come up with a few hypotheses of how you can solve for it. AI could potentially increase engagement by leveraging AI more to drive peer-to-peer interactions. Okay, let me go down deep down that road and understand what kinds of problems stop people from interacting with each other today. How could I solve for that with technology? And does that give me a meaningful enough result to increase engagement overall? Great, then you formulate that, you build a quick proof of concept, you run a test with a small focus group of customers, you gather your results, you validate your hypothesis, and then you push it through into your delivery cycle. So that process starts out with a high-level hypothesis, with a set of inputs, with a process that you've committed to following, and then you come out of it on the other end with a feature that now you incorporate into your platform. You didn't know what that feature would look like in the beginning, but then along that journey, you were able to develop and shape it to what it needs to be.

And so that's input-driven.

That's input-driven because you're putting a lot of thought into how you're developing that feature with the right inputs. It could be data, it could be interviews, it could be—

Without knowing what the output is.

Output is gonna be. Yeah.

Okay, okay, interesting.

There's a difference between output and outcome, right? You still get to the same outcome, but you may get to it with different outputs.

So explain the difference between outputs and outcomes. We wanna talk about this later, but let's—

Yeah, yeah, exactly. The outcome I wanted to achieve in this case was increasing engagement. The output is a specific feature in the product that helps you increase engagement.

How do you apply this to go-to-market? Where is this helpful for revenue leaders and how can they bring part of this into their own approach?

I would apply that more in the early stages. Let's say, take a sales cycle. In the very early stages of a sales cycle, you just had— we are an inbound business, for example. So, when somebody comes and knocks at our door, we are trying to learn what they're looking to achieve. And so, a similar thought process applies really well in the early stages of the discovery process with your prospect. We use the SPICE framework internally. We used to use BANT and METPIQ and all of that, but it felt like it was too formulaic, you know, to, and it was putting people into a certain mindset of always asking your budget questions in your first call. And it's not necessary in my mind, you will get to it anyway, very quickly. You're better off finding out what is the pain point that the buyer has. What's the problem they're looking to solve? What's the impact it can create? And then work into more of the commercial sales process from there. So using that same discovery mindset, hypothesis mindset, formulating a solution for the customer, that same process you use in product works pretty well in the early stages of the sales process.

And how would revenue leaders apply this like broadly to the organization? So they're trying to solve problems. What would you bring from that product mindset to a revenue leader that has a conversion rate problem? It's like, you know, we're losing deals at negotiation or we're seeing churn from a certain competitive vendor. How do you help them apply this inputs versus outputs like model?

Again, I mean, let's say take that churn problem as an example. You want to increase your GRR. So you feel like there's an opportunity to do it. You don't, you have 10,000 customers who are using your product in every which way possible. You're seeing your churn metrics trending down. Now you gotta take that problem, break it down, and figure out how you're gonna solve for it. So start with the inputs. What data do you have in order to analyze that problem? I would say these days with the abundance of tech tools, conversational intelligence, usage data coming from your product, NPS scores, G2 reviews, support tickets. I mean, the amount of data that you have on any given customer is enormous. All your subscription data, your renewals patterns, your upsells, your downsells, your discounts, everything that you've done with that customer is available to you. Now, that all becomes your body of inputs that go in. With AI now, it's so easy to take all of those inputs and actually sort through it and organize that into patterns that can help you to figure out what pockets of your customer base is churn most obvious in. And even that is a process. You have to get there because you have to segment your data. You could be segmenting it using different ways. You might have to do it a few times before you get to a right segmentation that works. But once you do that, then your pattern, you establish patterns and you can understand which pockets of your customers are exhibiting the most churn or most retention rates. From there on, then you can go and understand what are the underlying characteristics of those customers. And it goes back to some of the basics, you know, what type of use case gives you the best success? What type of, organization, what type of maturity within that organization helps you retain that customer? Because sometimes your product adoption depends so much on your customer's ability to actually take your product and roll it out. So is there certain characteristics of your buyer's organization that lends itself well to your product? Is there something that certain types of results that ensure that your product starts to get used more and more? Are integrations helping you to actually drive stickiness of your product? So there's so many such things that emerge pretty quickly with those patterns that you can now take those patterns and say, I'm gonna try and use that and replicate it. It could be through micro, you might go and run another experiment and say, I see that I'm getting a lot of luck with this use case and this industry with this type of buyer. Let me put together a quick campaign Go and target that customer pool or that prospect pool and see if you're getting, you know, better luck trying to sign up customers in that segment and retain those customers. This is again a process. It doesn't happen overnight. You have to set up initiatives and then work through it from point A to point B and understand where are you getting the most success and then go back and roll it out more broadly in the organization. So I think Revenue leaders have to kind of get out of the day-to-day grind they typically get themselves into, which is, you know, let's collect all the numbers, let's do the bottom-up forecasting, let's look at which people are performing, which people are not performing, and then use that more as an indicator of where to double down. Instead of doing that, you know, take that revenue hat off for a minute, go look at the problem you're solving in the market, understand it from your customer standpoint, and then go back into your revenue function and apply those learnings. That'll help, you know, revenue leaders tackle problems in a way that product people do it.

And I think a lot of people listening to this are gonna hear some of it and feel overwhelmed. They're like, you just mentioned so many types of data and how the heck do I wade through it all? And, and I think one of the useful framings is, okay, you've got all of this data that you wanna make sense of. Start with your hypotheses. Start with like, Okay. And you can crowdsource it all. Like what could be driving it? Could be use case, could be company size, it could be our champion. Like you could, if you go poll a bunch of people who are close to the customer, some product leaders, some CSM, some sales reps, and start to get an idea like, hey, what does a great customer look like to you? Like when you get a customer, what, what gets you most excited? And like when you get a customer and you're like, oh, this is going to be a tough one. Like what are you, what are those little spidey sense things? And then you're just taking these random hypotheses and starting to think like, all right, how would I get data to tell me that thing? Okay. It's all about like how engaged is the champion.

All right.

Well, what's the evidence that I have an engaged or not engaged champion? Well, it could be the number of emails back and forth. It's the length. It's the, you know, number of minutes you've spent on calls with them over the first 60 days. And you'll obviously need a, data science partner or an analytics partner to do this. But I think the mistake that revenue leaders make that I see product leaders doing such a good job at is like, churn is down. So, okay, churn is down. I need to like run some incentives or I'm going to run some training. And you just like, it's the leaping to conclusion. Like you said before, leaping to solution that gets people wrong versus saying, and this is, I really like Teresa Torres, who's like a product Author.

I love her too. Yeah.

Yeah. Opportunity solution tree. It's like, get all of the options out on paper first and then go up the funnel and be like, okay, is this a symptom or a cause? If it's a symptom, then what's the cause? And then you can start to be like, all right, here are all the things, here are all the potential patterns or contributors. Then the data team can run those things down. Then it can all, then you can bring it all back and say, We had these 7 hypotheses. These ones have no correlation to churn. Like, you know, we thought it was the size of company. The data shows size of company is like uncorrelated to retention. And then you can just, you can methodically work through this process. And I, I think this is one of the most valuable product mindsets.

It's just like, you know, the beauty of also being a scale-up is that you're working with enough customers to be able to establish what I call as a control set. If you can set up a control set, meaning let's say you pick your customers that are wildly successful with you, and then you go look at those customers and say, are there examples of customers who look just like those customers but did not succeed? Okay, then it becomes actually really easy to figure out what you need to double down on to improve churn.

That's a great model.

Because it's so easy to know your successful customers. You're talking about them all the time. They are giving you the best reviews. You can see adoption signals that are great. They may be squeaky wheels, but that's great, right? Because you want to hear from customers. You'd rather hear from customers than have them be silent and passive and detractors in the background. So, when you get all of that data and you know who's your best customer, it's so easy to then say, if that's my best customer and if there's another customer who looks exactly like that customer and I've replicated everything in terms of my customer experience and I still don't find that that other customer is having success, it's really then easy to find what is the one or two things you need to improve.

Yeah, that's such a great point. I think, and so much of it goes back to your earlier point about first principles thinking or like root causing. And it's the same, like we are so, we are so built for action as sales leaders. Oftentimes we like, yeah, output driven. So we like skip those steps. Hey, don't bring your chief product officer a bunch of solutions. Bring them problems and just like slow down.

Yeah.

How, how, um, when I go back to, to like root causing, so anything else that is worth sharing on how revenue leaders should get better at like finding root cause for problems or any examples that you have seen commonly where people try to solve a symptom and not, not the root cause?

Discounting, right? That's another example of an area where I see revenue leaders are too quick to conclude either the price that we've set for our product in the market is too high, or the packaging is not right, or maybe we, you know, need to add more product. Meaning builds more product. There are gaps in the market, so our competitiveness is not high. So I think, or our collateral is not strong. I've seen that type of a bit of a defeatist mentality. Not all the time. I think by definition, one of the great things about people in revenue roles is they're very optimistic, right? And I love it because the energy is so high. I love it. Like the high of winning a deal, all of that is fantastic. But I also see sometimes they feel very deflated and disempowered because they feel someone is setting the rules and they can't win by those rules. And that is something that I always try to pull them, like being, coming from a product mindset, my feeling is we are in the best position actually to know our customer and go back and shape a lot of that, you know, to play a winning game. But at the same time, if we are discounting a lot, it could not be because, you know, we are facing fierce competition. It could just be that we are not positioning our product well. So let's go back and see if there's some rep coaching that we need to do, or we need to support them in certain cases with solutions engineers who can go deeper in discovery and helps hence help them to create the value in those discussions that will help us to position our offer well. So, those are some of the things I would advise revenue leaders to not fall into the trap of, like thinking that they're not set up to win or to maximize the value of a deal.

And how would you, what advice would you give to revenue leaders to be better at getting to root cause? So with like, in, in, in a more macro sense, like instead of jumping to conclusions and jumping to solutions, like how do you, what, what process or mental model should they apply to be better at getting to root cause of, of some of these problems, whether it be conversion rate or churn or, you know, discounting pressure?

I think there's a basic thing, which is to become really data-driven. Rather than, I see many times revenue leaders have a ton of experience managing teams, but they don't default to using data to driving those types of macro initiatives. If, for example, if there's a change in, I don't know, if there's a change in the forecast week over week, The first thing I would do is to go and dig into what's causing the change. And then I would have a systematic process to understand whether it's coming from a lot of little changes or it's coming from some big changes that I need to go look at more closely. It's just the diagnostic mindset that you need to bring to the job day in and day out using data, which I see sometimes, you know, can we can learn from our product and engineering counterparts.

We have now identified problems, found potential solutions, and, but one of the things that we see, you know, product is built around, but go-to-market oftentimes fails to apply, especially in sort of like non-SMB scenarios, is being thoughtful about experiments. How can sales lead— where should sales leaders start to adopt a more hypothesis-driven, experiment-driven mentality? So like, I've got my ideas, I want to deploy them now. How would product think about pushing these things into a market and learning? And how should sales leaders think about applying that to their world?

I mean, experimentation is nothing but setting up a certain, again, coming up with a hypothesis. And then coming up with the apparatus that you're gonna use for your experiment, and then running the experiment, understanding the results, and then deciding how you're gonna take those results and convert it into, you know, an ongoing procedure or an ongoing artifact that you're gonna use in the future, right? So the same thing applies for any problem that we are trying to solve on the revenue side. Let's say we are trying to solve for, like taking the previous example of churn, you know, churn is high, we need to solve for it. We had a hypothesis, we went and dove deep, we did a diagnostic, we took our data, we came out with learnings, and we said, okay, I think we can improve churn better by, let's say, rolling out an assessment phase. Let's say we do an audit of a customer using an assessment template. You don't wanna take that template now and give it to your ops team and say, you know what, go and build it into my systems. Now every rep is gonna start using this. That's not how you go and apply change. That's not how you transform. You run with an assessment template with a small set of reps, with a small set of customers, and you then take the outputs and the results of that assessment and see if that's helping you to actually convert that customer into a better conversion rate. And if you feel like that's helping, then you go back to your RevOps team and say, hey, I want you to build the structures and the processes and the workflows that allow me to deploy this at scale. That's how I think about experimentation, which is take a hypothesis, run it, pilot it, set up a SWAT team if you need to, pull out your best sellers or your best account managers, let them go run with that experiment, let them come back with the results. You know, do it manually. If you have to run things in spreadsheets, it's okay. And then learn from that and then go and operationalize it at scale.

But oftentimes this isn't done well in revenue because we don't have the foundations built, like the data foundations. So how do you think about setting that up? Like what, what do, what do revenue leaders need to do before they like make that change?

You need to be able to bring your business model into a data structure. You need to know the fields that most accurately capture your customer into a database and help you manage all the information that you need on that customer over the lifecycle of that customer. And once you have that data structure well-defined, the schema, of that customer in your systems, then you can track that customer's journey through your systems.

Oftentimes I tell people it's like, what is the digital footprint of the thing that you want? And then how do you capture that digital footprint to be able to like, to, to report on it essentially?

Take your entire customer journey and mirror it, not just into the way you align your people, but also in the way you align your systems, the way you represent your data. So stratify it into the layers within your organization so you can then build the infrastructure to run this thing repeatedly, day after day.

Can you make that concrete by giving an example?

Like I said, we are an inbound business. So someone comes in, registers for a demo on our website. What are the fields that you wanna capture in that demo form that allows you to understand that prospect before it even gets in the hands of a rep? Where does that information live? How do you leverage that information to then research, you know, on that prospect before you go in front of that prospect to have a first call? Where do you then store that research? How do you validate that research? How do you represent that in your system so that if that person cancels on you today and shows up 3 months later, you're able to leverage that same information and go back and have a meaningful conversation with them. So, and then how does that information carry through from not just the first conversation you had with the prospect, but throughout the sales cycle, post-sales into the implementation team, and then into your customer success cycle? That's a business process where it's an inbound process. Someone is coming and asking you for a demonstration, You have a person who is in the frontline handling that request, but then you also have the systems in the background that are managing all of that interaction and that information to help you to carry that through end to end.

I think the instrumentation is such a big part of it that oftentimes reps grumble at, but if you want to be a hypothesis-driven, experimentation-driven revenue org, you just have to mandate that you can, that you capture the data across the customer journey. And that means reps operating in a certain way. You have to have, we use Momentum as our call recorder and sort of like CRM, AI CRM updater. Like you have to use it on every call. You have to send your emails from Salesloft and not just randomly from your inbox. And then you have to, like really mandate it and drive that home with your team. And then you have to, I think, like be smart about taking as much friction away from doing this as possible because you don't really want your reps spending a bunch of time like entering data. That's not super useful.

Yeah, I was gonna say you are not making them do any work. You're just asking them to turn their recorder on. After the call is done, that information is captured, is put in the fields. They just have to validate that the information is right. I mean, so much of the work is taken away from them, but not turning that recorder on, actually, I think they need to understand doesn't serve them well also because they're not gonna get their call transcript. They're not gonna get the follow-up email generated for them. They're gonna have to do a manual transition to the implementation specialist. Like they're just adding more work on their own plates, right? There's so much in it for them to follow the process these days with the tools that are available that it's really a no-brainer because it also helps them to do better in their jobs.

A clean CRM is a love letter to your future self.

Yeah, that's true.

You know, if you just keep your opportunity notes up to date, the next time you talk to this customer, it's like, oh, they wanted to solve this, but they couldn't move forward because of that. Like, I can go fix that problem and like, I can win those deals.

Even it comes handy sometimes post-sales because customers, I mean, as much as customers come in, everybody goes into these calls with the right intentions. Sometimes every customers hear what they wanna hear, right? And then when you go into an implementation cycle and they feel like, you know, they're getting something different from what they had signed up for, it's so convenient to have this information at your fingertips to go back and say, look, This is not what was explained to you. Or it could be that your rep genuinely made a mistake, in which case you go back and fix it. But it creates so much transparency and trust with the buyer when you have this information that it takes away that, you know, it takes away that friction that creeps in throughout that customer journey.

Any other experimentation frameworks that are worth solving? So we talked about being hypothesis-driven. Having instrumentation.

The place you would want to definitely experiment is pricing, packaging and pricing. Big topic. We could have a whole dedicated session on it, but I mean, there's so much going on in our space today with especially incumbent platforms getting, you know, AI-fied, if I could use the word, that how do you evolve your pricing and packaging into into that new world where your product is a combination of being a platform, very feature-rich, and you had some level of usage-based pricing before moving into more of the consumption-based pricing world, experimenting with credits. There's so much going on that it's not something that you want to take lightly. You should experiment with what pricing models are sticking in the market and Run it through, you know, I would say special bundles or special offers or special discounts that help you figure out what makes the most sense and then go and revamp your pricing and packaging as needed. I think there's a lot of uncertainty right now with how, where pricing is gonna land in the new world. We are seeing some of the big platforms like Salesforce changing pricing like multiple times a year. For example. And there's good reason why, right? I understand it from a vendor standpoint. We are putting in a lot of investment as SaaS companies into our products to make them much more relevant in today's world while point solutions are mushrooming all over the place. So you still have your competitiveness, you still have your moat, but you're also adding features to establish parity with the newcomers in the space. So when you do that, the newcomers obviously are giving away their product practically most of the time. So how do you then go head-to-head with them and not lose out on value, right? That's something that is a big problem that many SaaS companies are tackling. And so experimentation is the best way not to get sucked into one pricing model or another before you know what really makes sense.

This will be part 2 of the podcast. I would love to go down the pricing and packaging route. We're going through this as a business right now, and I've learned a lot and we feel good about where we landed, but now the experimentation is in flight. Yeah.

And there's also, I would love to talk to you also about, I think at one point you mentioned you guys were experimenting with onboarding. Like one of the things you were trying to do was to really cut short the amount of time that onboarding takes in your business, right? And shrink rapid as much as possible and automated. I would love to know where you guys landed there and then how did that translate into how you're packaging and pricing your product?

GTM and product are so much closer tied than in enterprise because the line is murky and many of these businesses have both a self-serve and a sales-led journey. Customers can cross over. And so for onboarding, you know, if we want to materially improve onboarding effectiveness and efficiency, well, that's really the job of product. Like we're going to do a bunch, we can train, you know, make, make, build automations in Salesforce and what have you. But really like we need the customer to do more of the journey in a self-led perspective. And so what the, the vision we're building towards is not PLG versus SLG or human-led versus fully self-serve. It's what is the intelligent overlap of those two things so that customers can be in a human-led journey, but have the product do a whole bunch of stuff with them, or they can be in a product-led journey and still get help from a person if they get stuck or they need help. Our customer base is interesting because it is a range of technology literacy. Like you have people running their business on literally like pen and paper and they don't know, they don't know how to get onto a Google Meet. And then you have people who, you know, oh, I used to be a software engineer, but my parents are from somewhere far away and I love their food. And so like I'm opening a restaurant and like cooking that food for my community. And obviously they don't need much handholding to get up and running. And so building our service model and our product model to serve this like, you know, very broad customer base is interesting, but we're learning a lot and definitely like shipping some cool product that makes this easier. But the user is both the customer and it's our internal team. It's our launch specialists. They are the user. And how do we make How do you build tools to help them do their job better when the customer can't do it on their own? How do you build tools to make the BPO more effective and better? We've shipped a lot and we're about to get into like hyperspeed there because we've piled a bunch of resources into that side of the business, which is, which is really exciting. Yeah.

And I think that how you really, what you learn during onboarding and how much of it you bring back to your product also informs packaging, and pricing. It needs to really be enabled through the product. I completely believe in that philosophy too. You keep your customer as much as possible in your product throughout the process of implementation and onboarding, even if it's an enterprise customer, not just an SMB customer, because the more they're living in your product, the more they're getting used to your product. And if that means you need to add things within your product to be able to give them a structured way of doing things that enables them with onboarding, so be it. Build those things within the product so that they can experience it through the product. We found a small little product out of France actually called Gemo that's a little assistant that we plugged into our back office now. Our back office is our administrative panel. And that was an experiment. Customers sometimes just don't do the work we ask them to do between our—

Oh yeah.

Right? You know that. You've lived that problem. And we are like, what can we do to make them do the work? And we were, what if we were able to put a little assistant in our back office and make them do the things when they log into our back office rather than giving them a sheet that's outside our product, like a checklist that they have to go execute against. And we tried that. We built this little widget in our back office with a checklist and we give them 4 things to do and it gets done more often than not now than it used to before. So that was an experiment. We tried it, it works really well. Now we are deploying this little widget for so many things, including, you know, pushing release notes to the customer in the back office. If their app is outdated and it needs to be updated in the app store, we'll send them an alert saying, "Hey, your app needs updating." So things like that, we've started using that widget for. So what started as a small experiment to improve time to onboarding ended up now being a complete widget that helps us to manage different aspects of the customer's lifecycle. We even push relevant webinar promotions through the back office to relevant customers. Then they go and register for the webinar in our product, which is our own customer community. So, Dogfooding your product as much as possible is another thing that can help you to drive adoption. Another one like that, actually it's a big one, is we have very robust APIs, but we never had pre-built integrations out of our box until 3 years ago. We realized that that was a big opportunity. So rather than waiting for product to put together a squad that can help us to set up pre-built integrations. That was the time when I was stepping into the revenue role, coming out of product. I said, why don't we go and get a middleware platform and build out a few integrations ourselves with a contractor? It doesn't take much to build a Salesforce connector or a HubSpot connector or whatever. And we built a couple of those. We went and pitched it and we started getting so much traction that now Over 30% of our customers buy prebuilt integrations from us. And obviously now the product team has taken that over and they're productizing it a lot more. But that's an example of an experiment we started on the GTM side, built an offering around the core product, commercialized it, proved the value, and then brought it back into the product.

I think one of the macro lessons here in a bunch of these examples is being able to start small and prove something out. And I see what oftentimes happens in other functions, revenue leadership and others. It's like, oh, we have a problem. I think we know the solution. So let's deploy it to every single sales rep. We're going to like push this out across the board rather than saying, okay, like what's the small safe space that we can deploy this into, learn, and if this thing works, then go big. And it's, it is no more like, it has never been truer than in, in the AI world where there's a thousand different tools. And I give this advice a lot to revenue leaders. I'm like, don't, if you push out two or three tools, you're like, this is game-changing, it's going to be awesome. And then it flops. Like you very quickly lose credibility with your team and that they're not going to lean into the next thing that you, ask them to do. So we've done this recently and we're able to improve the per rep output by 85% of our BDR team. But we had this like little group of 4 and our GTMAI lead and one of our Biz Ops people went, went to Toronto. They sat next to these 4 people and then they went like over and over, like they did iteration loops hourly. Like they would work on some things, then YG, who's the AI guy, would like go and rebuild a thing. He'd be like, okay, like now try this version. And they would do like 30, 40 more calls. And within 2 days, they, they had like cranked the output massively. And then, you know, the other BDRs started to see how many decision maker connects and how many opportunities they booked. And then we rolled this, this product out, uh, this internal product out across the rest of the organization, just outbound BDR, and now it's going to the other sort of BDR and SDR teams. But if we had done the first version of that across the board, it would've been— it would've been chaotic. It would've been too much all at once and we wouldn't have had it dialed in well enough to be confident. And then you're now, you're now trying to troubleshoot across like 50 reps instead of 4 that you can like sit next to.

Totally, totally. I mean, we applied this to a whole acquisition actually. We acquired a company called Orbit. You probably participated in Orbit matching rounds even.

Oh yeah, yeah, yeah, yeah.

Right, so that's part of Highbright now. So we acquired Orbit 2 years ago, a year and a half ago. What we did is we set up a SWAT team of just 3 people outside of sales, outside of customer success, outside of implementation. So on the GTM side, we put together a team of 3 of us and we said, we are gonna go, like, I took it upon myself to pitch the first Orbit deal in the Highbright world and secure the first customer, figure out how we would take it to market from within Highbright. And we ran the first 6 months with just a SWAT team. So Orbit became sort of overlay team and we came in into a sales cycle when we would think there's an opportunity, for example, to pitch Orbit, and join the sales team and handle the Orbit part and let the sales team do the rest. So we kind of ran 6 months like that. We commercialized it in the hybrid world, picked up the first million dollars of revenue that way, and then we rolled it out to the whole organization. So yeah, you are exactly right. When you wanna introduce a transformative thing in the GTM organization, start small, keep it focused with a few people, roll it out, test, learn, and then harden it and finally then operationalize it and deploy it organization-wide.

You don't want to be wrong a whole bunch of times, or leaders like don't want to, don't want to be wrong. And so how do you create the right environment of, you know, psychological safety in the team and maybe like open-mindedness from the sales reps so that you can deploy and make mistakes and not feel like you're losing credibility?

I think it's cultural. It starts from the top, right? So if you are vulnerable and you show how vulnerable you are and fess up to your own mistakes, I think people don't hesitate to do the same. So you have to create an environment where if someone needs help, they're able to ask for it. And if they make a mistake, be able to talk about their mistakes and share it so that we don't repeat the same thing again. And it starts with you as leadership. You gotta get your hands dirty and make some mistakes that are visible to your team and then talk about it and then go back, pedal back and course correct and show them how you fixed it. I'll give you an example. Last year when I took over customer success, I felt like we were missing an element of support in our support team. We have a regular product support team, and I felt like there was like a gray area where, you know, there used to be issues that customers ran into when addressing problems like SSO or DMARC, which is enterprise email protection, like setting up your email domains and things like that properly to be able to increase email deliverability. So there were some tricky technical topics where customers used to get stuck because they themselves didn't have the technical expertise to be able to solve those problems. Even though it was not our problem, it was the customer's problem, they would not be able to solve for it. So I was like, you know what, I think we need a level 2 support team. And I put together a team of 2 or 3 people who became sort of this escalation level, level 2. And what I realized through that process is that I was just creating more friction between our level 1 team and our level 2 team. And the real solution was to actually upskill our level 1 team to be able to handle that within their own flow of work. And so, yeah, we set it up and then dismantled it in 3 or 4 months when it didn't work. So, I think you gotta be prepared to then go back and say, what— by doing that, there were some learnings that came out of it. We could not have learned that we needed to upskill the core support team if we hadn't done it. If we had continued doing what we did before, we would've never solved those customers' problems. We were able to understand what problems we wanna solve, what problems we don't wanna solve, what we wanna solve through better documentation or other things. And we were able to kind of assess it better and then bring it back into the core support team. But it was not an experiment that was a slam dunk, you know, that we could just move forward with.

And going back, it's like culture and expectation settings. And I think sometimes the confidence level with which you communicate things, you know, sales leaders, we're like trained to communicate things with confidence and in absolutes. Oh, our product is the best. You know, this is going to be awesome. It's going to change everything about how we do business. But instead, if you can just be like slightly more nuanced.

Yeah.

Nuanced and humble to be like, hey, you know, we're gonna deploy this thing. We're excited about it. I need your feedback. Like, you know, we think this is gonna work for these reasons, but I need, like, as you're using it, like, we need your feedback to make it better. Like, we want it to, we want it to grow over time. And just like having a slight change in tone gives you then the, space to say, hey, this like didn't work, we're changing it, or it did work, but not the way we wanted and we're like reformatting. You don't have to have egg on your face then.

But then that's also a learning back for product teams. I'll say when you put your neck on the line and you say, I'm gonna bring these results to the company on— I see that spirit a lot on the GTM side. And sometimes I find that missing in internal teams like product and engineering teams. So there's, It's not just one-sided learning. I think there's a lot for product teams to learn by getting closer to GTM. If they align themselves to every step in the customer journey, every part of the bowtie, they would do their work so much more faster. They would be so much more informed. They would not have to rely on secondhand information to do their job. Their experiments can bring go-to-market people into their experiments from the beginning so they're not missing the mark in terms of what the market needs. There's so much value in product teams also getting closer to GTM teams.

100%. I think that's a good place to transition to a quickfire. So what do you think separates a good CRO from a truly great one?

Being data-driven.

What? What is the most common advice you find yourself giving to new leaders, people in like a new second-line role, their first like real big spot?

Just don't bring frameworks from the outside and try to plop them in, in our company. Figure out what works best for us and develop new frameworks. I'd rather go with that approach than trying to just take textbook knowledge and apply it.

What's the hardest lesson you've had to learn in your career?

Don't hold back. If you have a gut feel about something, go all in. And what's the worst that can happen? You're not good at it or you fail, but at least you've tried.

What's the best thing you've read in the last 12 months?

I was thinking about that question because I've heard you ask it to others and I was gonna either give you a fake response or I was gonna be honest. So I just, I'm gonna be honest. I haven't done long-form reading in a long time, but I'm a little— Oh. All the New York Times podcasts, whether it be The Daily or The Wirecutter, or more lately, I love The Hard Fork. It's really fun because it gives me everything I need in one place. And so yeah, I'm an avid listener more than a reader.

Very cool. Well, Usha, this was awesome. This is exactly what I wanted to cover in today's episode. I feel like we pulled out a ton of really interesting frameworks. That hopefully people can apply in their day-to-days. So appreciate you joining, and this was a blast.

Thank you. I enjoyed our conversation too. I don't do very much of these, so I didn't know what to expect, but once I was into it, I was on a roll. So thank you.

Thank you for listening to the Revenue Leadership Podcast. If you enjoyed it, don't forget to subscribe, and you can find a link in the show notes. And be sure to leave a 5-star review, share it with your network, and please join me next Wednesday for another great conversation.