How to scale sales enablement with demo automation

Infrastructure as Code is becoming more common in modern IT organizations. DevOps teams use tools like Terraform or Ansible to build cloud resources and virtual machines. Demo and training environments, on the other hand, are almost always built manually. Why is that? In this post, we'll explore the evolution of a demo environment and some ways to automate them.

A Demo Framework Story

Our imaginary tale begins with a software company called Initech. Initech provides accounting software for large enterprise organizations. They have a small sales team consisting of Alice, enterprise account manager, Bob, Alice's manager, and Kira, sales engineer. Peter, Michael and Samir are developers who create and manage the application.

Salespeople Gonna Sell

Alice: Hey Kira, I scheduled a sales demo for tomorrow morning at 8am. Sorry about the short notice, but this is the only time the prospect was free.Kira: Uh...I don't really have anything prepared. Normally we do some requirements gathering first...Alice: Oh, I'm not worried. You just work your magic and sprinkle some of that special Kira DevOps dust on it.Kira: Um...ok.

Necessity is the Mother of Invention

Kira closes the chat window and accepts her fate. She will have to build a demo environment because the company doesn't have one yet, and the devs are too busy fixing bugs to work on this. As a former developer, Kira knows how to write Code, and she's installed and set up the Initech software a few times. She goes to work building the first iteration of what we will call the "demo framework".The demo framework consists of a bunch of virtual machines that Kira runs from her laptop. The whole thing is built by hand, but that's ok because Kira is the only SE on the team. She doesn't have a whole lot of time to invest in building the demo environment, so she cuts some corners to get it done before the next day's meetings. The sales demo with Alice goes great, and Alice says, "You're a wizard, Kira."(Fast forward 12 months)

Growing Pains and Technical Debt

Initech has grown, and now there are eight sales reps and four sales engineers. The developers are as busy as ever creating new features and fixing bugs. The SE team shares the original demo that Kira built. The demo framework now runs in a shared account on AWS. It's not perfect, it has some rough edges, and the data is over a year old, but at least it works. Nobody really has time to fix the issues with the demo framework anyway. The team knows that it will have to be rewritten from scratch, but they just keep kicking that can down the road...

The Demo Environment Breaking Point

The SE team has now grown to 25, and the demo environments are in desperate need of an upgrade. There are known bugs, and the process for standing up a new demo environment is not easy to understand. New employees have to spend several weeks absorbing the tribal knowledge and trying not to run out of resources in their shared cloud account.Then one day, Kira's coworker Anthony accidentally copies his secret keys to the demo Git repository. Immediately a cryptocurrency mining bot picks them up and takes over the team's shared demo account. Within minutes hundreds of instances are created to mine cryptocurrency. The account is flagged for abuse, and AWS shuts the entire account down, taking the entire demo framework with it. The team of 25 SEs are completely out of luck and unable to do any demos or training without their shared AWS account.

Rising from the Ashes

After a painful week of rebuilding the AWS account, the team decides to rewrite the demo framework from scratch, using Infrastructure as Code. Every component of the demo, from the low-level infrastructure all the way up to the sample data in the application, is required to be stored in a version control system, and any changes to the demo must be added to the code repo and approved by a team member.It's hard work but, after a few weeks, the team begins to see some progress. New features are easier to add to the demo, and there's no longer a need for long-running instances. The new demo can be stood up in less than ten minutes, and it's well documented and tested.Kira and her team celebrate the launch of the new demo environment with an outing to the local video game arcade.Did this story seem familiar? Most organizations go through similar growing pains trying to standardize their demos and training environments. The question is — why don't we build these things the right way the first time? Why are demo environments created as an afterthought instead of built into the plan for the product?

Unique Requirements of Demo Environments

Here are a few of the factors that cause busy SE teams to take shortcuts when building demo environments:

Short on Time

The limit on time is probably the #1 reason sales engineers build things manually. Good automation takes time to build and test. SEs often don't have enough time to do things right, so instead, they take the fastest and easiest path to building a demo which is to create it by hand and then take a snapshot of what they built. While this works in the short term, it doesn't scale well as we learned from Initech and Kira's growing SE team.

Little or No Budget

Another reason demo environments don't get the attention they deserve is because of a lack of budget. Most companies do not set aside funds or human resources for demo environments. The general assumption is that the software is already built, so why can't we just demo with a copy of our dev environment? The burden of building the demo framework falls upon the SE team, who are already busy tagging along with their sales reps who need a technical resource on most calls.

Tells a Compelling Story

A great demo is not just about showing off a list of features. Presales engineers understand that there needs to be a compelling narrative around the demo that shows some useful outcomes. Simply going through a list of technical features is not sufficient. They need a story to go along with the technical features and benefits so the prospect can relate what they have seen to their own challenges.

A Model House or Movie Set

The technology demo doesn't need to work exactly like production, but it should at least look like a production environment. Real estate agents understand that a furnished home is easier to sell than a bunch of empty rooms. People like to see what a house might look like if they lived in it. The same goes for movie sets — the movie set needs to look like the real thing, even if it's just a facade of an old western ghost town.This presents a challenge for the demo developer because not only do they have to build a convincing environment, they also have to pre-populate it with data, so it looks "lived in", just like that house for sale. A fully automated demo environment may need some mock data that can be imported during setup to make it feel like a real environment.

Always Ready Environments

Busy sales engineers do not want to spend an hour setting up their demos. Ideally, the technology demo should be stood up and ready to go in less than ten minutes. This is much harder to achieve than simply creating a long-running shared environment that is never reset. One of the primary benefits of using on-demand demo environments is that they are easy to change. Adding new features is as simple as adding some lines of Code to a file instead of having to recreate an entire virtual machine image by hand.

Shows a Real Installation

At some point, the prospect will say "show me" and want to see the real thing in action. Slides and videos only go so far. SEs need to have a working copy of the software where they can show the prospect how the software might work in their own environment.

The Long Term Solution

The lesson here is simple - try to build it right the first time. The following helpful requirements checklist can guide your decisions as you create or upgrade your own demo framework:

• The demo environment is created from scratch, automating as much as possible with infrastructure as code.
• Demo environments should be created in ten minutes or less.
• You have an automated process in place for tearing down expired demo environments.
• All changes to the demo framework go through a review and change request process.
• The demo is documented, tested, and given the same treatment as your application code.
• A clear talk track is stored in a repository along with the demo and sample videos for other users to use for learning purposes.
• All your users learn and certify themselves on the standard demo process, even if they build their own custom demos on the side.