Working in an agile team requires delivering frequent product demos to the client. Whether you are a software developer, QA engineer or product owner, this is an inevitable part of the development process. Here, at Atlantbh, most projects follow the Scrum methodology using two-week sprints. Meaning we deliver demos at least once every two weeks, at the end of each sprint.
For most, delivering a demo, or any presentation at all, is not a pleasant experience, and that’s understandable. Usually there is a number of people, many of them managers, listening to you. Any type of question can be expected and you have the responsibility of presenting the work of the whole team in the best way possible. Based on my experience, here are some pieces of advice that can help you: A) feel more comfortable while delivering the demo and B) get the most out of it:
- Prepare your scenarios well – I know this sounds as me reinventing the wheel, but before we go any further I want to make sure that this step is properly emphasized. It is common sense that good preparation is key to success, but somehow, for different reasons, we fail at this step. Even if it has been a busy day and you are completely confident that you know how certain feature works, try it out before the demo. Write down all the steps and follow the scenario. Even if you think of something really cool during the demo and you badly want to show it to the clients, keep it to yourself. We know we are building high-quality, predictable software but it is just that demo-karma that will make you click on the only button in the application that doesn’t behave as you would expect it to. Unless you are completely sure how the software is going to behave, don’t do it. Some actions take longer to process, data that you expect might be missing and you will end up leaving a bad impression even if you have a really cool feature.
- Get to the point – In order for your demo to leave the best impression on clients, try to be as specific as possible. So, less talking and more demonstrating. Often we get eager to explain how tricky some feature was to implement, what hardships we went through, basically to explain the whole ‘invisible’ work behind it, but the ugly truth is that the audience doesn’t want to hear about that. Not during the demo. Some other meeting might be a more appropriate opportunity if you must share that kind of information. Demos are the opportunity to show the outcomes, to demonstrate different features of your software product, no matter how trivial or complex they were to implement. The most successful demo I had was where we showed a bunch of ‘small’ features that make the everyday usage of the application easier. Nothing too complex to implement… I literally could hear excitement coming from the audience.
- Tell a story – If your plan is simply to show one feature after another then you might leave the audience wondering how they can utilize the features you are showing. That’s not how you sell it. You have to know client’s needs and their business processes and make a real-life story that your feature fits into. Consider these two use-cases:
– Create a new email notification. Call it ‘Info’. The notification should be triggered by event called ‘Demo’ and sent to a user called ‘Test user’. Voila, everything works! The message you are communicating is that your application is fast and easy to use.
– Create an email notification called ‘New job application received.’ The notification should be sent to all HR managers every time a user submits a new job application. This way, they don’t have to remember to log in occasionally to check if there are new applicants. You are communicating not only that the feature is fast and simple, but how it will impact users’ productivity and improve business processes’ efficiency.
Bring your features to life by explaining them through a use-case that clients can relate to. This way, you show expertise on how products should be implemented and prove the value of your software product.
- Collect feedback – This is the most important part of the demo. Demo is not a place to brag about how great our software is and how much we managed to accomplish in a two-week sprint. Make sure that everyone is given a chance to comment on the features you are presenting. Moreover, make sure that you really listen and understand the feedback because this is the perfect opportunity to collect useful ideas which you will use later to tailor your software product to their needs. At the end of the demo it should be clear to everyone involved what further expectations are. If necessary, try to summarize briefly all the comments received during the demo.
Demos should be considered as an opportunity to gauge our progress and positioning with clients and benefit from the feedback they provide. Getting this valuable feedback is done by provoking a response from clients. Telling a story that they can relate to in their business processes, brings about this response. We must keep interest by sticking to the point. Lastly, we should be well-prepared and confident with our software product and in that way build mutual trust.