Archive for October, 2009|Monthly archive page

Tips to Giving a Better Demo, or, So You Think You Can Demo?

I have anxiety.  I am a terribly anxious person.  Giving demos?  Yeah, totally not my favorite thing.  Giving demos, to me, is always walking a fine line…if you hover in one place for too long or ramble on about something, they’ll eat you alive.  If you move too quickly through something, they come after you with torches.  Ok, maybe I’m exaggerating, maybe I work for Vikings….whatever.  Point is, I’d like to give a couple of common sense tips for giving a demo that will (hopefully) help you get through things smoothly and hopefully not have a 30 minute panic attack and talkinonebreathlikethiscausethisishowitalkwheni’mnervous.

We do a demo every Wednesday of our current Monstrously Huge Project that we are working on, so I’ve been seein a lot of demos lately.  A crapton.  A metric crapton.  So a lot of these tips are things I’ve noticed while giving an internal demo to the team and product owners.  However, I hope you can use these tips for other types of demos as well.

An effective demo will give your users/team/managers confidence in the product and make sure that everyone sees it right.  In no particular order…

1. Focus

What I really mean by this (vague) point is don’t just stare at your screen.  Sometimes it’s easy to fixate on something that’s maybe not done yet and you want to think about some more, but people are waiting for you.  Don’t get lost in your own head; be mindful of your audience.  They are the ones paying for the big show, the ones learning from you, the ones working to improve it….whoever your audience is you are giving the demo for them so make sure that you are, in fact, giving the demo for them.

2. Pay attention to your audience

Pay attention to what people in your audience are saying, what questions they are asking, little noises they make in response to a flashy thing in your software.  People will make it apparent what things they want to see and what things they like.  Try to stay in the area where their attention is for the right amount of time; sitting in one spot for too long is a waste of time and will just frustrate them (cannibalism), moving through too quickly won’t give them a good feel of the product (torches).  Try to keep the demo moving at all times but don’t scroll to the bottom of the screen if someone is commenting on something at the top.  Just (again) be mindful of your audience.

3. Employ the same workflow that the software will use

One problem I see a lot in demos is people jumping all around, showing off little things here and there, showing off big parts that they are proud of, skipping things they’re used to seeing.  This…is a fail.  When demoing a product it is key to show how users will be using it.  Having a disjointed view of a product is not going to instill a lot of confidence and is not going to make someone want to use it.  If you are all over the place and they can’t figure out how to complete one workflow because they can’t follow your software, you’ve made your software look unusable and now they don’t love it as much as they probably should.  Showing off exactly how easy it is and exactly how they can use it for their needs is…well, whatever, it’s a win.  That’s the way to do it; get on the trolley.

4. Cardinal Sin: Do Not Show Code

I didn’t even think this was a thing, except that I see it all the time.  If you are giving a demo, DO NOT JUMP BACK AND FORTH TO RUBYMINE.  Or Visual Studio.  Or Expression Blend.  Or whatever the crap you use.  Customers DO NOT want to see the code.  A demo is a demonstration of a product or a partial product or whatever the crap it is.  Don’t show code!  Why would you do that?!  I don’t even have anything more to say here, THAT is common SENSE!  /end rant

5. Do a dry run

When I do a demo I always, always run through the product as I intend to show it.  This way I can make sure all my test data is safe (no I.P. Freeley’s, etc), make sure everything that is supposed to work works, make sure I know the areas to stay away from if the software is not complete…a dry run is just a great way to verify your product before showing it off.  Maybe not if you have a 5-year-old product that you’ve been demoing for years and are a fuckin pro at, but if that’s the case you probably shouldn’t be reading a novice’s blog. For most products (newer products) a dry run is a great way to a) make sure all that shit I said before and b) get a good feel for exactly what you’re about to do.  There is a stupidly curvy road near my house and I almost wiped out the first few times I drove it (note: I am a woman.  Be not surprised).  Now that I drive it almost every day I can practically do it blindfolded (dear God I would never, ever drive that road blindfolded).  Point is, it’s easier to do things you’ve already done.  Amirite?  Do it.

6. Set expectations

If your product is 50% done, tell your audience.  If something you are currently showing off is in progress, tell your audience.  Make sure they know what to look for and what to accept as incomplete or they’ll heckle you for all sorts of bugs that are not bugs at all.  By telling them which section of an app is in progress they will remain relaxed when something blows up rather than jumping up and down snarling and shaking spears (sorry, my company is a little more serious about software than yours, hmm?  VIKINGS!)

