By Peter Cohan

What are the challenges of presenting SaaS (software-as-a-service) offerings vs. “traditional” or “on-premise” software products? SaaS demos present specific opportunities for disaster – several of which are outlined in this latest installment of Stunningly Awful Demos…

It’s the Same, Only Better – Let Me Show You

Many vendors work to differentiate SaaS from traditional offerings, in spite of often positioning SaaS offerings as providing the same functionality as their traditional behind-the-firewall counterparts. Many demos attempt to show these 1:1 comparisons in gory, boring, painful detail – with negative results (including but not limited to):

–Way too long, way too boring, ran into bugs, made the simple look complicated, opened the opportunity for damaging questions, key players left early, and on and on.

It’s Slow Today Because…

How often have you heard this phrase? Customers assume that whatever environment you use for your demos is better than their infrastructure (have you ever heard a customer say, “Our network is blisteringly fast?”). What they see in a demo is the best they typically expect the offering will perform in their own hands.

To add to this, customers are already concerned about performance when operating SaaS products over the web. Demos need to take this rather strongly into account to minimize clicks and other performance-related challenges.

No Plan “B”

And, of course, demos don’t capture screen shots of your key screens so that if you have no Internet connection you are unable to show anything…! God forbid you’d have these stored in PowerPoint or Keynote as a backup plan…

iPhone, iPad, iCloud, iAndroid, iBlackberry, iSmart…

Customers expect to see a broad range of devices supported by SaaS product vendors, including “traditional” PC’s and Macs, iPads and other tablets, and a range of smart phones. New practices need to adjust and reframe demos to address this.

Demos done solely on a laptop may lack sufficient depth of proof for many customers – and emulators are OK, but they miss opportunities to use iPhones and iPads (etc.) as props and to put the product in customers’ hands (changing, wonderfully, the whole demo dynamic).

Getting “Social”

“Social” is an additional challenge for some SaaS demos…Customers may want SaaS offerings to integrate with and/or feed a range of “social” tools (e.g., Twitter, LinkedIn, Facebook, etc.). This adds more complexity in demo preparation and delivery. There is even an entire cadre of “social aggregator” tools designed to help address these efforts, including EventBox, twentyfeet, Flock, friendfeed, youmeo, ping and a pile of others.

Vendors that offer these capabilities are often only too happy to show them in their standard demos – is this a good thing? Perhaps – but only if the customer views them as Specific Capabilities they need to address their problems.

Vendor Vocab

If you want to confuse your customers, try verbalizing a variety of vendor vocabulary terms. Here is a set to draw from, as a start – be sure to add your own company-specific terms and acronyms to further increase the perceived complexity:

– Cloud, cloud-based, in-the-cloud, cloud-burst
– On-premise, traditional, installed, behind-the-firewall
– On-demand, hosted, ASP, multiple-tenant
– SaaS, PaaS, IaaS, AaaS

Ignore F11

Most SaaS software is accessed (and demonstrated) via web browsers. In day-to-day use of browsers, many demonstrators use a range of toolbars (Google, Bing, Favorites, Command Bar, etc.) to provide them with quick access to a range of capabilities. These toolbars, however, consume screen real estate and may confuse audiences. Stunningly Awful SaaS Demos ignore this…

Tapping F11 (in many browsers) hides these toolbars, devoting the maximum possible screen real estate to your application and reducing apparent complexity. Simple and effective!

The Latest (And Greatest)?

One advantage of SaaS offerings is the ability to deliver releases nearly continuously, as opposed to traditional processes of large, comparatively infrequent releases (often followed by “X.01” releases that address problems found with the last large release!).

The corresponding disadvantage for presales and sales teams is staying on top of this release flow. SaaS demos often show the latest, greatest releases and functionality – which increase the risk of encountering bugs, surprise when the “old” workflow has been changed, and confusion when capabilities have changed.

Stunningly Awful SaaS Demos ignore testing the latest release environments or doing a dry-run of the demo ahead of time. Feeling lucky?

Wait – Don’t Buy This Yet!

A dangerous corollary of the above is the knowledge or expectation that capabilities not yet released will be available shortly. How often have you seen a purchase delayed by a misspoken comment or promise along the lines of, “Oh, that capability will be in the March release…” – to which the customer responds, “Terrific, then I’ll hold off buying until March…!”

Mismanaged Migration

What about upgrading existing on-premise customers to SaaS versions?
Many sales teams assume that customers will want to make those migrations right away (and pay for the “added value” of SaaS). Stunningly Awful SaaS Demos occur when it turns out that the customer is perfectly happy with their current on-premise implementation and do not perceive a sufficient driving force to move to the SaaS offering – there is no compelling reason to change.

This is exacerbated when demos delivered after insufficient discovery show that key functionality, in heavy use today by the customer, is not available or is insufficiently implemented in the SaaS version. Ick.

Interestingly (and especially sadly), some of the key capabilities lacking in the new SaaS versions are often amongst the most important for customers – reporting tools and other output capabilities, for example. These are (sadly again) often the last capabilities to be implemented in SaaS release rollout. Double ick.

“Configure, Not Customize”

Have you ever heard this mantra chanted by sales teams? “Our offering is configurable and doesn’t require custom development to implement customer-specific needs.” That’s great.

However, vendors often spend the first 10 minutes of Stunningly Awful SaaS Demos showing the broad range of configuration options – well before getting to the end deliverables desired by the customer. Bear in mind that many (most?) customers configure the offering only once, when it is first implemented!

Hijacked By IT

The demo was going great… and then an IT person asked, “What browsers do you support?” The answer to that question prompted the IT person to follow-up with, “And Java? What level of Java is needed? Flash? CCS? HTTPS? SOAP? REST? Multiple tenant…?”

Instead of “parking” the question for later, the presenter answered each question in detail, getting dragged deeper into a hole and moving farther from the main issues that the key customer players were interested in – and then they left the meeting room…!

Input – But No Outgo?

Many new SaaS offerings focus on the operations a customer can apply to their data or the associated workflows. A typical weakness for newly released SaaS offerings is the lack of sufficient capabilities for reporting or exporting the results.

To paraphrase a terrible old TV commercial, “You can check the data in, but it can’t get out…”

Login Logorrhea

Many customers have concerns about the security of their proprietary information in vendor SaaS applications. Rather than address this as a part of Q&A (where it typically belongs), Stunningly Awful SaaS Demos consume the first few (key) minutes of a demo detailing the login process, security arrangements, and customer data protection provisions.

This is a great approach if the team is presenting to IT (alone), but bores the heck out of business users – and consumes the few minutes that high-level executives are willing to invest in a demo meeting. Unless it has been identified as a key issue by customer management, save it for later in the meeting.

About the Author:

For more on sales demonstration effectiveness skills and methods that help your cause, visit Peter Cohan’s company website at www.SecondDerivative.com. For demo tips, best practices, tools and techniques, join the DemoGurus Community Website at www.DemoGurus.com or explore the  blog at http://greatdemo.blogspot.com/.