An often undervalued but crucial element of software development projects is the Product Demo: the session in which changes or new features are presented to the application stakeholders and/or end users.
— Small prelude for the Scrum Police: when I say ‘product demo’, I do not mean the Sprint review (of which the demo can be part of though). So unlit your torches and put away the pitchforks, people. —
You and your team may have done an outstanding job on creating a groundbreaking, job changing or life bettering solution, but to what use is that if you cannot convince the stakeholders of its merit? Or worse: have them resist your application before they even start using it.
This is not a hypothetical or inconceivable scenario. In every company and at every project people can attend your product demo whom are skeptical, who may be scared of the way you are going to change their daily activities and who will be vocal about this.
But that’s okay. Better than okay: you want these people to be present. You want these stakeholders to voice their concerns and confront you with their worries.
Because even though it may seem harmful to the perception and acceptance of your app at first, this is also the moment you can increase involvement in the development process. You can acknowledge their concerns and explain your team’s intention and motivation on how you have dealt with their problems. You can convince them their voice is heard and their input is valued, and ultimately show how your product will improve their daily activities.
Even when it turns out that (some of) the work you did does not match their needs, it is an opportunity to show them how the (iterative) development process works and that your team’s sole agenda is to create a product that matches and helps them in doing their job.
In this product demo you can turn critics into allies, who eventually may become advocates for your application. It can, however, also be the moment they lose faith in the project, the process or the development team.
So what can you do to make sure the latter does not happen? The story leading up to this sentence may have given it a bit away, but that doesn’t make it less true: give a compelling, convincing and kick-ass product demo!
Luckily, this doesn’t have to be that hard. Even when you are not the best public speaker or when you don’t have a lot of experience in giving product demos, the advice below can still help you a lot with providing structure to what you are presenting and making sure your audience understands the awesomeness you are trying to convey.
In the many years that I have been involved in (Agile Scrum) software development, I have given a lot of product demos at different clients, for different audiences and for different products. In this time I learned some ground rules that I apply to all my demos to improve the effectiveness and quality of my presentation.
So what are the things you can do to improve your product demo? As Buzzfeed proved that all information worth reading should be presented in a list, that’s exactly what I will do. In no particular order, here is what you should do:
1. Know your audience
Know who you are going to present to or prepare to entertain a diverse audience. An end user of your product has different information needs than a security officer, who wants a different presentation as an ops operative, whom may want to hear something else than your Product Owner (PO). You should be able to cater to all their needs.
2. Present scenarios, not user stories
User stories may be the developer’s bread and butter, but your audience prefers to see scenarios. Real life situations that they can relate to and because of that can instantly assess the merit of your changes. Combine your user stories into scenarios, for example: ‘How to find and handle a customer complaint’ covers the stories ‘create overview of complaints’, ‘create complaint detail screen’ and ‘have reply function’. Showing a list of scenarios before starting the live demo helps as people know what to expect during the demo.
3. Prepare your live demo
Prevent error screens and loss of face/credibility by doing a dry run on all your scenarios, well before the actual demo so (minor) bugs can be fixed. Pro tip: check the equipment that is used for the demo as well. Make sure it connects and provides a good representation of your screens. Projectors will often ruin colors and aspect ratio, so try to find the optimal setup beforehand. Do all this to prevent something from going wrong.
4. Prepare for something going wrong
Because it will. In spite of your best efforts, the so-called ‘demo effect’ dictates that something that has been tested a hundred times before will break down just when you don’t want it to. But don’t ignore it: address it. Show the audience how you deal with problems, acknowledge that in software development things can go wrong. Perhaps even show how the support process would work. Own it.
5. Use realistic data
As fun as it may be to name all your ‘Customer’ objects after Game of Thrones houses and fill your product catalog with your favorite fast food items, don’t do it. Yes, it’s only test data and yes, it’s only illustrative for showing the functionality, but it will distract people from what you are trying to show. In order for your audience to relate to your scenarios, use production-like data that they are familiar with.
6. Narrate what you are doing
Talk about what you are doing while you do it. You may be well accustomed with your app and think some user actions are obvious enough to skim over, but this may not be the case for your audience and it will confuse them. Talk about what user is going to log in, what his role is in the app/process and narrate every mouse click and your user’s motivation for choosing that particular option so people know what is going on at all times.
7. Keep the dialogue open but controlled
I always like to tell the audience that they shouldn’t hold back on questions until the end and keep a healthy dialogue throughout the presentation. This loosens up the mood, increases intimacy and allows you to instantly motivate design decisions and address concerns. Important though is to keep track of time and the flow of your presentation: don’t dwell on little details or specific topics for too long (some people live for this) as this is not interesting to all people attending your presentation. Have someone write down all feedback to address at a later time or:
8. Invite people for in-depth follow-up sessions
When people want to see more details of a certain feature or perhaps wish to see the specifics of a process more in-depth, invite them to a follow-up (deep-dive) session. This allows you to address their needs and/or concerns in a more personal setting that will better satisfy their information demands. Also, it allows you to continue your demo so it remains interesting for all stakeholders in the room.
9. Have the PO be present
People who see (parts of) their daily jobs changed in your demo will have questions. You will probably be able to answer a lot of these, but questions on “how” a certain role or department should fit or change to align with company goals are often not meant for you. Especially when a discussion starts on how or when certain problems should be dealt with, you want the PO to be present. He or she has mandate on making these (development content and direction) decisions and what has priority. Issues that you as a developer often have no say in. Have the PO present to quickly bring these discussions to a satisfactory end.
10. Collect feedback
Never believe there is nothing left for you to learn. Even if you think your way of presenting is the most effective way of conveying information that exists, collect feedback from your stakeholders to see how you might improve and better tailor your presentation next time. Sometimes people are just so used to how information is normally presented to them in their company, missing (some of) these elements can be distracting them from your message. Be adaptive: always keep looking for the best way to get the message across for the specific audience you are showing your product to.