Here at Citrix, we build a lot of demos. When you’re fortunate enough to work for a company that produces amazing products, you’re always showing them off. Because when a product transcends what can be said of it – and speaks right to the heart of ‘great user experience’ it must be seen to be believed…

Building an effective product demonstration environment is as much an artful as it is a technical endeavor. It requires a keen understanding of your products capabilities, its strengths, and its key differentiators from competing products. In this article I wish to relate some of the best practices, lessons learned, and suggestions that I’ve accumulated while building demo environments for Citrix.

A proper product demo environment is a true ‘sales force-multiplier’ only when it is properly developed and clearly presented. Because an interactive demo can provide a tactile, realistic, and personalized experience to your audience, there is an added risk that your audience can have a negative experience as a result of improper design or poor delivery. I’ll save the ‘proper delivery’ aspect for another article and focus here on planning, design, development, and testing. I will make the following assumptions:

• You are reading this because you are building a demo environment to showcase one or more technology products
• You are doing this to increase sales leverage and shorten the sales cycle

Planning
Most failures are the result of poor planning, improper expectations, and lack of effective communication. We all know this – but what are some specific planning considerations when you are dealing with a demo environment? First – don’t operate in a vacuum. Start your planning early and involve ALL the stakeholders. It’s a mistake to begin building a proper demo environment without the perspective that the only the whole organization can provide. Below are a few of the groups that are all too often omitted from the planning stage, and this nearly always causes problems.

• Marketing – Competitive intelligence stakeholders
Make sure that the marketing department provides its objectives from a product messaging standpoint. Identify your products strengths and key differentiators and determine what is demonstrable.
• Development stakeholders
Make sure that your product’s existing features and upcoming features are well understood by those who will be developing the demo environment. Much like any other environment, you have to have an eye toward the future and build accordingly.
• Sales stakeholders
Involve the sales force, as they should know what the customers are asking for and what competitive advantages should be capitalized on and showcased. They should also have a greater feel for what is realistic to demonstrate during their customer conversations.
• Executive stakeholders
Much like the marketing team, which can provide guidance from a messaging standpoint, the executives typically have the clear message they want to project to the marketplace. They are frequently privy to information no one else has – so you have to make sure the demo environment can help tell the story that they want told.

Design
When designing any demo environment, you have to know who your audience is. Easier to design is an environment used only by your own people or vested partners, as you can usually expect a certain amount of proficiency on their part to use the environment as it is intended. Training can be provided for those that need it. But a demo environment that can be accessed by the public, without any guidance whatsoever requires painstaking attention to detail and easy to understand instructions. Key thing to understand here are; if it can be broken – they will break it, and if it can be misunderstood – they will misunderstand. Demo environments that can be accessed by anyone present the biggest challenge to the designer, and frequently it is necessary to restrict what can be accomplished in the demo to easily consumed scenarios.

Development
Put your best people on this – really. Make sure they clearly understand what the end result should be (see planning section). The people doing the actual building of a demo environment should have an in-depth understanding of all the pieces that make up the demo environment. They should have extraordinary attention to detail, and quite frankly – be perfectionists.

Ideally, the people you choose to develop the demo environment will have some history with the product. What I mean by this is; if you are showcasing a product that has undergone many changes over the years, the developer(s) of the demo should know what the product used to do (so advancements can be showcased), as well as what future enhancements are on the product roadmap (so the demo environment can be developed with growth in mind).

The development team should be made up of people that work well together, aren’t afraid to ask for help, and genuinely enjoy teaching people how to use the product(s) being demonstrated. A flair for presentation will show in the final product, and that’s usually desirable. Experienced product trainers are especially good at designing demo environments because their experience in the classroom gives them special insights into what the customers find interesting, what’s impactful, and what topics are foundational to the audience understanding what the product can do.

When developing the demo environment, refer back to the design specifications from the planning sessions, and do it often. It’s all too easy to stray from the original mission while in the midst of putting everything together. If the product you are demonstrating has many ‘moving parts’ or allot of optional components, you must continually ask yourself, does this enhance the demo or can this be a distraction? This is continually a challenge for the very technical among us who tend to want to showcase the latest technical wizardry. As with much, simpler is usually better.

Testing
This is something that never ends – and is never done well enough. It never ceases to amaze me what slips through the cracks and ends up embarrassing you later on. In my experience, the worst people to do ‘final’ testing are the people who actually made the environment. They are too familiar with it and take too many things for granted. Even the most detail oriented people will make mistakes here. The best people to test your demo environment are people who have NEVER seen it before and are representative of your intended audience.

You must recreate all possible usage scenarios for the testing procedure.

• If your demo is an unattended one, where users interact with the demo without any input from a facilitator, then you shouldn’t be present to answer their questions, ask the testers to write them down.
• If your demo is designed to be facilitator led, such as where a sales person or engineer guides a user through the demo, then gather some test subjects together in a room or on a GoToMeeting session and present it exactly as you would to the intended audience.

Regardless of which method you use, you must debrief with the testers and review their questions and concerns afterwards. This should give you a good idea of where your demo can be adjusted. If trends emerge in the questions they had while testing, you can adjust the demo, or provide better instructions. Consider having all those from the initial planning session present for this debriefing session and make sure their expectations have been met, or adjusted…

Well there you have it – my overall thoughts regarding the development of technology demos. I’d love to hear what you have to say about, so feel free and add your comments…