Transcription
[Music] Good morning everybody and welcome to this episode of 30 minutes to president's Club. My name is Arman Fro, and I'm here with my co-host Nick Selski. And today, we have the one and only CEO of Align, his name is G AA. Nick, why should people listen?
G takes us through how to attach the problems you solve to the root causes of those problems, to what you're going to show in a demo, to how you ultimately build out a business case. One of the big things we've been seeing recently is your champions have to sell on your behalf. And if you're not starting from the beginning, attaching those things, and then codifying it in a way that it can be shared internally on their end, you're going to struggle. And so G takes us through how to do that in this episode. In 3, 2, 1, let's roll.
All right, go. Welcome to the show. We start every single episode with your top three actionable takeaways. So let's get your three.
Great. Thanks so much. Excited to be here. So my first takeaway really is what I call the why demo formula. What a product does and how it works is really how 99% of demos out there look like. And we hear all the time that mantra, demo value, not don't demo features and demo benefits and all that. But what's missing is that there has to be a practical framework of how to do this right. And even great AEs that do great discovery, it always looks like that there's the good discovery, and there's, and, and it's, there's a pause there at that meeting. And then from that point, it just moves into, here's the product, and here's how it works.
One of the best ways to go and solve this is planning ahead of time your path. What good looks like. What are the problems that you typically hear? And what are the different demo paths that you use to solve these problems? So, for example, at Align, we could hear about multi-threading challenges, and the demo path could be uncovering hidden stakeholders and how to use Align to engage new stakeholders. Or it can be someone talking about how champions fail to sell internally at the decision stage or mid-process, and we could demo the champion enablement capabilities of Align and how we can use Align to simplify the decision process and to better collaborate and co-create with champions.
Amazing. What's number two?
Great. So number two is, we focus so much on teaching how to do great demos. And we get executive meetings, and we run the same process. Okay? So a lot of great AEs know that discovery is not a step, and it's something you do throughout the entire process. But then they get to the executive meetings, and they run the same type of conversation, try to have a lot of discovery, a lot of questions, a lot of small talk. But that's not how executives buy. So executives get, basically, at the end of the day, you lose them in seconds if you lead with questions and not, not lead with insights. So that's really kind of the, the, the biggest tip that I have there is, there, executives expect you to already know a lot by the time that you get on that call. You had conversations with the champion, you have conversations with their team, and you've learned a lot about their business. So leading with insights and not questions basically means that you can talk about the macro, macro trends in the market. So as an executive, I'd like to better understand what's really going on right now and to relate a little bit into what behind your solution could drive the urgency and could, and make sense to invest in it now. Secondly, I would like to hear about what others like me are saying. What are problems that you're hearing from others in the market, and feel like I'm in good hands. And the third thing is what you've learned from speaking with my team. So a recap of what you've learned, and then we can have a conversation.
Beautiful. Round us out, G. What's number three?
Great. Yeah, so number three is ROI in sales. So 99% of buyers just don't, don't buy it, right? They don't fall for it. They don't believe ROI numbers. The way that it typically works is you get to the end of the process, there's that fancy big calculator, and you sheep that calculator, maybe you plug in a number or two, but hey, here's your ROI. I think the number one reason that fails is that we're pitching in sales a return before we truly understanding or showing our prospect that we understand their business. Do you want to know as a seller, what is my current state? What am I trying to accomplish? What's preventing me from getting there? And how do you quantify the problem, right? What's the cost of me doing nothing? And help me believe also that you can solve my root cause. Only then really go and build an ROI or scenarios. Instead of, here's your ROI, build some scenarios that I can go and play with, but that are based really a good understanding of my business.
So go on the prep. You walked us through all of the steps of your why demo formula, which was part of your first takeaway. So the step one is you want to build a map between the problems you solve and the demo paths you could use to solve those problems. Step two is you want to take notes during discovery of which problems you're going to demo. But then I want to zoom in on step three, which is once you know which problems you want to demo, before each demo path, you said you need to recap both the problem and the root cause before you demo anything. I'm hoping that you could unpack that a little bit more for the audience.
The whole point of that call is discovery, right? Discovering that there's a good fit, okay? Covering value. Big part of it is the problem, but also I need to get the confidence that you can solve my problem. When there's that disconnect, when there's discovering, we talk a lot about problems, and then cut, we go into present mode, and then we're just running through present mode, we're missing out tying the connection between the problem and the root cause to the solution. And what that means is that we bring all of the mental load to our prospect to try to make that connection. And most of them don't. Like they have so many things going on. Even during this podcast, like I'm getting alerts on my Apple Watch, right? So many things are grabbing your attention and taking you sideways.
A good best practice there is you're going into each of these demo paths of a solution is to recap. Right? So for example, Align be something like, John, earlier mentioned that your team struggles accessing e-roll since many of the stakeholders stay hidden behind forwarded emails, and you spoke about how that leads champions to fail internally when they're trying to drive consensus, and of course, that leads to lost revenue, right? So when I'm doing something like that, I immediately bring the challenge that we talked about. I'm showing that I've listened throughout the conversation, and I now can go and show the solution.
When I was in high school and I learned how to write an essay, what I got taught was before each argument or paragraph in the essay, what you're supposed to do is say, hey, here's what I've told you, here's what I'm going to tell you next, and then you give sort of the, the argument in the essay, and then you recap it again. And all you're doing is when you're showing a demo of Align, G, my guess is you're showing six or seven or eight or nine different things. It might be easy for you to follow because you've given these demos a ton, but for your buyer, it can all sort of blend together, and there's distractions. And what you're doing when you recap the problems and the root causes is you're almost chaptering your demo and you're putting some structure around things. The other thing about that recap and the root cause is often times when you're showing a demo, you've got new stakeholders in the room, and it can be good for them to hear your understanding of the problem and the root cause because they might not have thought through those things before.
It's exactly that the framing and checking. Because think about really what's going on. You, you end the demo, they go back to their day-to-day job, okay? You might follow up in two weeks because there's vacation, and then they need to go to their manager and other stakeholders and get more people in a demo. So what's going to happen? What are they going to say? They're going to say, yeah, they do this, and you do that, and they showed me these features and these features. Or are they going to have clear chapters? They have a solution for better multi-threading that does this, and something can help us enable champions when they'll sell internally by doing this and that, right? By chaptering, you're really creating these easy bookmarks, really, of something for them to repeat. So that really makes so much difference because it's less about the how things work, how, how the analytics work, it's more about how the solution to your problem would work.
The root cause is the linking point or the linkage between the problem and the demo story or the demo path. I remember at Pave, when I was teaching my reps to do discovery, it was so, so hard to get them to get an HR person to say, yes, we have massive employee retention issues. And that's the problem. We have a ton of employee retention issues. And they would get so excited when they got that where they'd say, now buy Pave. And I was like, no, you skipped one step right there. You need to be able to say, you have employee retention issues, and the reason for that is because employees can't see the value of their cash equity and their benefits all in one place. So they think they're being undercompensated. And so let's pretend I'm Nick. I open up my Pave portal, and now what I see is that I've gotten three demotions, two comp decreases. If I'm Nick, but if I'm G, I'm a better employee. I see I've gotten promoted two times. I see I've gotten my comp increases, and I can see that not only have I gotten salary increases, I've also gotten equity increases. And the only reason you can tell that story is because you said the reason that you have compated attrition is because employees don't understand this. So I just want to underline how important that root cause piece is because otherwise you sound like you have pipeline issues.
By Align, there's a middle step that happens between what happens at the end before you wrap and move to the next part of the demo. It has a lot to do with time, right? So sometimes you might have done 30 minutes discovery, and then there's just like 10 minutes maybe to show a few things. But if you have a longer conversation, let's say discovery is in a separate conversation, and you're just doing a little bit of a deep dive, and then you're showing more of a demo, then I would try between each demo path to validate. So you want to validate before moving to the next problem in demo path because again, you saying, here's how I'm going to solve, here's the problem, right? We talked about this earlier, John, right? And here's the way that this could potentially solve the problem. That only brings you to a certain point. So I would go and do a quick, easy question, how do you see your team using this? Or how well do you think that this could solve what we talked about earlier, right? That makes them think, that starts a discussion, that brings up objections. Objections is a good thing, and then we can move on to potentially the next thing. And even if I get two or three demo paths done, that's in most situations, that's enough. We have a deep, meaningful conversation around two or three areas of value versus trying to cover a lot of things in the demo, and then someone asked them, what is Align? They'll just say a lot of different features.
We often times call it a future question, which is a lot of times people will do a demo and they'll ask a present question, and they just ask, how do you do this today? And it just feels like a continuation of doctor checklist questions or discovery. What asking a future question does is it says, hey, let's pretend I put this in your hands today, like how would your team actually roll it out? Or what would you want to see? It gets them thinking about how they would actually use your solution today and also potentially some of the roadblocks they would run into. You can also ask a past question, which sounds like, hey, you mentioned earlier that your team was having a lot of time struggling with multi-threading, right? I'm curious, let's just pretend they were using this today. How does this compare to their current process that they're working with? And so you can recap a problem that you discussed earlier, recap the root cause again, and now that you've showed the demo path, you can say, how does this compare to that in the past? So you have future questions, which help you make it real. You have past questions that will contrast your solution with their solution today.
Go. I want to ask you about what happens deeper in the sales process. You're the executive buyer, and you buy a lot at Align. One of the principles that you were telling us about is solving for starvation versus indigestion with information. And I'm curious if you can talk about how can sellers better navigate that decision stage of a deal?
The problem today is that buyers don't lack information, like there's information overload. You, your role as a salesperson is not to try to solve how much information you can give your buyer in order to make a decision, rather it's to be a sensemaker, how to optimize for better consumption of that information, indigestion of that information. So a few examples can be sharing just fewer links, fewer attachments, fewer back and forth, and really organizing all of all of that workflow. Another one would be in it's timely, like I'm, we're right now just building a huge requirement, building documentation. So instead of saying we didn't build a product ebook, we thought it would be much better if we build a requirement builder that has all the different things that you will need to look at when you're buying digital sales rooms, or how do you use, use like a two to three minute recap video of a use case versus sending a 60-minute gone call. So that's just one example. Another example could be all of the email link attachment graveyard. That email is where a lot of deals go to die. Sales should look at their job as project management of the buying journey. I like saying you're providing buying process as a service, that's your role, and that's how you should look at it. And then email is really a lousy mechanism to do that, and like things just get lost. You, you send a value summary in email one, a PC summary in email seven, a case study in email 15, pricing in email 25. People are looped in at various points of the process, and then you just dumped a lot of information throughout the process. Try to organize it. Being a little bit self-promotional, that's exactly what a deal room does, keeps everything in one place. But you can also do this with a Google Drive or with very custom-made decks, and really just think about what's going on right now, who was looped in, how much do they know, why they need to buy, and where we are in the process.
I want to talk about this in the context of a business case, because a business case is supposed to be the antidote to indigestion, where I'm taking all of the qualitative things that I've learned about your business, I'm talking about those, how they quantitatively impact the bottom line of the business, and then I'm usually including some things that you would need to act on to achieve those benefits. Those are usually the three parts of business case: qualitative, quantitative, and then what you need to do, implementation, resourcing, things like that. I've seen people have 30-page business cases where it's practically like a Gartner report on its own, and it's every feature page, every case study, a million different things. Could you walk me through what is the flow of a better business case? What are the main chapters in a good business case?
Business case ideally, you want it to be one or two pages of the core of what is the problem that you're trying to solve, what is the root cause behind the problem, what's holding them back, what is costing them to continue this way, why they must act now, right? So it's the entire story. And you want to make sure that there's a compelling story where most sales miss is when we're selling these products, we're not solving the, the problems that most sales people think that we solve. So I'll give you an example. Both Gong and Align, completely different solutions, solve for win rate and solve for a better deal visibility. But we don't compete. It's a completely different technology. One is a customer-facing collaboration tool, and another one is about revenue intelligence for actual sales conversations. So they both kind of drive the same value, but what's different is exactly what we talked about earlier, is the root cause. The root cause of things that we would solve for is champions failing to sell internally, or sellers don't know who the stakeholders are involved in the deal, or sellers losing control over a complex POC because they're failing to project manage the deal and create alignment with their champion, for example. So you want to make sure that really your narrative of writing that business case gets into that level of root cause language. And the root cause is also not enough because the executive is going to ask, okay, why haven't we done anything so far? Why can't we solve this in other ways? And how important it is to solve? And why is this more important than other priorities? So just really put the questions that an executive might ask in your mind. And then this would be the framework. The solution part, it should be a smaller piece. It's more about really framing a very compelling problem to make sure that someone spends budget.
What's interesting is you talked about, okay, how else have they tried to solve this problem? And even earlier, you were talking about, well, people could solve the multi-threading, the hidden stakeholders, the champion enablement problem with Align, but they could also solve it other ways. You were like, they could set up a Google Drive, they could have a shared PowerPoint deck. When you explain to your customer, hey, there's other ways to solve this problem beyond buying something from me, one, it makes you look more credible. But then two, you can include that in that business case. When you really build out the problem, hey, there's lots of different ways you can solve this. It doesn't sound very attractive to me as an executive to have my entire team set up Google Drives to share with all my customers. It probably sounds more compelling to end up working with Align here.
So I want to go back to the ROI case that you talked about at the beginning of the show. So step one, you understand their business, etc., etc., etc. And then from there, the next thing you're doing is you're quantifying the cost of inaction. Can you talk to me about how you do that?
Stuff that's at the end of the day, that's the return, right? That's the opposite of return. So for me to see a return, there has to be a problem that I believe is equivalent to that potential return, right? So the fact that Acme, for example, 10x their pipeline using my solution doesn't mean that any other customer will will achieve that same result because it might be that Acme didn't have SDRs or weren't doing anything in the first place, or their emails were really, really bad, and then the solution took them from a very, very bad situation to here, right? So the concept of quantifying the problem is called really cost of inaction. And let's take an example from Align. So if we want to go and build a very tailored ROI, then we would go and think about, let's say, okay, so telling us that their challenge is timeline, their challenge is cycle is getting longer, and it's getting longer because POCs get dragged. Okay, how much is the POC causing the timeline to get longer? Okay, oh, it's getting dragged from two to five weeks. Wow, that's significant. How many of these POCs get dragged from two to five weeks? 50% of them. Okay, the 50% of these POCs that get dragged from two to five weeks, can you isolate them and tell me what's the win rate and cycle length in these POCs? Here, here it is. And then then I'm getting really to a cost. I can go and say, overall, we're working X amount of deals, half of them are getting stuck in the POC, and it's getting dragged from two to five weeks, and that's worth that much in win rate, that much in sales cycle times, the ACV. That's the outcome.
To bring this full circle, this really ties to the demo framework that you talked about earlier, which is first thing you're doing is you're quantifying the problem. And let's say for the, the example that we used earlier, is I need to quantify your team is struggling with multi-threading. What does that mean? What is the average win rate when you have power versus you don't have power? And how many deals is that impacting? If you have 100 deals, half of your deals don't have power, you have a 20% lower win rate. Boom, that's an ARR opportunity. From there, you attach that dollar number to the root cause that you can solve in your demo flow, and that's the next step in your business case.
Talk to me about, I have multi-threading as a problem, Align can help with that. Root cause. I have, next thing is my problem driving timeline is my next problem. Align can help with that. You talked about building scenarios, not a dream outcome. What's an example of building scenarios in an ROI case? What am I going to believe if you're going to show me just one scenario?
Then okay, that number looks great, that looks big. But it's same thing as negotiation, right? We want to give options. That's a good best practice. Like giving options shows me that I can play around with this, that this is not, this is not accurate, this is not really what this is going to be, this is just us building together as partners, some hypothesis, an hypothesis of how this is going to play out potentially. And as I'm going through the process with you as a buyer, then we're really co-creating and co-designing this, then it makes it more believable. So what I would go and do is build scenarios that one of these scenarios is the cost of inaction. So if we understood that that dragged POC is leading to, I don't know, million dollars in lost ARR, so that's one ROI scenario. But then try to create scenarios that are not as great. Because if the problem today is that, and you're fully solving the problem, what about it's all about risk management? What, what about if we solve the problem by 50%? If the implementation doesn't go well, or if people don't adopt it in the same way, or maybe the problem is also tied to skills and you can't fully solve it, okay? So build more scenarios for me to also understand what is the worst case scenario look like. And I think that what most sellers are trying to do here, they're trying to show 10x, 20x, like crazy numbers. But buyers don't need that. Like they don't buy only because of impact. Okay? There are many other benefits, there are many other things that are non-measurable, and they get that. So as long as that you can show two to three X as the, you know, as a good baseline, just show a few more scenarios that are even worse, that's okay.
When you model out those not as good scenarios, it also helps you prevent against future objections. Exactly. It's showing a good worst case. It sounds like it's the best way to sell. Show me a good worst case.
Amazing. I'm curious, with your worst case, is that often times not recouping the investment? Like how bad of a worst case can you get away with showing? And the reason that I ask is people will try to do this when we sell 30 minutes to president's Club sponsorships all the time. Well, they'll be like, okay, I can't attribute the impact of your social posts. I can't attribute the impact of your podcast ads. I can look at how many webinar leads actually bought our software, and that's my worst case scenario, only this portion of the sponsorship that I can actually track. And often times that actually makes a decent dent into the cost itself. But sometimes I'm like, no, like that worst case is actually like a fraction of what you're buying. So how bad can your worst case be relative to what you're asking them to pay for?
You need to really create realistic scenarios, right? And if your worst realistic scenario doesn't return the investment, doesn't recoup it, but there are other amazing benefits, and you think it still makes a strong enough case, yeah, try to say, yeah, I still believe that we have a good partnership here. If you don't, then don't sell a bad deal. It's not about where you're trying to put that case at, it's trying to just find what's reasonable. Because then at the end of the day, you're going to face the customer tomorrow, and that's brand, and that's long-term relationship, and that's retention, and that's potential expansion, right? So SAS is not about the sale, it's about long-term sales and long-term retention is and growth.
Often times we think of ROI in three different levels. The first is the trackable stuff, the people who download your asset, the people who sign up for the webinar, and that's like the bare bones. It's literally only the people that you have track of. The base case. The middle case is if you start to scale that up and you assume that there are people that you can't track on the podcast, there are impressions, and you can scale that up and you can start to say, okay, if like we can only track a quarter of our traffic, what is this remaining 75% of your sponsorship get you? And that's sort of your middle case. The final case is when you can start to get the emotional reasons, which is if you're telling me that between the cost of the leads you can actually track, the untrackable leads you can't see, and the brand halo effect of making sure that everyone actually knows who the heck you are, if I can't make up the ROI between all three of those things together, then honestly, you probably shouldn't be working with us. By having their commodity case as the worst case scenario, it almost puts it out there versus leading with only the dream case scenario where it's like, there's untrackable stuff, there's trackable stuff, and there's dream outcome stuff. They often times tear down the entire thing versus acknowledging their worst case scenario as the first case. And showing that worst case scenario, and someone buying after they're seeing that worst case scenario, they're going to be a better customer versus you're only showing that dream. And then if they get to the worst case, and the worst case is good, let's talk about a good worst case. Okay, they're going to be upset because he sold them the dream.
Amazing. Well, clock is ticking and we are running out of time. So we got to move to the final question, which is this. We've talked about a lot of really good things salespeople should be doing. Now I got to ask you about what I shouldn't. And so the last question is, what is one bad habit that you see a lot of salespeople exhibiting that you think they need to break because it hurts them more than it helps?
We have this month, TR sales always have a next call booked. I would challenge that month with replacing it with a better question. How are you supporting your buyer next steps? Always have your buyer next steps supported. So I would much rather hearing my sales team saying in a forecast call pipeline meeting, we're right now working asynchronously on a business case, okay? And they're going to present it internally versus, I have a weekly catchup. Okay, what are you doing? How is the deal progressing? Have the confidence to work with your champion as asynchronously and really ask yourself all the time, how are you driving the deal forward? Not how are you getting control? It's not really control. You're not really in control. Eventually the deal, you can influence it, but you can never control it.
Amazing. Go. Thank you for joining us, everybody. Stick around for a 60-second recap coming up soon.
All right, Nick. It's time for a two by two recap from this episode with G AA. What do you have for your two?
Before you even go into a discovery call, you need to have a clear sense of the problems you solve, the root causes for those problems, and then the demo paths or the value stories that you're ultimately going to show and tell. You want to know what you're looking for when you go into a conversation with your buyer, rather than just hoping they're going to know exactly why should buy and what you should show.
My second one is when you are building out a business case, do not just model out one scenario. Instead, especially with ROI, model out a, not so good, a pretty good, and a best case scenario. This not only makes you come across more impartial and more realistic, it also can help overcome objections to your business case.
Number three, link the problem to the solution using the root cause. So a lot of times people will say things like, oh, you have pipeline generation issues, you should buy my product. But you need to be able to say, you have pipeline generation issues because your reps are struggling with cold calling, and for that reason, they need cold calling training, for example.
And lastly, number four, demo in stories, not in features. I find a lot of reps will get to the magic moment where they're ready to demo the problem they can solve, and instead of speaking in the day in the life of an employee, where you might say, well, Nick opens up his portal and hears what he sees, they say, this is a page that adds compensation plus equity plus benefits, and they are literally just describing the feature. So describe the demo in terms of the day of the life of the problem.
All righty, Nick. How could people help us out here?
So Arman, you and I put together a number of 30MPC, what we call buyer enablement templates with the team at Align. And that includes things like a mutual action plan, business case templates, and deal rooms. The 30MPC way. There is a link in the show notes to go get that. If you like some of what G was talking about today and you want to see how 30MPC can help you put that into action, it's free. Go check them out and they should be helpful. Thanks for listening. We'll see you next week on the show.
[Music]