How to Show Off Your Software

Few things are more nerve-racking than demo-ing your work. As the leader of a demo you are the face of your department. A great demo shows your bosses and peers the valuable work you’re doing—but when a demo goes wrong, it can be stressful and embarrassing. Giving demos is also unavoidable. The non-technical shareholders in other departments need to see the product as it reaches new milestones, so you should be prepared to show them. Like so much else in life, the key to a great demo is planning and practice.

Define your audience

Before you even start planning the demonstration itself, you should carefully consider your audience. Giving a demo to the rest of the engineering team is quite different from giving a demo to the sales team or the executive board. Defining your audience and their relationship to the software will help you highlight the most relevant features and bug fixes. In a demo to the engineers you might want to show off improved performance via benchmarks, or talk about test coverage. However, the sales team would rather hear that you’ve implemented one of their feature requests, while the executives want to know what the changes mean for the business and its quarterly or yearly goals.

While defining your audience, think carefully about how they interact with the product. What aspects of your product or service will they use every day? What are their major problems with the product? What do they love about the product? What do they complain about? If possible, you should reach out to someone who will be attending the demo and ask them: “What are you looking forward to seeing at the demo next week?” Take their response to heart.

Once you’ve defined the audience for your presentation, try to set some goals for the demo. Deciding in advance what you want your audience to get out of your demo will give you both clear goals for planning and good benchmarks against which to measure the success of the actual demo. Revisiting your goals after you’ve given the demo will help you evaluate your success and improve before your next one.

Set the scope and make an outline

Once you have a good idea of which features and changes are the most important to highlight, it’s time to order them within an outline. Be judicious in filling out the outline—it is usually impossible to show everything that the team has done. Software is complex, products can be more complicated than they appear, and engineering is hard. It’s tempting to try to show off all the amazing work your team has done, but a great demo involves making the hard choice to reduce the scope and keep things concise. You will have a limited amount of time and your audience has a limited amount of attention. Prioritizing the features and changes you want to draw attention to is crucial. Be cautious and realistic in setting the breadth of your demonstration.

In addition to the aspects of your software that you wish to highlight, there are a few things every outline should include:

• An introduction to yourself and your relationship to the software

• A description of what you’re about to demo using vocabulary that is designed to arouse interest:

  • “This is our highly anticipated new product”
  • “We’ve added a number of exciting features”
  • “The latest version of our product is the fastest version yet”

• An explanation of the motivation for the changes or features you’re showing:

  • “We’ve listened to your complaints about the data-input forms”
  • “An increase in users forced us to optimize critical code paths”
• The actual demo
• “Thank you for coming, are there any questions?”

This outline will be your road map, and you should have it handy when you actually give the demo. You may also wish to create supporting resources, such as a slideshow presentation containing relevant metrics, benchmark results, and other aspects of the software that are difficult to demonstrate directly by using the product. Finally, this is a good time to try to anticipate what questions your audience might ask afterwards. If you prepare a few slides in advance, you can say, “I’m so glad you asked”, flip to the prepared slide, and blow your audience’s minds with your forethought.

Protect against bugs and make sure you practice first

Now that you’ve planned for the best, it’s time to prepare for the worst. Nothing derails a software demo faster than an unanticipated bug rearing its ugly head in the middle of your presentation. There are a number of steps you can take to reduce the chances of this happening.

First, freeze or fork the code at a specific point where you know everything you want to show works. The presenter should be spared the distraction of whether an unanticipated regression or a bug introduced by new code might occur, so treat your demo like a miniature release and carefully test the interactions you intend to show off.

Second, to the greatest extent possible, limit your reliance on the network. Ideally, the demo should run entirely on your local device. Get the code running locally, get a mock version of the database running locally, and mock responses for third-party APIs if possible. The network connection is out of your control, and devices on the network might change without your knowledge—therefore, everything you can do to keep the demo self-contained will help you avoid an embarrassing and unexpected bug. If possible, before the demo, you should also test your connection to the projector, speakers, TV, and any other devices you’ll be relying on.

Finally, the demo that the stakeholder sees should not be the first time you give the demo. Practice running through your entire presentation at least once before the big day. Have a friend or coworker watch you and provide feedback, or film yourself and provide your own feedback from the perspective of an audience member. The practice will make you more confident when it comes to the real thing. This run-through will also demonstrate whether it’s possible to give the demo in the time you’ve been allotted, so make sure you time yourself, too. If you prepare carefully and practice beforehand, you’ll wow your audience with your professionalism and give your product the chance to really shine.

What you can start doing before your next demo

• Identify your audience and their relationship to your software.
• Make a plan based explicitly on that audience.
• Limit the scope of the demo and make an outline—show what you can, but be realistic about what you cannot.
• Freeze the code and limit external dependencies before the big day.
• Practice, practice, practice—present the demo to a friend before you present it to the world.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by Brice Marchal