I recently had an epiphany Software demos are rarely worth the effort. There are few instances where the resources spent in preparation outweigh the risk of a spectacular public fail that demos entail.
I've participated in countless demos in my career to stakeholders big and small. I've conducted demos for the CEO of a large health care company. I've demo'd software to military officers and college professors. I even helped demo whitehouse.gov to the President of the United States. I've also demo'd software to librarians, call center workers, and lots of other front-line workers. All of these demos involved a rush to produce something worthy of demonstrating, rehearsal, and a lot of prayer. Some resulted in "attaboys," some resulted in complacent acceptance, and some resulted in complete system re-designs. No one has ever been so blown away by what I've shown that they immediately increased the project budget or gave me a hefty raise. Maybe that's the quality of my demos, but I doubt it.
So why do development projects subject themselves to extra work and stress to conduct demos? Here are a few reasons I've identified:
Collect Interface Feedback - It's a bad idea to use a demo in order to get user feedback on user interface. First, demos are staged and don't reflect anything in the real world. Often in a demo, the demonstrator is the developer who created the software and knows its every nuance. They know exactly what buttons to push and where to go to find what they need. The result is a polished demo that makes the software look easy to use. The demonstrator first shows the user how to use the software and then asks them if it looks easy to use. Of course it looks easy to use, they were just shown how to use it. That's not at all pertinent to whether or not someone who has never seen the software before will understand how to use it.
Collect Aesthetic Feedback - Demos should not solicit feedback on the look and feel of an application. Often, users will comment on the color scheme, layout, or graphic selection of the application. Those types of issues should be consistent with the brand and marketing of the application, not the personal tastes of users. The best way to test the aesthetics of a design is to conduct a branding test. Decide what color scheme you want to use and then ask a sampling of users to tell you what values those colors evoke in them. For example, if the application is handling sensitive information it should convey trust. Pink and purple would probably not be the best color choice. You can do the same type of test for the logos and graphics.
The other reason not to listen to feedback from users on aesthetics is that they aren't designers. When considering someone's opinion on a graphic design, the first thing I do is take note of what they're wearing. If they're telling me my colors aren't appropriate and they have on a Donald Duck novelty tie, their input doesn't count for much. Design is much more than having an eye for color and taste. A good design is well thought out and follows some basic tenets on the presentation of information such as use of white space, font choice, and layout. These are principles that are gained from experience and should not be subject to review from someone's inner artist.
Demonstrate Progress - This is about the only good reason for do a demo. Stakeholders need to see that there is some progress being made and there is no better way to demonstrate that than by showing off the product in action. This is a perfect scenario for your magic show. A good demo that wows stakeholders buys goodwill for the project and creates a positive buzz for the software. The problem is that you need a finished product to create that wow factor, and if the product is finished, it better be what the stakeholders expect. It's like at the end of a barbershop haircut. The barber always holds up a mirror at the back of your head for you to approve of the job he did. If you act shocked at what you see, that's very bad for the barber. There is no way to put that hair back. The worst comment he would want to hear would be something that might require a little extra trim. Similarly, there should be many touch points with stakeholders during the development process so that demos do not result in any surprises. It's important to have a clear understanding of expectations (requirements) up front with sanity checks along the way. If this is done, demos merely reassure stakeholders that you're making progress.
Overall, demos are not a good way to collect any kind of information from stakeholders. The only things they are good for is demonstrating progress. It's natural for a development team to show off the product of their work, but expectations should be set appropriately.