How to Demo Software
How to Demo Software
Selling your skills to stakeholders
Why Public Speaking?
Most people who become a software engineer skew towards the introvert scale while also not being great at public speaking. This is a common stereotype amongst our profession and I find it to also be true. If this matches your persona, breaking out of those stereotypes are how you can get promoted more often than your peers. Being a talented developer who is also good communicator gets you recognized more than the peers who sit in the back, hoping recognition gets bestowed upon them. Great technical work does get recognized amongst peers and immediate management, however building your reputation amongst key stake holders give you a supplemental X factor at your W2. While your work is overtly technical, the people promoting you are often less so. Your manager may not have coded in a decade after moving up the ladder. Their boss even more so. That also doesn’t include HR, which often makes the final call to approve a promotion. You need at least all three on board to give you that pay raise.
Relaying your skillset is effectively a giant game of telephone. If the initial signal is weak, it will die out before it can reach the powers that be. Therefore, it’s on you to start off with the strong signal in this process. The easiest hack towards this is any sort of public speaking amongst your organization. If you’re an Agile practicing team, then you already have a built in Demo session where your team and others gather to see what you have built.
You need to remove the preconceived bitter taste of giving demos that I, amongst many other software devs, have had for years. Instead of seeing it as a waste of time or a fruitless effort, you need to flip the problem on its head and turn a problem into an opportunity. By giving a strong demo of your work, you will share with managers, senior managers, peers, projects managers, and more how good you are at your job. This is often the most productive facetime you will get with extended team members and people on the business side too.
You will use the software demo to convey the business needs to the audience, share your technical implementation along with all novel code, offer a live demo, demonstrate the value of the feature, and then take questions from stakeholders. We will go in depth on each step of giving a public presentation.
Software Demo Guide
Confirm the meeting
Before you start any public presentation you need to ensure your work environment supports the Demo loop. Agile shops will include this usually but if there is not a culture of Demos you probably have to fight up hill for this. If you wish to make this happen then lobby your boss and their boss and mention how this is a direct way to see the impact the team is making on the business unit. If your boss doesn’t agree, then you may need to side step to your product manager and schedule something your self. In this case I would demo larger features - multiple features on a longer time frame, as the 2 week sprint will often include smaller work such as simple bug fixes, API changes. I would leave the basic CRUD endpoints as just a smaller bullet point, but if there is new or interesting code involved, try to share that. Often new development techniques spur the rest of the team to copy or transform your work, especially at the smaller level corp, which is how you start building a good reputation.
The frequency of the demo will determine the amount of content to show. If this is a special project with a demo for your Director or VP put in much more work in every phase, as key business decisions will flow from what you show them. Often more senior level devs will need to build proofs of concepts and demo them to inform higher management of the potential future work.
Additionally, ensure that the meeting owner - either you, your boss, or PMs have a clear agenda of the demo material, and send over what you wish to demo in advance. Lack of agenda is a main reason stakeholders do not attend, so send it out early and determine the speaking order.
Once you have the demo setup it’s time to prepare to give the presentation.
Prepare the System
Demos are usually given the week after a sprint is done while a new sprint is in flight. This means there will be a few days between code complete and the actual display of the software. It’s important in these interim days to save all relevant testing data, API requests, data base setups, DB queries, Config values, Stubs, etc… so that once demo day comes, you do not have waste time and setup your environment again. Personally I always have to remember to seed the database with the correct data again come demo day, you do not want to make this a habit, especially if your feature is complex. You’ll waste up to half a day just setting the demo up, and you do not want to be stressed going into a presentation. I have certainly scrambled minutes before a demo to setup the database correctly and it is not fun. To get around this, in your Pull Request always add in relevant test data and configuration options to be used as a historical record of documentation. This will make your recall easier as you will have already context switched into a new task due to the new sprint.
By this point you will now understand if your software is in the correct state to demo. If this isn’t the case, please inform the meeting owner ASAP to reschedule if needed. Also if you find any bugs, do your best to avoid them in the demo. Again if your demos are frequent, you can afford some level of “off-ness” - known bugs can be fixed in next sprint, or incomplete features can be shown. Just make sure to note that and say, ”it’s prioritized”, which are magic words in the Agile world. This will comes down to your work culture here but my team is flexible and understanding that we have lots of work in flight and not everything is going to be perfect all the time.
Now that you have a working environment you need ensure that the environment remains stable leading up to the demo. Often the day before I try to set everything up, and then retest a few hours before demo time to ensure everything is working. Inform your team also of any important data that must not be changed. Often sprints have you working together on a feature, so it’s highly likely the state you put the system in may clash with another teammate, so confer and sort the details out. If you have shared testing environments then also ensure that no one deploys news code as a safety measure. Ideally your testing suite would catch any new bugs, but it’s easy to miss a case that results in a bug cropping up.
Build your Presentation Script
Now that everything is ready, you need to build your presentation. Before you start working on this, you need to follow the golden rule of any public speaking, “Know your Audience”. If this demo is mostly business side of the house, then limit technical details and focus on presentable features and mention business problems and solutions. If the demo is more technical folks, don’t be afraid to dive a bit, show relevant code, and more. However, even the most technical of folks need a business problem to understand the context and what needs to be solved. Often you’ll get a mixed audience so balance the business needs and technical presentation. Remember demos are supposed to show your skillset off, so optimize for the forum.
In terms of the presentation script, this is the template of how I like my demos to go:
Self Introduction
Important if you demo to people outside your team
Feature Introduction and Scope
Ensure everyone understands the problem and its boundaries. Think STAR - Situation, Task, Action, Result
Contextual background (optional depending on audience)
Not everyone is aware what your work focuses on and what the state of the project is. Bring them up to speed and mention key details.
“I worked on X project this sprint, doing feature Y, that affects system Z, as part of initiative Q”
Live Demo of Feature
Point out key details as you go, but make sure to demo everything fairly quickly first before diving down into the details
Prefer not to take questions yet, give whole picture first
Deep dive
Show notable code and algorithms
Explain your design process
Elaborate on trade offs considered
Mention edge cases
Wrap up Demo
Mention future work that will build upon this feature
Q&A
Be prepared to answer technical question within reason and limits of the meeting. This isn’t a design session, but feedback is useful. Anything too complex offer a follow up meeting with the individual.
Business questions can be handled by you, but don’t be afraid to punt to the product manager
“I Don’t Know, I’ll follow up with you” is an acceptable bailout answer to less significant stakeholders
Conclusion
End the presentation or pass onto the next person
Thank everyone for their time
Post meeting follow ups
If you made any follow up commitments make sure to do them so you can incorporate your feedback into your current and future work.
You should write this template down into a document, and then fill it out every time you need to give a demo to ensure a standardized demo format. This will keep you from veering off schedule and ensure you don’t miss any details. I also make sure to write down key phrases throughout the document to repeat verbatim to the audience. With all this finished ahead of time you will have confidence going into the live presentation.
Build your Cheat Sheet
Once you have a solid script for the demo you will need auxiliary information to support it. This is why I make a cheat sheet that contains the following:
Presentation Script
Data Samples / Inputs
URL Links
The Cheat sheets is your main reference point during the demo. This prevents you from forgetting where to go once things are live. It should be your one stop reference point for anything you need in the Demo. Once you are live you don’t really have time to improv, so build a rigid sheet that you can reference in the midst of presentation. Since I have two monitors I always have the extra one with spare documentation up, my demo outline script, and any additional web pages I would need to reference in the middle of my presentation.
Give the Demo
Now that you’ve done all the prep work, the demo should be straightforward. The day of the Demo make sure to give a dry run before the meeting to ensure everything works as expected following your script. Make sure your mic and camera work correctly if remote and that you are wearing appropriate attire. If you are giving a demo in person, arrive early and check if the room hardware works. If you have bad internet or a noisy working space then find alternative solutions. Make sure that you’ve cleared your computer desktop of all distractions and unnecessary applications open. Make sure to silence any work chat notifications that could pop up during the meeting. I also like to pre login to any needed sites that are useful, this could be the team source code hosting site, a third party API site, and more, as this will save you time and boredom from your audience. Have your cheat sheet handy and follow the script you built and you will do well. It’s time to now let your Demo rip!
Remember, stick to the script!
Now things can and will go wrong during the demo. Someone will change the database or a new bug will pop up during it. Don’t panic, acknowledge what happened, and proceed to make adjustments. If data needs to be reseeded or a query needs to be run, that should be ready to go in the cheat sheet. If the bug can be ignored, do that. If the demo is stopped due to a data issue, try to perform a quick and dirty fix. If its too hard to fix try to demo what you can and side step the issue. If the demo is complex enough then consider building a script in Python to seed all the correct data and keep that on hand. Otherwise mitigate or reschedule. Pre-recording an offline demo and sharing that out is also great if the stakeholders are mostly external to the business.
People are understanding of these issues, but the higher the level of stakeholders the less mistakes you need to make. This is why you dry run your demo at least once before presentation.
Conclusion
With all this in mind you now have a playbook on how to give better software demos, and therefore demonstrate value to the important people in your company. By embracing this you can take advantage where other developers fail to take advantage and use it as a springboard into promotions. You can only get better at this by trying, and giving Demos is a perfect way to build those non technical skills out.