How to prepare the perfect product demo

You don't have to be a sales person to deliver a great software demonstration. I have found the key to improving the quality and consistency of my demos is research, planning and practice.  This demo preparation checklist helped me transform from rambling techie to educated and coherent domain expert.

Know your audience

I view software demonstrations similarly to job interviews; there is an expectation that you have researched the company you are presenting to and the people who will be attending. You need solid grasp of their core business and where your product fits it. It is also useful to know in advance the roles of the attendees and a little about their background. Hopefully you can save yourself the embarrassment of over explaining a point to an expert in the field. Public company websites and LinkedIn profiles are a good source of information.

Ask Questions in Advance

Send an email before the meeting to ask questions in advance. Use this information to tailor your demo. These types of questions are good options to discover the key issues:

• What are the roles and background of those attending?
• What are your top 3 pain points with your current process?
• Are you currently using any other tools in the process?

What you learn here researching your audience should then be used to fine tune the demo story and script.

Craft user stories

Before you start rattling off the product features to show in your run through, take a step back and imagine the software through a user's eyes. Those in software would be familiar with a user story. User stories help frame software requirements from the point of view of the end user. They are useful when preparing your product demo for the same reason.

A typically agile user story is formatted like this:

As a [ROLE], I want to [ACTION] (so that [BENEFIT])

The format works for planning software demos as well. The key difference is while in an agile framework the user story is the smallest unit of work in a software demo it tends to have a larger scope. Depending on how your product works it may be useful to design one story for each type of user interacting with the system.

Here are some examples I have used recently.

As a potential student, I want to apply for a research project so that I can start research at the university

As a supervisor, I want to review and progress my student projects so that my students don't miss any milestones

As a research officer, I want to ensure student projects are meeting milestones so that ....

You should have a couple of key user stories for your product that you can mix and match depending on what you know about your audience. The more familiar your demo feels the easier it is for the potential client to imagine themselves using your software in production.

I tend to pick two or three user stories to base my demos around. These stories are separate but should fit together to form the overall picture of your software. Often "data collection, "data workflow" and "reporting and analytics" flow well together.

Write a demo script

After you have a clear idea of the stories you want to tell draft a script or run sheet around them. The script needs to act as a high-level guide, not detail step by step actions to complete. When presenting as you need to be flexible with audience questions and preferences but try to act within your broad script.

If you don't know the product well enough to work off high level notes it should be someone else running the show.

Write a section for each user story you are going to cover. You should try to simulate the process that the user would take in the product.

• Don't hold back on the good stuff. Including some stronger features/screens/reports early on in your run through. You want people to be engaged early.
• Don't try to include everything. You need to spend time showing your best and most relevant features so don't feel like you need to "feature dump" every button and every screen in your plan. This is a trap that developers often fall into.
• Include "actions" in your script. You need to show the process of your software, not just what every screen looks like. Seeing data change state and move around your system is key to making it "feel real" for the audience.
• Avoid complex data entry. You should "do things" in the demo as the point above suggests but no one will enjoy watching you fumble typing for 20 minutes only to fail form validation. If it is going to take too long, have an example ready to go.

My preference is for each user story to outline each function you intend to show. Within each function I add details on how it should be delivered. I tend to colour code the details along these lines:

• Yellow is a key talking point. This is normally a specific business benefit that I want to highlight. Yellow is my cue to slow down while presenting and make sure I get my point across.
• Green is an action I need to take in the system. I normally highlight in green things like submitting forms, changing status or anything that I need to actually do (as opposed to just show) in the system to proceed.
• Purple is a detour or action outside of the main system. I often end up cross selling related products during our demos. Purple is a reminder to me to open up that other product/tab/example outside of the normal demo flow.
• Red is something I need to sort out before the demo. Things I highlight in red include missing data, questions to clarify about the client or (hopefully not) errors in the product. Red needs to be sorted well before demo time.
• Uncoloured items are general reminders on the story flow or minor talking points.

Do I need demo slides?

Slide decks are not my strong point and I am a firm believer in the "show don't tell" method. However, having some simple high-level slides ready can help structure your introductions and drive home the key benefits you are pitching.

• Introductions. Include the names and roles of the presenters from your company. This is a good reminder to actually do intros as it is something that can be missed and is awkward to pick up later on.
• Company overview. Your company's key information and mission.
• Product overview and key benefits. Include the name and logo of the product you are showing. Try to distil the top 1-3 benefits into this slide and refer to them in your script.
• [Optional] Description of the user stories you want to show. Sometimes a simple process diagram can be useful here.
• Conclusion. A slide to show at the end of the demo. Summarise the next steps and key contact details.

Demo Data

In the ideal world you configure your demo data to match the audience as closely as possible. For important demonstrations I have used publicly available client polices and documents to configure our demonstration site as closely as possible to how I envision the client would operate in production.

The bottom line is your demo data has to be good. "Test project 1" and "This is a comment" is not good enough.

Your demo data should be good enough that you not find yourself saying "this is just demo data".

You should avoid "smoke and mirrors" in your data and functionality. If you don't have good data for a report showing a screenshot is fine as long as you aren't trying to pass it off as the real deal.

Know your weaknesses

Put yourself into the shoes of your future client and ask "what is missing from this product?". You will know the software better than anyone so it shouldn't be too difficult to come up with some potential gaps. They key is to have a decent (and honest) answer to what may be lacking in your product.

Here are some ways to frame missing functionality when asked:

• Ensure you have accounted for it on your product road map. This should be something you can provide to a client if requested.
• Have an explanation for an alternative method or workaround in the system.
• Accept the question (if it comes) as important feedback and make an effort to acknowledge it in any follow up communications.
• Be confident about what is out of scope for your product

PRACTICE

Like all things in life, the more you practice the better you get. It can be tricky to find an audience for a "real" dry run of a software demo. You can fall into the trap of not selling to them because they are not a real client.

I normally go with two types of practice. One is a "simulated" run through of the demo with a team member - ideally someone who is involved in the meeting. I have my script up on screen and we step through making tweaks where necessary.

The second practice is a "live" run of the demo. This can still work well with team members, especially those not familiar with the product. Often the best candidates (and the hardest to get hold of) are in leadership and executive positions as they best emulate the decision makers that you need to convince.

Another option is to do regular internal team "functionality presentations". These work best if kept short - one user story from your plan. Internal demonstrations have the added benefit of knowledge sharing - both of the product and how to show it off effectively.

Presentation and delivery

I have written a separate post with my top product demo presentation tips. They relate closely to the preparation outlined in this post.

If you enjoyed the post, perhaps like or retweet the thread on twitter