One Great Demo! Workshop participant recently noted that he sets up a web session for his discovery calls. In addition to having the session open and available for any discovery needs (e.g., Menu Approach, Workflow Analysis, etc.) this is a subtle way to test the technology before any demo is scheduled. Very clever!
Tips, thoughts, tools, techniques and practices to increase success rates with software demonstrations
Tuesday, June 28, 2011
Testing Web Collaboration Tools – While Doing Discovery
Many sales teams find that their customers are (still) unfamiliar with web collaboration tools (e.g., WebEx, GoToMeeting) or have not tested the tool before a scheduled vendor demo – resulting in fumbling, lost time and (sometimes) having to reschedule demos. In addition to the several other ideas already offered in this forum, here’s another (very clever) one:
Monday, June 13, 2011
Remote Demos – Who’s There?
Consider typing the names of the audience members on the screen (use a white board, PPT, or Word document). This confirms who is actually present, engages the audience and gives you an accurate list as well – audience members will often correct any spelling errors for you!
Friday, June 10, 2011
Product Overview Presentations - Like Having a Brochure Read to You
Many demos are preceded by 1) a corporate overview presentation and/or 2) a product overview presentation. Leaving the horrors of typical corporate overviews aside for the moment, it just struck me that watching many product overview presentations feel a lot like having someone read a product brochure you… A recent product presentation I watched took over 30 minutes (before the demo) and reviewed the company history and mission statement (again, even after it was introduced in a corporate overview presentation!), then walked through the history of the problem/shortcomings of the existing technology, technology Bottlenecks, the product technology itself (how it works) including details of architecture and environment, typical numeric results, security, integration options (SDK and API’s) and finally deployment.
The customer was quiet throughout the entire 30 minutes – no interaction. It struck me that this was like having the product brochure being read to us!
Monday, June 6, 2011
Stunningly Awful SaaS Demos – Lost in the Clouds
What are the challenges of presenting SaaS offerings vs. “traditional” or “on-premise” software products? SaaS demos present specific opportunities for disaster – several of which are outlined in this 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):
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.
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.
- SaaS, PaaS, IaaS, AaaS
Ignore F11
“Configure, Not Customize”
Login Logorrhea
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, 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.
[Some of the names of these tools are really fascinating, for example: Twitter Tools, Twhirl, TweetBeep, TwitBin, Twidget, TwitterBerry, and Twittalator Pro. Gad!]
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…!
Thursday, June 2, 2011
Interesting (Good) Examples of Online Demos
The folks at Spotfire (Tibco) have created an interesting set of online demos at http://spotfire.tibco.com/demo/default.aspx worth exploring. Typical online demos often try a one-size-fits-all strategy, which fails in many situations (since we aren’t one-size-fits-all customers). Spotfire has created a flock of example demos (~60) for a range of industries and application areas, endeavoring to enable customers to focus on reasonably specific topics and challenges.
Further, the demos are not canned recordings, but are live (bounded) versions of the offerings, enabling customers to dynamically explore the demos and associated capabilities. There is, of course, some risk in this – that customers will not figure out how to navigate through the demos, but the use of some text descriptions (along with brave clicking on the customer’s part) largely addresses this issue.
Overall, an excellent job in providing appetizer-level examples of Spotfire’s capabilities – and potentially a great template of an approach for others.
Subscribe to:
Posts (Atom)