The Man with the Golden Process

Having conquered (almost) his entire known world before he turned 30, Alexander the Great can rightfully be called one of the greatest military commanders of all time. By this time, he had defeated what was at the time considered the greatest empire in existence, and his Macedonian Argead Empire stretched from Greece to the Indus River, covering more than 5.2m square kilometers (2m square miles).

Readers who are unfamiliar with the story might be curious about what happened next and how long Alexander’s reign and dynasty continued for - and might be surprised to learn that the answer to that question is less than five years. Instead of consolidating his gains and calling it a day - after more than 10 years on the (military) campaign trail - he continued to push eastward, his soldiers mutinied and refused to march further, Alexander was forced to return home, and he died of mysterious circumstances shortly after making it back. 

There are two lessons to learn here for those of us wanting to implement demo automation. Number one is to know when you’ve hit your limit, and number two is to ensure you solidify your gains to take them from temporary to permanent.

This article will cover the final two steps one needs to take to successfully drive change management around acquisition and adoption of demo automation software in an organization, namely, how to sustain and consolidate a change - Sustaining Acceleration and Institutionalizing the Change. In other words, we’ll look at how to avoid Alexander’s fate (not dying - I am not a doctor - but losing his empire) by ensuring that all the work we’ve put in so far is just enough to overcome that initial inertia and make sure that your Demo Automation engine can keep running.

Sustaining Acceleration

I mentioned that lesson number one is to know when we’ve hit our limit. At this point, we most certainly have not - but our aim is to get there. Now that we’ve successfully turned plans into action and momentum into pilot(s) with concrete, measurable wins and success stories, we’ll want to push forward until we meet our very own Indus river. 

You should now be in a position where you and your change management effort has gained significant credibility - you’ve shown that your demo automation tool(s) can generate outsized value, make people’s lives easier, and you have the social proof to demonstrate it. But the people you would count among your users probably only cover the very beginning of the adoption curve, and one could argue that now the hard work starts - winning over the people who are probably going to be, at best, lukewarm to the idea of changing their behavior.

So what does this look like? What black magic do we need to use to do this? Well, the playbook doesn’t really change. You’re still trying to get people’s “so what” right, convincing them that you can solve their challenges and make their lives easier. What changes is your audience - with the “early adopter” type personalities in our volunteer army and pilot, the promise of something amazing was enough to get them onboard. As you work your way through the adoption curve, however, people will not only start to care less and less about ideals and more and more about actual, tangible value, but they’ll also generally become more skeptical of changing the way they do things. That’s why having done all the aforementioned six steps is so crucial - without the proverbial snowball having been able to grow big due to your systematic efforts to create and sustain momentum and success, you simply wouldn’t have been able to convince these people. But since you have, you can double down and let the story tell itself. Gradually expand your user base, using your Pilot, the learnings, wins, and people from it, to slowly but surely spread the footprint. Keep adjusting your approach to new feedback, keep setting new goals as you meet your old ones, keep the urgency and impact drumbeat going, and keep celebrating wins early and often.

Achieving 100% adoption, however, is probably in most cases unrealistic, and in some cases not even desirable. To determine a realistic target - your Indus - you should consider how well the use cases/problems your tool solves applies across the user base you’re trying to spread it to. For example, in a B2B Sales organization, when it comes to demo automation, the value proposition will likely resonate more strongly in higher-volume segments than it will further upmarket. The more support a given seller, team, or segment already has, the lower is likely the perceived need or value-add for a demo automation tool. At some point, if your persistence and insistence doesn’t lead anywhere, that might serve as a “natural barrier” for how far you’ll be able to scale your efforts. Trying to penetrate further into the organization despite the perceived lack of need could also backfire - Sales leaders typically aren’t too happy if you’re trying to force something that doesn’t really work onto their sellers, and can hurt your credibility. Remember that your end users don’t exist for the benefit of your tool - your tool exists for the benefit of your end users.

Institutionalizing the Change

Now that we’ve reached our Indus, it’s time to do what Alexander couldn’t - consolidate our gains. We do this by institutionalizing the changes - not as in putting them in a mental health facility, but as in making them “sticky” by ensuring that they become part of “how we do things”. Entire books have been written about what and how you could do, but the most important thing - outside of continuing to keep the drumbeat going across all levels of the organization - is embedding your tool(s) and processes in established policies, procedures, programs, and playbooks.

Let’s consider a few examples of what, in my experience, I’ve found to be some of the most powerful ways and places to institutionalize demo automation:

