Regular Demos – is one of the most powerful instruments of managing your client’s expectations. That’s the way you can formally get acceptance of your team’s work and eliminate frustration risks caused by missing functionality. It’s like “selling” product to the consumer and motivating them to buy it.
This article provides a few tricks on how to organize a great demo in a routine of software product development cycle.
Choose the right time and audience
Make sure that people you invited to the Demo know the context. They should be motivated to provide feedback and have enough authority to make key decisions.
Product Owner who formally accept product/feature delivery from the client side must be there. Also, consider inviting representatives of the backend, marketing or customer care teams. As well as any group of internal users interested in the product progress and certain feature delivery.
Prepare Script
Write a demo scenario and script beforehand. It will help presenters to demo feature faster and more precisely. Figuring out things on the fly might not be a good idea.
Simple Script would look like this:
#User Flow - Log as johndoe@gmail.com / pass - go to Dashboard - see available balance - show withdrawal process - show success/fail case - Logout
#Accountant flow - Log as sarahdoe@gmail.com / pass - Show monthly reporting stats
Prepare Presentation
Classic powerpoint presentation will help you structure message and focus your audience on certain topics.
You can consider following presentation content
- team members introduction
- show demo plan and state which part of demo topics will be interesting to certain attendees
- remind goals of the previous sprint and re-state upcoming sprint focus
- add screenshots of implemented features
- show business metrics changes during the last iteration
That’s a way you drive your demo forward with a predefined scenario, control timing and always have Sprint and Demo artifact which is easily sharable to others.
Rehearse
That is a #must step. You should always rehearse your demo before actual presentation is made. This will prevent you from public disaster when presented functionality is broken. Also, it will actually help to build your scenario for demo script. Just reserve a time slot at least a day before Demo meeting to prepare.
Switch presenters
Development Sprint was a team journey, so let your teammates present the work they made themselves.
Who demo’s what – needs to be a part of Presentation Plan. As a demo organizer – make sure that your teammates are comfortable to use demo presentation tools beforehand (hangout, GoTo Meeting, Skype) and commit to that.
Control the Conversation and Timing
During the demo run, you always need to make sure guests are actually listening. Don’t switch slides until you see that people are engaged and follow you. Don’t let the discussion go too deep or switch to the topics that are not relevant to the goal of your demo. Finally, you can allow attendees try new functionality themselves, if technical setup allows you.
Backup Plan
Always have a backup plan!
What might happen?
- API team released new unsupported version on stage environment
- your teammate changed account access password or wasted the one available use case
- your teammate is suddenly sick, so can’t present his/her own part
So, the above mentioned static presentation is the easiest way. But it is still, good to have demo setup on another (e.g. local/dev) environment.
Retrospect or “close the deal”
Just like in the Sales Call you need to “close the deal” and summarize conversation. Schedule follow-up, plan the next meeting and ask attendees for feedback.
This will help you adjust the next demo a bit.
and remember
Every demo is a “Sell” of your team, your approach, your service. It’s a really powerful tool to keep client on track of your progress and for you – collect feedback to tune your roadmap.