Long one of the staples of outbound marketing in the technology industry, it’s nevertheless striking how little thought often goes into a product demo. It’s understood that you need to have a demo, but who – precisely – it’s for and what you’re specifically trying to accomplish are afterthoughts, if they’re thought of at all. For anyone that has spent time in this industry, it’s shouldn’t be hard to come up with examples of underwhelming, interminable demos that are dry recitations of features rather than a purposeful subset married to a narrative.
Over the years at RedMonk, we’ve seen a great many demos, and while there is no one-size-fits-all approach to them, there are a few patterns worth discussing in demos that tend to perform well with developer populations. Having had this conversation a half a dozen times over the past week, it seemed worth sharing a few suggestions for Do’s and Don’ts if the intended target for your demo is a practitioner (i.e. developer, DBA, ops/sysadmin, etc). If you have other suggestions, drop them in the comments.
- Do Make it Quick / Don’t Try and Show Off Every Last Feature:
One of the biggest mistakes vendors tend to make is that they feel compelled to talk about literally the entire product. First, this makes the demo long and, probably, boring. Second, there are only so many features that can be absorbed from a demo, so by definition showing more than a minimal subset is wasting time because it’s information that can’t be retained. Last, it takes away some of the joy of discovery developers have in terms of playing around with a new tool.The most successful demos instead tend to be those that are focused on a particular feature or capability, and ideally have an accompanying narrative. Instead of shotgun-style “here are fifty features” demos, demonstrating a particular capability – ideally with accompanying source code – in simple, easy to follow steps (i.e. not like this) shows off the feature you believe is most important in a digestible fashion. We’re always asked for examples, and while it’s not a live demo, no one embodies this concept better than Twilio’s quickstart documents.
Or, to use a more basic example, there’s a reason Apple’s iPhone ads focus on the movie you can make rather than running through the characteristics of the underlying hardware platform.
-
Do Make the Demo Useful / Don’t Be Too Academic:
Another common mistake is demoing something that is academically interesting but practically useless. Depending on the product, this may be difficult or impossible to avoid, but wherever possible, demos whose output is something that is practically useful are much more impactful than those that are one and done proof points.Developers that walk away with from your demo excited to build something that is practically useful have a much greater chance of actually engaging with the project or product, and therefore are that much more likely to become regular users or customers. This is also true for interviews, incidentally. But how do you construct a useful demo?
-
Do Make it Individually Relevant / Don’t Make it Organizationally Focused:
Most of us in this industry have been in demos that are focused on an organization – “by using this product organizational productivity goes up 55% and risk goes down by 33%” or similar. While these are, as above, necessary and unavoidable for some product segments, wherever possible having a demo that’s focused on the individual rather than their employer will be much more effective.For example, which demo is more likely to get you to play with Watson: using the tool to help customers make correct purchases, or how you could use it to tune out of conference calls? You need that first demo for customers in those markets, clearly, but if your specific goal is to reach developers the latter is much more likely to be interesting enough to get them to kick the tires.
These are basic rules, of course, and there will be many exceptions where one or all don’t apply. But as Picasso said, “Learn the rules like a pro, so you can break them like an artist.”