• Before anything is sold, sellers need to be onboarded. Onboarding is where habits are created, and after they are, they are notoriously hard to change. Thus, you’ll want to make sure demo automation is covered during Sales onboarding - maybe not as the first thing Sellers are exposed to, but certainly after they have a rough general idea of what your Sales process looks like so that any training and enablement happens in context. Don’t underestimate that final point - information provided during onboarding tends to go in one ear and out the other, so in order to make sure that it sticks, relevance and timeliness are critical. If your tool can help reduce ramp time (reduce the delta between when they’re hired and when they can actually sell) by helping them position products they otherwise may not have had time to gain confidence to present on or demonstrate themselves, you’re going to be a favorite among your Onboarding trainers (and your Sales leaders).
• Whenever anything new and exciting is launched (such as a new product or a new process), or when something is decided by leadership as warranting special attention, sales enablement will typically be in order. And here is another opportunity to become embedded into a process. If we can help our Enablement friends more quickly and efficiently put Sellers in a position where they’re able to sell the new product, follow the new process, or do whatever Leadership wants them to do by making it easier, they’ll likely be more than happy to cover demo automation as part of any such enablement initiative. This is doubly effective because not only are you providing training in context (the importance of which discussed above), but if you can “train the trainers”, you’re not even having to actively do anything, meaning you have more time and energy to spend on the next thing. This is what institutionalization is all about!
• Organizations might also have Sales Programs people or similar roles whose sole purpose is to help make it easier for sellers to sell more and sell better, and to help bridge the gap between (local and global) leadership priorities and sales execution. They will typically create programs, playbooks, and other types of assets to help the Sellers do so. If you can ensure that demo automation shows up in those assets, you are taking it from something that lives “outside” of the “normal” sales process, and you’re ensuring it sits front and center and top of mind for Sellers without having to put in any additional effort to do so. And after you can show your Sales Programs colleagues how your tool is helping them help their Sellers generate more pipe and close more deals, you will continue to show up in their assets.

If you happen to be fortunate enough to have buy-in to do this earlier, you do not have to - and should not - wait all the way until this point to do so! All of these, outside of the Onboarding point, can take place on a smaller scale in your Pilot programs and will help build the right muscles, generate even better results, and create invaluable relationships if they are allowed to happen. The additional momentum you gain from doing so will just make it easier to truly institutionalize these processes later on.

Having completed this step, what you’ve essentially done is build demo automation into the very fabric of how your Sellers operate. Using change management principles, you’ve built an “engine” that, after you’ve managed to start it (with your preparation and execution), now not only idles but consistently runs close to the redline. And because you’ve managed to push it beyond the RPM at which it will successfully idle, the engine will not stop. Instead of having to pull the starter cord on your lawn mower like a maniac every time you want to mow your lawn, you’ve now essentially got a robot mower that will mow it for you. And you can focus your time on optimizing how the robot runs, plant a bigger lawn, or move on to a new project entirely.

How do you know if you’ve been successful?

Robot mower analogy aside, what are the tangible, tell-tale signs that will tell you about whether you’ve succeeded in implementing demo automation software in your organization and have made it “sticky”?

In my experience, the signs are both quantitative and qualitative. You should be able to see high adoption (licensed users as a percentage of potential users) and usage rates (users who have actually used the tool as a percentage of licensed users) among your users, as well as significant impact on business data (percentage of (number of) all Sales opportunities touched/influenced, percentage of all Pipegen and revenue touched/influenced, and on any other metrics you care about), and bucketing these by leaders, teams, countries, regions, etc. can help you pinpoint where things have worked really well as well as where more work might be required. This is NOT something to save for “the end”, but something that should be monitored continuously starting with your Pilot groups. 

Equally as powerful, however, are the qualitative signs. These can be hard to define, but I like to think of them as the “momentum” or “buzz” associated with your tool or process. Are they called out by leadership as a suggested course of action when leadership beats their drums? Does it show up in processes and Slack channels as a recommendation? Are teams and Sellers talking about it? (As an anecdote, any time I go into the office, I’ll have Sellers come up to me and ask me about the tool I manage and tell me how much they love it). But for me, my favorite one is when it shows up in places you didn’t expect and that you weren’t involved in. When suddenly it’s included as a key resource in some process or program you knew nothing about and only heard about it after-the-fact. That’s when you know it’s been a success - when you actually don’t need to do anything and all your numbers in all your dashboards are still trending upwards. Until something changes or breaks and you have to get back in the saddle again, of course. Because your robot mower will always need tune-ups and improvements from time to time.

Summary of this article series

This series of four articles has covered an end-to-end change management-based approach to successfully implementing demo automation tools or processes in (a part of) a company. The first article covered why change management is the right “lens” to look at this problem through (namely because we’re asking people to change how they work, because change is hard, and if you can get people to change behaviors at scale, everything else will follow). The second article covered how to prepare an organization for change (the most important but unfortunately also the most boring step), where I covered the importance of creating a sense of urgency, forming a powerful coalition of stakeholders, and creating a strong and compelling vision for change, all while constantly keeping people’s “so what” in mind. The third article covered how, once you’ve built foundations for your change, you can start to execute, leveraging a volunteer army of pilots and evangelists, making success easy for them by removing barriers, and helping them achieve - and socialize - short-term wins to prove the value of your tool or process. Finally, this fourth and final article has covered how to make it “sticky” - how to leverage the momentum you’ve built out to go wall-to-wall and integrate your change into processes - as well as how to evaluate whether you’ve been successful.

By demystifying something that most people find quite challenging, breaking it down into simple, sequential steps, supplementing with personal experiences and examples and even wrapping it all into a nerdy metaphor, I hope I’ve been able to give you some concrete tips and suggested actions for your own demo automation implementation efforts. Now get out there and reach your own Indus!