Clearly this headline is clickbait, right? Yes, and no. The one thing to remember when you are giving a demo is you’re *probably* not showing a customer or prospect a production system where your solution has actually been implemented. A customer case may serendiptously align itself with the access level you may have to a production system your technology has solved world hunger in; in that case, go for it. Most of the time it just isn’t possible.
Isn’t fake bad?
To answer it simply; no — fake isn’t bad. There are many different ways to go about illustrating how your technology (or solution/skills) can solve a real business problem a customer actually has. Lets quickly though, make one point to the buying audience:
Note to buying audience: it is unrealistic to expect your sales engineer/solution consultant to show you the solution to your exact business problem with a canned marketing demo — on the first meeting.
Marketing vs “The Field” Demos
The fact that there is a “versus” in my section header often means there are two different types of demos that get created. It is not uncommon for technology companies to have PMM’s “Product Marketing Managers” who represent the feature set of the product line they’re responsible for, creating/advocating for demos that highlight features their teams have built — for the marketplace. You’ll find these types of demos at conferences, marketing events, industry keynotes.
The other side of this coin is a group of sales team professionals, affectionately known as, “the field”. Aside from the obvious goal of a sales team — that being to make new customers and increase the adoption of existing customers — the sales team represents the product in the context of the actual business problem an individual customer has. Read that last line back…slowly…remember when I said “problem an individual customer” has? It is in this area where we find the “versus”.
Call them what you will — SE, Sales Engineer, Systems Engineer, Solutions Engineer, Solutions Consultant, etc, et. al, ad nauseam — these folks are the ones doing a different kind of demo. Its often the stuff the PMM’s create is used by the field, but often in a different way.
Example: If a demo scenario designed by a PMM is a soup-to-nuts, walkthrough of a feature set, and it takes 15 minutes, the customer isn’t going to sit idly by wowed like i’m Steve Jobs waiting for the “..one more thing” moment. In reality, a demo isn’t software, its is a very dynamic event with feedback and interruptions.
The SE team makes their own content too! Sales Engineers are on the on-the-ground, first technical interface to your customer. They have a unique ability to empathize with a customer’s techology environment and challenges; as often many of them *were* on the other side of the meeting table, doing the actual job they’re now selling to.
You’ll find the SE’s often are best at creating the “a-ha” moments demos as — to put it plainly — they have to. If an a-ha moment isn’t created by a sales engineer in the demo an opporunity has been missed.
SE’s most often create demos on their laptops, whip up datasets that might mirror customer experiences in the past, and build custom user interfaces to make the product stretch and bend in to the necessary shape of the customer’s need. The best sales engineers will leave the customer with the belief or hope that with this new knowledge, solution or product that they too can achieve great gains.
A Demo is a Performance Event
Sales rep says “Wilde, I need you to give a demo of our $FEATURE_WORD because the customer is asking about this $MARKETING_WORD”. Most sales engineers will (and should) say…wait what? Give me a bit more information, or lets have a discovery/prep call with the customer prior to the meeting.
Yo, customer! I’ll bet you didn’t know your sales teams think this way! In fact, they’re doing you a favor becuause you are not an expert on their product, and the they are not an expert on your business problem. Some prior discussion will help them not waste your time.
Returning from my digression, I do wish there was a better word for the “performance event that is a demo” and the “prop that is the demo”. These two words are used interchangeably in not the best way. “Show me the security demo” vs “We have a demo planned for tomorrow with $CUSTOMER_NAME”.
Determining which props to use in any demo performance event is critical. Have a discovery call with your customer. Let them know you’d like to not waste their time. Determine their interest level, timeline, and the right audience. There’s a chance that out of the discovery call will come more discovery calls where opportunity for your amazing solution to be applicable to more of your customer’s business challenges. Don’t just say “yes, sure! I’ll bring my SE out and she’ll blow your mind”. Save her for the right time. Give her a chance to properly prep and she will blow their minds, but in due time, friend.. in due time.
Keeping it real…fake
Since the customer usually can’t be shown production systems where your solution has been implemented, here are some strategies for making demo content that mirrors production.
- Make a faux-production environment that mirrors reality.
- Capture databases, logs, structures, images
- Generate data and scenarios if you can and play them back to your software/technology
- Store all of your demo code in a source code management system like “Git/Mercurial” (GitHub, Atlassian BitBucket, etc.)
What seems like 100 years ago now, but early on at Splunk we (likely my friend Christina Noren, aka: cfrln)setup a J2EE application environment (a demo that if I recall used MYSQL, BEA Weblogic Application Server and Apache HTTP). This demo came with a “flower shop” dataset. We introduced some failures in to the system, captured the logs and #boom “mirrored reality”. Splunk uses machine data, such as logs and metrics to help customers analyze operational and security issues. Having a real/fake dataset made it so we could create a nice “demo prop” for our field to use during these “demo performance events”.
Below is an example of a video demo I made many years ago (Splunk 4.x era) with a “fake environment”. It uses Microsoft.NET’s old “StockTrader” demo app. Note: there is one specific Splunk feature I show “fschange” which has been deprecated.
If your software/solution can allow for fake/generated data, you are on your way to providing your own a-ha moments — and even perhaps a whole pile of YouTube videos.
Saving and finding all of the things!
In a forthcoming post I’ll get in to a discussion of cataloguing demos, extracting metadata from them, using a “YAML” formatted file (demo.yaml) as method to do such a thing — all with the goal of helping Sales Engineers find the right props to use to educate the customer in an efficient manner.
Disclaimer: these are my own personal opinions and do not necessarily reflect that of any current (SPLK) or future employer.