Just for fun last night, I started compiling a list of my best guidelines for live software demonstrations (“demoes”). I turned into quite the list so I thought I’d put it out there to see what you think of it. Anything you would remove, change or add? Which one do you like the most?
Guidelines for Software Demonstrations
- Send out the agenda in advance (what will be reviewed). This will allow everyone to decide if they want to come or not.
- Prepare and test in advance. Use a high-level script. Pre-cook data. Keep a backup plan for the thorny bits.
- Use three roles: Host, Demonstrator, and Note taker. Demonstrator could alternate.
- Allocate most of the meeting time for looking at live software. Keep slides to a minimum. Too many meetings look at slides anyway.
- Prefer showing things that are ready for release, or nearly ready. This will provide the most accurate picture of current status. Avoid pretty but unimplemented designs which often leads to exaggerated expectations. Don’t show untested or buggy software.
- If time is short, demonstrate the most interesting stuff and list the rest for completeness.
- Keep it engaging and use occasional humor to lighten the mood. Role playing is an excellent technique for both.
- Frame each solution with the context and the problem. Explain the situation and what the customer is trying to do, or what problem the customer is having.
- Demonstrate at a slow pace, explaining every move. People won’t be able to keep up otherwise.
- If you have them, use metrics to show the outcome of the solution that was just demonstrated. This will help demonstrate how your teams provide business value instead of being a feature factory.
- Encourage questions and feedback from the audience and show appreciation when you get it. This will create more feedback.
- Respond to all feedback, either in the meeting or, if you can’t answer directly, afterwards. People hate shouting into the void.
- At the end, review the road map or backlog so the audience knows what’s coming next.
