 |
| Photo Courtesy: https://www.youtube.com/watch?v=vJvp1TCcCgg |
"I went down to the demonstration / To get my fair share of abuse" - The Rolling Stones
A software demonstration (“demo”) is an early step in the sales process, and (in a full RFP procurement) also one of the last. The intent of the demo is to show the customer what the software can do and how easy it is to use. It’s not training, but it goes deeper than some screen shots.
As a City IT Director, I watch a lot of software demos. Not all of them are good. In the interest of improving the process for all of us, here is advice for those who give them.*
* If you want guidance on watching demos, please see my earlier piece “Let’s Make Software Demos Meaningful.” That blog also talks about my own experience performing demos, which is how I learned many of these lessons.
*********************************************************************
Disclaimer: All of the ideas expressed in this article are my personal statements and opinions, and do not reflect the opinions/statements of the City of Urbana.
*********************************************************************
Start With a Quick Process, Then Go Back and Layer on Details
A common demo mistake is to open the first screen... and then talk for 10 minutes about the various options and features. Bor-ing! It’s better to immediately go through a simple scenario and say “see how easy that was? It took me less than a minute to get my entry done.”
Once you’ve shown a basic entry, you can go back and do it again with more features. (Pro tip: Go back and enhance your first entry, so that the second time can focus on the next layer.)
Show, don’t Tell
Or: “Move the mouse more than you move your mouth.” A demo goes off the rails when the demonstrator points out things on the screen and talks about what they do. When that happens, I think… if you’re not showing it, what are you hiding?
Keep the demo moving. Unless you’re answering a question, don’t stop showing the software.
Let the Demo Tell a Story
When people use software in real life, there’s a business process occurring. One or more people are moving a task from point A to point B. There’s an opportunity here for storytelling.
If it’s a one-person task, then play that role. Understand the real-life situation of your customers and be that person. (“My boss asked me to do this crazy-hard task, with a deadline in 15 minutes! Fortunately, I use xxxx software so…”)
When the business process has multiple people, your demo should include changing users to be different people. For example, if a manager needs to approve something, show how they get a message (email? text?) then sign in and further the process along. BONUS: This is also a chance to show that customization makes the views/dashboards/home page look different for various users.
The best example of this I ever saw was Susan Capstack Beal, who literally put on different hats (cowboy hat, green eye shade, etc.) to play roles for a big demo back in the 2000s. You don’t have to go that far, but the audience loved it!
It’s Not Training
This is a trap that snares people who are incredibly knowledgeable about the software and can’t help sharing their knowledge. Usually this comes out as too much talking (see “Show, don’t Tell”), but it could also manifest as the person diving the demo deep down a rabbit hole of features and losing the narrative.
The problem is that an exhaustive demo is… exhausting. Audiences might learn a lot, but they’re not ready to receive this much detail during the sales process (your software might be one of four they’re reviewing this week) and too much information can leave the impression that the software is complicated. The time for training comes later; keep the demo simple. [One note to clarify: it’s OK to dive down in detail to answer a question and show a key feature that connects with the audience’s need. What I’m against is burrowing down without being asked!]
Be a Limited User – NOT an Administrator
Software that’s used by multiple people often has user roles. In real life, most users have limited access and can only see some of the system components and data, while the “Administrator” role usually sees all data and all actions. For convenience, programmers and other software company workers generally use Administrator roles. (Although testers should not!!)
Here’s a rule: the only time a demonstrator should be logged in as an Administrator is when they’re demonstrating how a Systems Admin does THEIR job. Every other time, the demonstrator should use a limited role, like a normal user.
Demonstrating as a limited user has many benefits:
- You can hide many fields & functions, making screens look simpler.
- You can mask/hide data the user shouldn’t see (employee SSNs…) to demonstrate security features by showing them in effect.
- If you do sign in as the Administrator to play that role, people can immediately see the additional Systems Admin functions.
Use Realistic Data (Better… Use the Audience’s Data)
The demo’s goal is to get the audience to imagine themselves doing their job <more easily> in the new software. Having garbage/test data makes it harder for the audience to connect with the software. When Mickey Mouse and Donald Duck are the names they see, the software looks childish.
Instead, take the time to set up realistic data. Need names? The Internet’s got lots of them. (Back in the old days, we had to use the phone book!) If you demonstrate to city governments, pick one – we’re all pretty similar - and accurately set up their structure. And keep up the effort: if your system is year-based (like financial data by fiscal year) don’t show data that is two years in the past.
Want your demo to really shine? Tweak the data for each audience. It doesn’t take much work, but it shows extra effort. Sure, lots of people grab our City logo for their demo, but very few take the time to use our information. A true story: we looked at software for public meeting agendas and one demo person looked on our website and used the real dates of Council meetings. Just a few minutes of pre-demo effort but the result was instant rapport.
An important sub-rule here: there should be a demo environment of the software, one that isn’t used for testing or development, so demo people can control the data. Come up with good examples (ideally: scenarios prior demo audiences asked about) and build them out. Make the process you’re showing look as much like it will in real-life.
Practice, but Clean Up After Yourself
Look closely during many demos and you’ll see lots of records just like the one you’re seeing but with different dates. This shows that the demo people use the same examples all the time. It’s not a problem – in fact, the demo person should have a script – but it’s another way that demo environments look unrealistic.
When I gave demos, the system was financial software – so there were many possible ways for entries to get errors: insufficient budget, inactive codes, effective dates, etc. Trust me: there is nothing worse for a demo person than an unexpected error that stops your demo cold. There you stand (on Zoom: there you stare…) trying to figure out what went wrong in front of everyone. I heard once that “A good demo won’t win a sale, but a bad demo can lose one” – and I think there’s a lot of truth there.
Here’s the method I used to practice, but still have good looking data. This assumes that the demo team has its own demo environment:
1. Script your demo and set up quality reference data.
2. Backup your demo database.
3. Walk through the script, practicing and revising the script.
4. Restore the demo database from the backup.
5. Repeat steps 3 and 4.
If you need to add to the database: restore it, make updates, and take a new backup.
Now you can practice and before each demo it’s ALWAYS the
same. It doesn’t get full of junk or redundant data and it’s going to work the
same way every time – just watch out for those effective dates! Doing a live demo
is always a high-wire act, but you’ll have a lot more confidence knowing that your
script works.
**********************************************************************
About the picture and lyric…
Even the picture of the Shamwow Guy is ACTIVE, like demos should be, and it reminds us that all demonstrators are hucksters. ; )
Watching that video (see below), I am wowed by demo of the product in action… seriously: I need one of those! The demo Starts Quickly with a wipe-up then Layers on Details like soaking up the bowl. It Tells a Story (of spilled cola) and Shows more than it Tells. Software demonstrators WISH they had a product this simple to demonstrate. As a demonstrator, he’s got energy but you sense the repetitions in his performance. Even if it’s the hundredth time you’re doing a demo, it’s the viewer’s first.
Careful watchers can see they also take advantage of the “Julia Child” method of demonstrating, when you show how to make the turkey first… then pull a fully baked one out of the oven to save time - or to hide extra steps! Note at 34 seconds when you get a wipe effect (*ahem* an edit) and we’re not necessarily looking at the same sopping wet rug that he just poured cola on.
About the song: I can’t help it; “You Can’t Always Get What You Want” is my favorite Stones song. As much as I love the album version, the one below from 2020 is pretty awesome, too.