The Demo: Rules of the Road
A few notes on sales demos.
Over the past years I have done a lot of new product demos, and through that process, I think I have picked up a few potentially useful things. If you run a startup that sells to businesses, or in fact try to sell any kind of innovation, please read on for some perhaps surprising opinions & tips.
Please note that the ‘consumer demo’ as exemplified by Apple product launches is an entirely different field. The consumer demo is mostly outreach and marketing, not an individual sales activity.
So, the business to business sales demo. The first thing to realise is that the need to do a demo is a sign of weakness. Established products don’t need demos. SAP has likely not done an actual demo in a decade. The demo is there to convince the audience that your product is for real and not just slideware. It is compensation for your perceived (product) immaturity.
And the audience is in fact right to be skeptical. Especially in the field of IT, the majority of recent products turn out not to do what you’d think they’d do, or to do it so badly they won’t survive even a 15 minute demo.
Live demos are such a great way to discover a product doesn’t live up to the hype that most established players try extremely hard to never do one. “Too technical, let’s keep this high-level”. Millions are spent on software that no one has ever seen. As of 2016 this is changing somewhat though — customers have become more sceptical, which is good for startups.
So if you are in a competitive situation, make sure your customer forces any established players to do demos as well. They might not want to, they might not do as well as you do, and this is all helpful for you.
The demo as development strategy
In the startup or innovation mindset, the demo is a proud moment. You’ve worked hard on your product, frequently until the very morning of the meeting. This may be because your stuff truly wasn’t ready yet, or because your customer informed you briefly before the demo of several “must have” features that you implemented just for them overnight.
And in fact, demos are just wonderful this way. They spur development and are a great way to improve product market fit — because all the elements are there: a customer willing to show up with articulated needs, coupled with the demo that can provide instant validation of your new features.
I can now safely admit that in my two startups (although PowerDNS no longer is one), I have sometimes created customer demos out of thin air as a way to motivate the team and speed up development. Invite potential customers to look at progress you have made, tell your developers that the potential customers need a bunch of specific new things for the all important demo, and a lovely rush ensues that delivers the very progress you promised. Everyone benefits, even the customer. Sorry (not sorry).
The excitement is for you, not for the customer
But now we get to a difficult point. You need to forget about all that excitement. In a hurry. For you it is a great rush. But NO CUSTOMER EVER wants to feel like you built that stuff just for them! Because remember: the demo is there to prove that your product is real and can be relied on. Code that is still warm from the compiler does not generate that feeling.
In fact, the proper attitude for a sales demo is one of understated pride: “This is what we do. We’ve been doing this for years. It is not a big deal to us”. That does not mean of course that you can’t boast about your great abilities, by all means do that. But compare it to selling a car: definitely tell how powerful the engines and brakes are. Give numbers. But don’t tell your customer that this stuff comes straight from the lab and has never been tested in the field.
In the very early days of PowerDNS, we once worked all through the night to deliver a demo of our new control panel to Ascio in Denmark (hello Nikolaj Nyholm!). We were so proud of how hard we had worked, so we told the down to earth Scandinavians there about it. They informed us that if you have to work through the night, you started too late. Hard to argue with that.
One way you CAN however share that excitement is when it is abundantly clear you are showing roadmap stuff “straight from the lab”. If you are doing a demo of a product or version of your product that isn’t ready to be sold within the next 6 months, go wild, share your enthusiasm. It is a lot of fun. But it is not sales, even though it might be in the future.
The Bob Ross Solution
The temptation for demos is to do an entire product walk-through. An exhaustive display of every screen/panel/whatever of your product. The first problem with this full enumeration is that you simply don’t have time for it. You must focus on the things that are good and that matter.
Secondly, the full walk-through makes it abundantly clear what features you might NOT yet have — since you showed everything that IS there.
And in fact, the way the human mind works, the audience is working very hard to find things wrong with what you are showing them. They will immediately zoom in on the 1% that is missing from your feature set (even if they don’t really care about it that much), and not on the great 99% that you are so proud of.
And the problem with actual large customers with money — a promise to deliver the missing 1% “next week” only confirms their suspicions something is wrong with your company. In their organization, NOTHING gets done in a week!
The solution to this challenge is to act like Bob Ross, the famous TV painter. Place a happy squirrel (feature!) here, a lovely tree there, and it all suggests a great landscape. Even though you in fact did not paint all of that. A few pretty squirrels showcase what you can do, without having to paint each and every tree.
It is the same with demos or product presentations in general. Pick features to show in great detail (areas where you know you will shine and that actually matter) and the audience assumes that the rest is great too. No need to do anything more.
In this way, you don’t let any boring missing bits that your established competition has implemented over the last decade ruin your demo. Show the parts that matter, and only delve into the rest if the audience asks for it.
And if you do pick up that they assume you have features that are not there, implement them quickly so you are ready next time.
There is no excuse
Demos are frequently hindered by small things. “Normally this would run on HTTPS, but the certificate expired, but this in no way takes away from the substance of the demo.” YES IT DOES. Or “I’m hosting this on my laptop in a VM, on a real server it would of course be a lot faster”. The audience may nod. But they will remember sluggish performance. “The data in here is a bit artificial, but it would do the same on real traffic of course”. Probably true. Customer remembers that you didn’t show the real thing though.
“Sorry for all the typos in the slides, I was supposed to work on it over the weekend but had to run errands”. You just told everyone you can’t plan.
I can go on and on. These things are trivial to fix. But sadly, superficial deficiencies DO take away from the substance of the demo! Dedicate time to fix all the small things. It is worth it, even if you show up with one feature less.
Some other notes: assume there is no wifi/ethernet and no power plugs at any demo. Bring your own fully charged computers, bring your own connectivity. And even then, insist loudly and frequently on working internet — your demo is likely to be in that one room without 4G/LTE coverage. I even know people that bring their own projector!
The inevitable error
So this will happen. You click and a full report should appear, but you get an error. You log in and you get three pages of backtrace. On reload it works. You can get away with this exactly once in a demo with the following technique: tell your audience that this proves the demo is for real.
“If this was all fake or slideware you’d never get an error!”. And then share some actually and fully true details on why it went wrong.
But, work hard on making sure this only happens once. Do a full runthrough on the exact setup you will be showing the customer.
Cherish the demo. Use it to speed up development. Observe your potential customers, discover what features they are assuming you have, and make sure that next time you actually have them. Focus on the important features (you only have time for those), don’t accidentally hold a whole session on your weaker points. Fix those “minor” issues that actually do take away from the substance of your demo. And finally, use the inevitable error to prove that your demo was real.