If you code for a living, chances are that you'll eventually have to do a demo. If you're lucky it'll be one of the good ones. Because, really, there's only two kinds of demo.
The first is a customer, or external, demo. Maybe the customer is really "company executives who don't know you from a hole in the wall", but still, customer demos always go the same:
- You want it scheduled as late in the day as possible, because it feels like you're never really ready for it. You come in that morning thinking "I only have until 3 to finish this." If it's put off for another day, you're excited about the extra time you get.
- You're incredibly nervous during the whole thing that you're going to make a stupid mistake, because you know that's what they'll remember.
- Customer demos are typically a team effort, where one engineer is selected to do the actual presentation. This means that you're getting the heat if anything goes wrong, even if it was not your code that did it.
- No matter how hard you work, nobody's really going to care. Most of the people in the room don't want to be there and don't really understand what they're being shown.
- 10 times during the demo you will seriously consider finding a new job, or perhaps just throwing up.
- If anything catches anybody's eye it will be the animation or the fonts or the color, or some other shallow, trivial detail that has nothing to do with the architecture of what you built.
- Chances are very good that you'll have to do it all again in a few weeks.
Compare to the internal, "prototype" demo. This time you're demoing to your peers, and it couldn't be more different:
- You're bouncing off the walls with excitement at getting to show off what you've done. Your meeting is scheduled at 10, you arrive at 9 and it's frustrating to you that you have to wait an hour because you want to keep tweaking on the code. If the meeting gets delayed you're royally pissed off because darnit you want to show it now!
- You're a frickin rockstar during your presentation. You are so confident in what you've built that when there are little snags you just say "oops" and move on to the next thing.
- Your peers are actually listening, and can actually ask intelligent questions about how and why you did certain things a certain way. And you're glad to answer those questions, up to the point where it starts to take away from your demo because you know that you're not going to have time to show off all of the greatness if they keep talking.
- Peer demos are very often solo efforts, so it's entirely on your shoulders whether it works or doesn't. This somehow manages to comfort most engineers, who wouldn't have it any other way.
- The people in the room are going to acknowledge your hard work.
- You actually don't want people to dwell on any one aspect as the "best" part because it's all good, damnit.
- While talking you're also thinking up new features you haven't added yet, and solving problems that you hadn't yet solved.
- At the end of the meeting you offer to do it again in case anybody missed it.
For a period of time I worked at a big stuffy bank. "We have 6 week deliverables," some random VP told me. Every 6 weeks an army of executives in white shirts and dark blue suits would parade over to our side of the office for their demo. The night before I watched as the project manager got grilled by his managers, memorizing the script they'd worked out. He regularly threw up before the demo. And the most he ever got out of it was a list of things they hadn't gotten into the release (that were due for the next one, of course) and stuff that was broken that had to be fixed, and see you in six weeks.
Then I went to work for a big company where marketing ran the e-commerce group and they liked them some demos. True story, I once promised them a demo for a meeting, but the demo was incomplete when my boss came around to tell me the meeting was starting. I was so pissed off at myself that I finished what I needed in the next 15 minutes or so, went upstairs and actually slipped my boss a note in his meeting that said "Demo's ready if you still want it." They did, so I came in, did my demo, and then the marketing guy running the show said, "Well, Duane's the only thing that actually accomplished anything today, and I think it's going to be even cooler than we thought it was. So I think that merits a round of applause." A little appreciation goes a long way.
What's the point, other than to point out what we as software people already know? I'm wondering if you can bridge the gap, and bring a little bit of the good stuff over to the dark side of the customer demo. Let's see:
- The schedule is what it is. Once you've got something you agree is ready to demo, then put it aside, stop working on it. Whether the meeting is at 9am or 4pm, if you keep touching it up until the last minute you're going to leave yourself in a bad situation because there's almost certainly going to be something broken or half completed in there that you have to explain at the last minute. Don't do it. Freeze it. Check it into source control, tell your boss, and then go do something else until demo time.
- In almost any room there are going to be people who are listening to you, and perhaps even interested, even if they don't know what you're talking about. Find those people. Then, concentrate your efforts on them and ignore the old bald heads who are checking their blackberries while you're talking. The fact that someone is listening to you, will help remind you that you're not totally wasting your time.
- If people want to be the most impressed with the way the form animated itself on submission, and don't seem to care about your n-tiered architecture, let it go. They are either users, or they are representative of users, and that's the sort of thing that the user sees. Save your architectural vision for your peers.
- Confidence in what you're doing goes along way toward doing it well. Mistakes have a way of creeping up on you if you let them. Slow down. Breathe. Pace yourself. Focus on the parts that are going right, don't panic over stuff that might go wrong. When you are among your peers you tend to do this naturally because you're not thinking your job is on the line if you make a mistake.
- The entire tone of your presentation will often come down to here's how much we accomplished, or here's how little we've accomplished. It's entirely in your control how you spin it. If you keep saying "We didn't get to this, and in the future we want to do this, and it doesn't do this yet...." you're leaving your audience with the wrong impression. Your fellow engineers will hear such things as, "Yup, long term strategy, ok, makes sense, there's a bigger vision that he's working towards." Customers, however, will hear such things as "What's that? It's not finished? Oh, well, let us know when it is."
You can come out of a customer demo with one of several outcomes:
- I aced the demo, and they really seemed to like it.
- I aced the demo, but they didn't really care one way or the other.
- I got torpedoed when they started talking about things that were never supposed to be in the demo, so it looks like we blew it when we actually had something good.
- We were totally not ready for that, that sucked.
Three out of four of those actually mean you did a pretty good job. You might be frustrated by the results, but that doesn't have anything to do with how much you accomplished in getting your produtc ready.
Really there's only one thing to fear when doing a customer demo, and that is "If they don't like it, I'll lose my job." If you feel that way, then you have to give yourself a reality check and ask if that's really the case. Are you good at your job? Is your team, in general, good at their job? Is the fate of the company riding on this demo? We hear all the time in the movies about advertising agencies who put everything into making one customer happy. Who knows, maybe you really are in such a situation. I don't think I ever have been. If I blow a demo, the most I'll do is walk around the block to blow off steam, possibly even wreck the whole afternoon, and then come back in fresh the next day and try to do a better job next time. Would you really lose your job over a bad demo? If so, do you think maybe you should be looking for a better job?