7. Good clean test data

I guess I addressed this a little earlier, but make sure you have good test data in something you are demoing.  What I mean is:

a) Make sure it’s stuff that works.  I’ve clicked on a patient name during a demo that a developer had wiped from the database but for whatever reason the name was still available in the grid.  Let me tell you how happy people are to see RUNTIME ERROR in the middle of a product demo.  Love it.

b) Make it family-friendly.  Ish.  Yay, being on your team is like working in a boys locker room, fun times!  When your CEO walks in and sits down to see what you’ve got? you had better not have Harry Balls and Seymour Butts as sample data.  Yes, I know they are hilarious but they are also fantastically annoying if people have to pull screenshots or show it to someone outside of the team.

c) Make sure there is enough.  A lot of times I’ll see a grid full of data on one screen and then when the person giving the demo navigates to the next screen a grid is empty.  Or has one item, which they take an action on that makes it disappear from the grid.  Oh, want to see it again?  Let me go into the code and add it.  ERRMP (I don’t know how to make a buzzer sound), wrong!  Make sure you have a few real-looking things in each section that you are going to show so you can show your audience til the cows come home (i.e. roughly the amount of times you think they might need to see it to get it, and maybe a couple extra for show).

Thanks to @laribee for accidentally giving me the secondary title, thanks to @edtaupier for giving me inspiration (you are awesome, please don’t doubt it), and thanks to @scottcreynolds for the martinis that fueled this post.

Agile, Agile, Agile, It’s the Way to Be

Note: This is in response to @scottdensmore’s request for software-themed Schoolhouse Rock.  I didn’t really know where else to post it, plus I can whore traffic this way.  Try to sing along in your head.

Agile, Agile, Agile, It’s the Way to Be

Design, code, test, deploy
You think this is the way to work?  Oh boy!

Have I got a thing to show you
It’s called agile, it’s the best!
Plenty of communication
Makes it better than the rest!
You think you’ve got a great thing going
With waterfall
But how much room for change do you have?
None at all!
With agile you build in
Plenty of room for change
*some other character pops head in* “Why build it any other way?  I find it rah-ther strange!”
Big design up front
Long requirements docs
Annoying when your BA is a ****
And your POs are all coooocks! *piano trill*

Can’t get answers when you need ‘em
Spec docs have no sense of totality
How will you ever satisfy
Your zero-defect mentality??
Weeellll, you’ve gotta go with agile
Make user stories follow INVEST
Back it up with good criteria
And your product will be the best!
Working software is
The primary measure of success
Use the agile way and you’ll get there
With much less streeeesssss!
Be a craftsman not a drone
Take some pride in your code
Leave your codebase clean for the next guy,
Don’t be a total chode!
Iterative development,
Continuous delivery
All these reasons add up to:
It’s the methodology for me!
*song slows, piano playing*
With a kaizen attitude
You can get there too duuuude….
*music resumes and full chorus*
Just work well with all the members on your team!
*piano closes out song*

Design, code, test, deploy

You think this is the way to work?  Oh boy!

Have I got a thing to show you

It’s called agile, it’s the best!

Plenty of communication

Makes it better than the rest!

You think you’ve got a great thing going

With waterfall

But how much room for change do you have?

None at all!

With agile you build in

Plenty of room for change

*some other character pops head in* “Why build it any other way?  I find it rah-ther strange!”

Big design up front

Long requirements docs

Annoying when your BA is a ****

And your POs are all coooocks! *piano trill*

Can’t get answers when you need ‘em

Spec docs have no sense of totality

How will you ever satisfy

Your zero-defect mentality??

Weeellll, you’ve gotta go with agile

Make user stories follow INVEST

Back it up with good criteria

And your product will be the best!

Working software is

The primary measure of success

Use the agile way and you’ll get there

With much less stresss!

Be a craftsman not a drone

Take some pride in your code

Leave your codebase clean for the next guy,

Don’t be a total chode

Iterative development,

Continuous delivery

All these reasons add up to:

It’s the methodology for me!

*song slows, piano playing*

With a kaizen attitude

You can get there too duuuude….

*music resumes and full chorus*

Just work well with all the members on your team!

*piano closes out song*