I’ve done a reasonable amount of public speaking in my career but until this year’s Adobe MAX conference, where I appeared onstage during the keynote to present the official release of Adobe XD 1.0, I had never given a public software demo before. It’s true that a demo is not entirely dissimilar from giving a talk or lecture—many of the same presentation skills apply to both—but I discovered that in many ways demos are an entirely different kind of beast. So I thought I would write up some of my personal observations on the whole experience for those who are curious or who might one day have an opportunity to do something similar.
Like many folks working in tech I’ve demoed software countless times in the past but almost always in private settings—for colleagues, customers, investors, or to small groups of users. What makes an occasion like the Adobe MAX keynote unlike those prior experiences is its scale. There were 11,000 attendees in the Las Vegas auditorium where it was held, plus an overflow room and untold more viewers of the live stream.
A live audience of that size demands that even a short, ten-minute demo like the one I gave needs to become something that barely resembles the “real life” version of itself that it’s meant to represent. Most people use software alone in an almost improvised manner—whatever it takes to get the job done—and almost never talk about their actions aloud. A keynote demo upends that solitary activity and transforms it into a public performance that’s heavily rehearsed and narrated live, in real time.
“A keynote demo turns a solitary activity into a public performance.”
In fact the central thing I learned about these kinds of demos is that they require exhaustive practice. In the two months leading up to the MAX conference, I flew out to San Francisco every single week, leaving New York on Monday and returning on Thursday or Friday, all to rehearse my ten minute demo again and again and again. In San Francisco, I’d spend nearly all day, every day practicing with the keynote’s production team and with the other keynote presenters. When I wasn’t officially in rehearsals, I was often running through my part on my own, usually in my hotel room but occasionally muttering it aloud walking around the Adobe offices. It was an all-consuming process.
You might be thinking to yourself, “That’s excessive,” which is an understandable reaction. But what I also learned is how absolutely necessary all that time was in developing the story of what I was going to be demoing. Even though there was relatively little debate about the aspects of Adobe XD that I would be presenting onstage, the actual narrative of those features really had to be developed through iterative, organic evolution. The version of the demo that I first began rehearsing back in late August was very different from the version that ended up onstage in mid-October, and it changed countless times in between.
Each of those many run-throughs was more than just a matter of learning or memorizing the content. The real value in doing it over and over, a dozen or two times a day, is that it allows you to make an endless number of incremental tweaks along the way—adding or subtracting a word or phrase here or there, trying out different sequences and emphases, learning how to communicate the message a tiny bit more clearly or succinctly.
There’s also the added complexity of the assets, or the sample design file, that forms the heart of the demo. Having a great looking project with which to show off an app’s capabilities makes all the difference. For various reasons, the sample file we started with had to be discarded, and so I spent a lot of time with one of our designers creating something entirely new, from scratch. He’s based in Germany which is five hours ahead of New York and eight hours ahead of San Francisco, which of course exacerbated the interminable jet lag that I was aready experiencing from all my back-and-forth travel. It was a very strange period of my life.
“Having a great looking project to demo makes all the difference.”
Choreography too is a part of this preparation. Not as in footwork (though I did have to practice the actual route I took as I walked up to the podium) but rather the choreography of what happens on screen. It was much trickier than I had anticipated to synchronize the words that I spoke with the motions of the cursor so that neither came too early nor too late. It got to the point where, by the end of the process, I was moving my mouse and clicking on buttons almost precisely along the same path and with the nearly exactly the same timing on each run through.
All that said, a lot of all that preparatory time was frankly devoted to just getting me used to the concept of demoing. How one figures out the tricky balance between telling the audience and showing the audience is kind of a personal journey. Demoing is neither clearly the former nor the latter, and getting comfortable with that ambiguity just takes time, practice and some measure of self reflection, too. You need to get right with whatever personal ambitions you have for how you want to come across on stage, and to reconcile that with whatever the goals of the demo are and with the feedback that comes from the rehearsal process. It was only through lots of trial and error and many periods of wondering whether I was even tempermentally suited for it at all that I was finally able to figure out “how to demo.” I’m sure there are people for whom this comes naturally but for me, I had to learn it the hard way.
“Don’t disregard the outside possibility of totally random chaos too.”
Finally, don’t disregard the outside possibility of totally random chaos, too. You can prepare all you want, but there’s always the chance that something completely unexpected could entirely derail the actual demo once you go on stage. And, of course, that happened to me.
After all that rehearsal and practice, after internalizing every movement and detail of the setup of my screen, I walked on stage ready to do my thing and what happens? My trackpad died. It just wouldn’t work, stopping my demo cold in its tracks while a member of the stage crew had to rush another one out for me. You can see it in the video I posted above—not more than a minute into it, everything breaks down. People tell me that I managed to hold it together, but sometimes panic manages to disguise itself as composure.
It’s worth repeating that the inherent tension of a keynote demo is that it takes something you normally do alone—use software—and turns it into a highly public performance. You’re looking down at your keyboard and device most of the time but you’re also trying to augment every click and every word you utter to draw the live audience into it.
And even though every mouse movement is projected at huge scale for the audience to see, you still need to use carefully chosen commentary, expressive body language and judicious pacing to form a narrative, to give it all shape and purpose. The whole thing is both highly staged and strangely improvisational; it’s exacting and methodical yet it’s meant to come across as breezy and casual. It’s a monologue in that only the presenter is talking during those ten minutes, but it’s also a conversation with the audience in that anyone watching is going to be silently asking questions that should be answered in short order by what’s demonstrated on stage. It’s one of the weirdest things I’ve ever been through but it was also a lot of fun.
+