A colleague recent sent me Cheat-Sheets for PowerPoint and other Microsoft Office products (actually called “Quick Reference Cards” – but Cheat-Sheet is much more fun). I note that the Slide Delivery Shortcuts can be particularly useful and included some that were new to me:
Slide Show Delivery
End Slide Show "Esc"
Jump to Slide "Slide #" + "Enter"
Toggle Screen Black "B"
Toggle Screen White "W"
Pause Show "S"
Show/Hide Pointer "A"
Change Arrow to Pen "Ctrl" + "P"
Change Pen to Arrow "Ctrl" + "A"
Erase Doodles "E" [“Doodles” are ad hoc markings]
Send me an email (PCohan@SecondDerivative.com) if you’d like to receive the full Cheat-Sheet for PowerPoint or the full set for MS Office.
Friday, March 26, 2010
Tuesday, March 23, 2010
Remote Demos – Enabling the Audience to Catch-up
Here's a simple tactic to enable an audience to "catch-up" with what you are showing on your screen, particularly when dealig with relatively slow connections: Stop and then restart screen sharing. This effectively reloads the audience session.
This tactic can be particularly useful if you have been sharing screens with a large amount of images or scrolling graphics that require sending a lot of data to the audience machines. Works nicely!
This tactic can be particularly useful if you have been sharing screens with a large amount of images or scrolling graphics that require sending a lot of data to the audience machines. Works nicely!
Thursday, March 18, 2010
Brain Rules - Absolutely Required Reading For Sales, Presales and Marketing People
This book doesn’t appear to be about business, necessarily, but – it definitely is!
Brain Rules provides both the explanation and, more important, clear guidance on how to help you enable your customers to remember the material you present in demos (and via other communications vehicles as well).
Particularly useful and interesting are the following chapters:
- Rule #4: We don’t pay attention to boring things (attention)
- Rule #5: Repeat to remember (short-term memory)
- Rule #6: Remember to repeat (long-term memory)
- Rule #10: Vision trumps all other senses (vision)
I feel as though I’ve slowly (over a period of many years!) been discovering many of the principles that the author presents in the book. A colleague of mine wisely commented that “An hour of research is worth a year in the lab” – but, of course, he’s a cynic.
Summary? Read it. Here’s information on the book:
Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School, John Medina, Pear Press, Reprint edition (March 10, 2009), ISBN-10: 0979777747, ISBN-13: 978-0979777745.
Brain Rules provides both the explanation and, more important, clear guidance on how to help you enable your customers to remember the material you present in demos (and via other communications vehicles as well).
Particularly useful and interesting are the following chapters:
- Rule #4: We don’t pay attention to boring things (attention)
- Rule #5: Repeat to remember (short-term memory)
- Rule #6: Remember to repeat (long-term memory)
- Rule #10: Vision trumps all other senses (vision)
I feel as though I’ve slowly (over a period of many years!) been discovering many of the principles that the author presents in the book. A colleague of mine wisely commented that “An hour of research is worth a year in the lab” – but, of course, he’s a cynic.
Summary? Read it. Here’s information on the book:
Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School, John Medina, Pear Press, Reprint edition (March 10, 2009), ISBN-10: 0979777747, ISBN-13: 978-0979777745.
Thursday, March 11, 2010
The Demo Route That Shouldn’t Be Traveled
Imagine you want to drive to the store to pick up a few things for dinner – a trip that normally should take 10 minutes one way. You get into your car, leave your driveway and proceed down the street. Your car is equipped with a very intelligent voice-controlled GPS, however, which decides that there are other options you should see on the way.
The GPS takes control and turns off from the direct route to show you an interesting restaurant it thinks you might want to try sometime in the future. You thank the GPS, and ask it to return to the original course. It does so.
A few blocks later, it once again changes direction and drives 5 minutes to show you a nice park. “Terrific…” you say, “but please return to the original course.” The GPS sighs quietly, but obediently returns to the original route once again.
After a moment of quiet, the GPS makes a left turn and proceeds 8 minutes to a new home-products and hardware store. It announces proudly that the store just opened recently and is a great option for everything from paint to plumbing. Annoyed, you tell the GPS “Please return to course!” It does so, after grumbling that you really should see all of the cool options it knows about…
At this point you disable the GPS and proceed directly to the store – dinner will be late!
What if demos were delivered in the same manner? This pathway of driving off course to show potentially appealing options is truly an example of Sales Prevention at work.
A solution? Just “Do It”. Take the direct path from a logical starting point to completing the task. Avoid the urge to take those turns off course.
The GPS takes control and turns off from the direct route to show you an interesting restaurant it thinks you might want to try sometime in the future. You thank the GPS, and ask it to return to the original course. It does so.
A few blocks later, it once again changes direction and drives 5 minutes to show you a nice park. “Terrific…” you say, “but please return to the original course.” The GPS sighs quietly, but obediently returns to the original route once again.
After a moment of quiet, the GPS makes a left turn and proceeds 8 minutes to a new home-products and hardware store. It announces proudly that the store just opened recently and is a great option for everything from paint to plumbing. Annoyed, you tell the GPS “Please return to course!” It does so, after grumbling that you really should see all of the cool options it knows about…
At this point you disable the GPS and proceed directly to the store – dinner will be late!
What if demos were delivered in the same manner? This pathway of driving off course to show potentially appealing options is truly an example of Sales Prevention at work.
A solution? Just “Do It”. Take the direct path from a logical starting point to completing the task. Avoid the urge to take those turns off course.
Monday, March 8, 2010
A Date Nit
Given that the purpose of software demonstrations is to (1) build a vision of a solution or (2) show proof, everything we do in a demo needs to support these objectives. In demos we are working to “suspend disbelief” in our customer audience – in other words, we need to make the demo appear to be as close as possible to real life. Anything we do or show that is obviously fake hurts our cause.
Two examples of making a demo obviously appear to be fake are:
- The use of silly or obviously fictional names (e.g., “Mary Manager”, “Dave Departmenthead”, “Sarah Superuser”).
- Naming files or processes “demo” or “test”.
To these I add a third, slightly less obvious item:
- Dates and date ranges.
I was watching a demo recently and noted that all of the reports that were run and presented showed data from 1998 and 1999. This automatically makes one wonder about the software: Has it been updated since then? Are their QA test suites that old? Have they tried the system with current data?
The old data also impacted my attention. Instead of listening and watching the next steps in the demo, I found myself wondering and thinking about data from 1998…
The morals are clear: Use real-life names (people, files and processes) and use dates that are contextually relevant for the customer’s situation.
Two examples of making a demo obviously appear to be fake are:
- The use of silly or obviously fictional names (e.g., “Mary Manager”, “Dave Departmenthead”, “Sarah Superuser”).
- Naming files or processes “demo” or “test”.
To these I add a third, slightly less obvious item:
- Dates and date ranges.
I was watching a demo recently and noted that all of the reports that were run and presented showed data from 1998 and 1999. This automatically makes one wonder about the software: Has it been updated since then? Are their QA test suites that old? Have they tried the system with current data?
The old data also impacted my attention. Instead of listening and watching the next steps in the demo, I found myself wondering and thinking about data from 1998…
The morals are clear: Use real-life names (people, files and processes) and use dates that are contextually relevant for the customer’s situation.
Wednesday, March 3, 2010
Cognitive Dissonance in Demos
How does cognitive dissonance apply to delivering demos? Cognitive dissonance can be defined as an uncomfortable feeling caused by holding two contradictory ideas simultaneously in mind. Cognitive dissonance occurs when a person perceives a logical inconsistency with his/her thoughts.
This happens when one idea implies the opposite of another. In movies, a great example is when a man and woman initially despise each other, but then fall in love (grudgingly at first, of course!).
Does cognitive dissonance occur with software demos? Yes and no. [Sorry, couldn’t resist the example!] It certainly happens when the vendor says, “Easy to use…” but the demo shows the offering as complex and confusing, from the customer’s perspective.
Equally importantly, cognitive dissonance may occur within the vendor’s team – particularly in discussions between sales and presales players, both before and after the demo:
- “Have we done sufficient qualification and discovery?” “ Yes, but… we don’t really know what they need.”
- “Did we address the customer’s key needs?” “Yes, but… we did the same demo we always do.”
- “Did we achieve our objective for the demo?” “Yes, but… the customer didn’t ask very many questions during the demo – and they didn’t say what their next steps are.”
What do we, as the vendor, remember from a demo vs. what the customer remembers – or what we think the customer remembers?
Interestingly, our first impressions of the relative success of a demo are sometimes the harshest. As a few hours pass, or several days, our memory of the demo tends to slant more towards the positive. [The effect intensifies with the number of beers/drinks at the airport bar, not surprisingly…] This suggests that demo teams should debrief and capture, in writing, their impressions of the demo meeting as soon after the meeting as possible:
- What went well?
- What could have done better/differently?
- What expected/unexpected problems appeared?
- What did the customer say? What didn’t they say?
- What action items/follow-up did we promise? Did they promise?
Most people’s brains work to resolve cognitive dissonance, tending towards a filtered set of perceptions. Those perceptions often mask or causatively ignore the initially dissonant items – resulting in over-positive final impressions, inflated forecasts, and shock when the deals don’t close!
This happens when one idea implies the opposite of another. In movies, a great example is when a man and woman initially despise each other, but then fall in love (grudgingly at first, of course!).
Does cognitive dissonance occur with software demos? Yes and no. [Sorry, couldn’t resist the example!] It certainly happens when the vendor says, “Easy to use…” but the demo shows the offering as complex and confusing, from the customer’s perspective.
Equally importantly, cognitive dissonance may occur within the vendor’s team – particularly in discussions between sales and presales players, both before and after the demo:
- “Have we done sufficient qualification and discovery?” “ Yes, but… we don’t really know what they need.”
- “Did we address the customer’s key needs?” “Yes, but… we did the same demo we always do.”
- “Did we achieve our objective for the demo?” “Yes, but… the customer didn’t ask very many questions during the demo – and they didn’t say what their next steps are.”
What do we, as the vendor, remember from a demo vs. what the customer remembers – or what we think the customer remembers?
Interestingly, our first impressions of the relative success of a demo are sometimes the harshest. As a few hours pass, or several days, our memory of the demo tends to slant more towards the positive. [The effect intensifies with the number of beers/drinks at the airport bar, not surprisingly…] This suggests that demo teams should debrief and capture, in writing, their impressions of the demo meeting as soon after the meeting as possible:
- What went well?
- What could have done better/differently?
- What expected/unexpected problems appeared?
- What did the customer say? What didn’t they say?
- What action items/follow-up did we promise? Did they promise?
Most people’s brains work to resolve cognitive dissonance, tending towards a filtered set of perceptions. Those perceptions often mask or causatively ignore the initially dissonant items – resulting in over-positive final impressions, inflated forecasts, and shock when the deals don’t close!
Subscribe to:
Posts (Atom)