OK, you sat through some unprofessional demos. Never fun. But generic demos without a specific problem to solve always have a rambling aspect to them. It's a buckshot approach to finding a prospect (like carnival barkers hoping for a sucker)
In the olden days, Seybold Seminars had a panel titled "Seven Minutes with a Software Vendor". If you can't communicate the value proposition in that period of time, you shouldn't be in sales.
Unless you're attending a group demo, shouldn't every technical demonstration for a specific customer be relevant to that customer (not generic)?
I spent most of my software experience designing and building software products (product management). Lots of people spend a lot of time and brain power to think through the design and coding of software. The disappointment I feel when I get a "bad demo" is that all that hard work gets lost because all the prospect/customer remembers is that the you couldn't remember the passwords, URLs, uploaded random files as examples, or didn't have everything configured.
My point - take the same care with technology demonstrations that the folks who built the product took in designing and coding it.
EXPLANATORY: "shouldn't every technical demonstration for a specific customer be relevant to that customer" Yes, of course. But has the due diligence been done by the S/W vendor to understand why the prospect is seeking a solution? That would/should inform the presentation with relevant data and content. Not knowing the password or demoing off development's staging server is either incompetence or just plain risky. Anyone who has done live demos (as opposed to canned ones) knows that Murphy's law is always lurking in the wings. If the client has been qualified, a recorded narrative is inappropriate.
So there are two paradigms for demos: The request which should be qualified prior to the demo; and the "elevator speech" version, which should be concise.
It is difficult to imagine a prospective client sitting through a mind numbing walk through of everything a S/W system provides. At some point, it's just plain cruel and a waste of everyone's time.
SNARKY: "take the same care with technology demonstrations that the folks who built the product took in designing and coding it."
Save me from a code warrior ever explaining anything. Ever sat through a meeting with a DBA extolling the virtues of tables?
Jennifer's message seems two-fold: PSP, don't agree to a generic webinar without spending time with the vendor ahead of time identifying a problem you are trying to solve; and vendor, don't go with the shotgun approach. Have a conversation with the PSP to find out what problem or business situation they are trying to solve, instead of simply trying to sell a product that may or may not work. Of course the other take away is to remind PSP's that we need to have relevant conversations with our customers, not simply try to sell them what we have in our toolbox.
Having been involved in many technology demonstrations in my career. I agree with Jennifers observations. You must do your due diligence about the customer and what their needs are and confirm that before you begin "the dump" of information you're so proud to present.
Problems will arise in any situation. Be honest, sometimes we fail. As to developers working on the site the sametime sales is presenting. If my developers don't have the ability to do parallel development and support variants, then you're not really a developer, you're a hobbyist. If you're not ready to show a potential client the software, then wait until it's ready.
That old Boy Scout line still holds true "Be Prepared"
Thanks for your comments and thank you for extending it to how printers sell. The sales process can be complex but I think if you remember one simple thing: its not about you or your product/services - its about the customer's challenges and the solutions to those challenges. If you remain focused on the customer - its hard not to win.
A helpful trick from the presenter's point of view is the three stage adage "tell them what you're going to tell them, tell them, tell them what you just told them." Telling them what you're going to tell them helps to get everyone on the same page and provide a context for what is to come and helps clarify the relevance of the coming presentation. Telling them goes into greater detail and provides tge core info. Telling them what you've just told them acts as a review to ensure tgat the expected content was actually covered and refreshes minds for follow up questions.
Gordon - thanks for your comment. I like this advice for presentations. For sales demonstrations I would like to see a lot more preparation in "customizing" the information/demonstration to the relevant needs of this prospect.
I always wanted to enforce this sales rule: You can't speak about a benefit unless the customer has told you about the relevant challenge. This rule would force sales people to ask a lot more questions, listen more, and talk less.
You would eliminate the "feature vomiting" that happens. The customer wants to know about RELEVANT benefits. Do not make assumptions about your customers during a sales cycle. Show respect, ask the questions, listen, and then respond with the relevant benefits.
Discussion
By Robert Godwin on Oct 22, 2014
Jen,
OK, you sat through some unprofessional demos. Never fun. But generic demos without a specific problem to solve always have a rambling aspect to them. It's a buckshot approach to finding a prospect (like carnival barkers hoping for a sucker)
In the olden days, Seybold Seminars had a panel titled "Seven Minutes with a Software Vendor". If you can't communicate the value proposition in that period of time, you shouldn't be in sales.
By Jennifer Matt on Oct 22, 2014
Robert,
Unless you're attending a group demo, shouldn't every technical demonstration for a specific customer be relevant to that customer (not generic)?
I spent most of my software experience designing and building software products (product management). Lots of people spend a lot of time and brain power to think through the design and coding of software. The disappointment I feel when I get a "bad demo" is that all that hard work gets lost because all the prospect/customer remembers is that the you couldn't remember the passwords, URLs, uploaded random files as examples, or didn't have everything configured.
My point - take the same care with technology demonstrations that the folks who built the product took in designing and coding it.
Jen
By Robert Godwin on Oct 22, 2014
Jen,
Two points, one explanatory, the other snarky-
EXPLANATORY:
"shouldn't every technical demonstration for a specific customer be relevant to that customer"
Yes, of course. But has the due diligence been done by the S/W vendor to understand why the prospect is seeking a solution? That would/should inform the presentation with relevant data and content. Not knowing the password or demoing off development's staging server is either incompetence or just plain risky. Anyone who has done live demos (as opposed to canned ones) knows that Murphy's law is always lurking in the wings.
If the client has been qualified, a recorded narrative is inappropriate.
So there are two paradigms for demos:
The request which should be qualified prior to the demo; and the "elevator speech" version, which should be concise.
It is difficult to imagine a prospective client sitting through a mind numbing walk through of everything a S/W system provides. At some point, it's just plain cruel and a waste of everyone's time.
SNARKY:
"take the same care with technology demonstrations that the folks who built the product took in designing and coding it."
Save me from a code warrior ever explaining anything. Ever sat through a meeting with a DBA extolling the virtues of tables?
By Howard Owen on Oct 23, 2014
Jennifer's message seems two-fold: PSP, don't agree to a generic webinar without spending time with the vendor ahead of time identifying a problem you are trying to solve; and vendor, don't go with the shotgun approach. Have a conversation with the PSP to find out what problem or business situation they are trying to solve, instead of simply trying to sell a product that may or may not work. Of course the other take away is to remind PSP's that we need to have relevant conversations with our customers, not simply try to sell them what we have in our toolbox.
By Mark Robinson on Oct 23, 2014
Having been involved in many technology demonstrations in my career. I agree with Jennifers observations. You must do your due diligence about the customer and what their needs are and confirm that before you begin "the dump" of information you're so proud to present.
Problems will arise in any situation. Be honest, sometimes we fail. As to developers working on the site the sametime sales is presenting. If my developers don't have the ability to do parallel development and support variants, then you're not really a developer, you're a hobbyist. If you're not ready to show a potential client the software, then wait until it's ready.
That old Boy Scout line still holds true "Be Prepared"
By Jennifer Matt on Oct 23, 2014
Howard,
Thanks for your comments and thank you for extending it to how printers sell. The sales process can be complex but I think if you remember one simple thing: its not about you or your product/services - its about the customer's challenges and the solutions to those challenges. If you remain focused on the customer - its hard not to win.
Jen
By Jennifer Matt on Oct 23, 2014
Mark,
Be prepared - great advice. It counts because it shows respect for the most precious thing you spend in a sales process "the customer's time".
Jen
By Gordon Pritchard on Oct 27, 2014
A helpful trick from the presenter's point of view is the three stage adage "tell them what you're going to tell them, tell them, tell them what you just told them." Telling them what you're going to tell them helps to get everyone on the same page and provide a context for what is to come and helps clarify the relevance of the coming presentation. Telling them goes into greater detail and provides tge core info. Telling them what you've just told them acts as a review to ensure tgat the expected content was actually covered and refreshes minds for follow up questions.
By Jennifer Matt on Oct 27, 2014
Gordon - thanks for your comment. I like this advice for presentations. For sales demonstrations I would like to see a lot more preparation in "customizing" the information/demonstration to the relevant needs of this prospect.
I always wanted to enforce this sales rule: You can't speak about a benefit unless the customer has told you about the relevant challenge. This rule would force sales people to ask a lot more questions, listen more, and talk less.
You would eliminate the "feature vomiting" that happens. The customer wants to know about RELEVANT benefits. Do not make assumptions about your customers during a sales cycle. Show respect, ask the questions, listen, and then respond with the relevant benefits.
Jen
By Ken Stewart on Nov 17, 2014
Jennifer, it's great to see someone else publish on this exact topic. I found your video quite on point, and you thought of a few points I did not.
I had some similar thoughts in my own post...
Your Software Demo is Killing Me! where I challenged presenters to condense everything to 15-20 minutes!
http://changeforge.com/your-software-demo-is-killing-me/
Ken
Discussion
Only verified members can comment.