views:

164

answers:

10

Hi,

What is the most useful strategy when your application throws an exception in the middle of the demo, in terms of keeping the client's mood still positive?

+5  A: 

Just tell the truth but humorously, like saying apparently our software is still not that perfect, and we are keeping making it perfect.

don't ever lie or try to cover it up. clients are not dumb.

Benny
+1 honesty is the best policy no doubt. It looks worse when you try to fib to the client, makes you seem untrustworthy which could reflect on your app as well.
Anthony Forloney
+1 agreed, be up front about it.
confusedGeek
+1 i agree about "don't ever lie or try to cover it up", but i'm not as sure about "clients are not dumb"
David Hedlund
One place I worked had a salesperson who was extremely deft at recognizing a crash coming and switching to a noncomputer spiel while he rebooted the machine. He was not respected by the development staff.
David Thornley
+2  A: 

I'd say it depends on what stage you're in. If you're selling something, my experience is that it is always preferable to just bring static material for demonstration. Powerpoints are alright, but printed screenshots that the clients can toss around the table are unbeatable. It allows you to only show exactly what you want, in a very controlled manner, while still looking very professional.

If the client has already bought the project, and the demo is related to, say, a launch that's coming up, the best you can do is to smile and say "as you can see, we're still working out a few quirks"

David Hedlund
+7  A: 

If your client doesn't trust you, there's nothing you can really do. I build trust with my clients so when something like this happens, they believe me when I give them an explanation. And when I tell them what I'm going to do to prevent future problems, I make sure to follow through.

Depending if this is a "final" demo or if its a mid-project demo will also affect whether you can really alleviate the customers' concerns. There's very little you can do to make the customer happy if it's the end of the contract and there's no more budget for testing and bug-fixes.

One generic strategy I've used: if you have someone in the room document the exception/problem in front of the customer and let them know it is going into the bug tracking system for investigation and testing, that will demonstrate to them due-dilligence and alleviate some concern. You, of course, need to follow through and make sure to fix the problem.

James Schek
A: 

I think it personally depends on your relationship with the client and how satisfied they are with your product this far.

I usually tell them it was bad data from testing or jokingly say that was a test to see how the application handles errors (if you have a generic, catch-all error message/page). You can also use the time to reiterate the importance of user testing/acceptance.

Joshua
+2  A: 

I usually let the client know up front that I'm running off a live dev environment so we might see some weirdness. If I am aware of parts that have issues (inconsistent crashes..) I let the client know about them before I show that section (along with the fact that production won't do this and I am working on it already).

Update: based upon other responses, I agree that early demos with static material are better for generating discussion.

confusedGeek
+1 It is difficult to show the client demos when you are still developing the software. I agree, be upfront and let them know a head of time that not everything is _tied_ together yet. Under promise and over deliver.
J.Hendrix
@J.Hendrix You must know my manager, he says that a lot (Says the same thing about my estimates too....)
confusedGeek
A: 

Is this shipping product or still under development?

Assuming it's a shipping product, just recover and move on. Work the room while recovering (rebooting, restarting the app, etc.) and don't dwell on what happened. Customers understand stuff happens.

I was an applications engineer and this happened frequently. IMO, the key to recovering from this starts at the beginning of the relationship / sales process / demo, not one particular event. Establish trust and build credibility with your audience as early as possible. If you have this and an exeption gets thrown, the audience will probably trust you enough to think nothing about the software failure and just move past it. Yeah, you will have the occassional person looking to crucify you regardless of what you do but that comes with the territory.

Be honest if someone asks (they probably won't) and never talk negatively about your product. I also found when questioned about a fatal error, it helps, and they are very foregiving, if you can explain what happened in terms the audience understands. It demonstrates your knowledge of the software process and goes back to trust.

Scott
A: 

Possible strategies:

Telling the audience "we're all going to stay here until whoever did that owns up".

Complaining about the prevalence of evil monkeys.

Seriously, I'm majorly against public product demos. Don't attempt demos until you're 99.99999% sure the damn stuff works. And even then it's a bad idea, you're setting yourself up to fail with all the variables that can go wrong - which may not even be with your software. If you must do it, attempting to impress customers with a flashy UI is best done one-on-one. That's the way we've always done it.

Bob Moore
+0 Not sure that I agree that demos are a bad idea. I've found demos help set proper expectations, get early feedback on usability, and can often start discussions of follow-on work. But to do demo's safely, you need to have PM's who will hold their ground when it comes to unpaid scope creep.
James Schek
I'm not against demos (we do them one-on-one using laptops), I'm against *public* demos, where some poor schmo from sales gets up in front of a crowd at an industry conference. In my experience, the probability of everything working, even with *production* software, is low. Venues have flaky networking, may have no UPS facilities, people walk past machines and start fiddling with them... you get the picture. There just isn't enough *control*.
Bob Moore
Ah--make sense. Agree--"public" demo's can be really bad.
James Schek
+2  A: 

The last time I presented a project to a conference, I planned a live demo, but I actually had a set of slides headed "If you can see this, the live demo didn't work!" with big screen shots. Inevitably the live demo didn't work (it needed a globally routable IP address and this wasn't available) and the slides were called for.

come to think of it the slides are here: http://www.slideshare.net/TYR/tracking-international-arms-dealers-with-python-and-bits-of-string
A: 

I've never done a demo where I didn't set expectations beforehand. If this is a work in progress, make sure they know that up front. This goes a long way towards keeping them positive. EVERYBODY has issues during demos. Just smile, tell the truth and continue.

Probably the best way to help keep your client positive is to project positivity and confidence yourself. If you seem unsure of yourself it'll show as being unsure of your app.

Terry Donaghe
A: 

Write down the Exception and why/how it occurred IMMEDIATELY. Then they will see that you will be fixing it.

Joe Philllips