Recipe for a successful software demo

Recipe for a successful software demo

Software demos are an essential part of a balanced and healthy product development cycle. From internally unveiling a new proof-of-concept to collecting feedback from external stakeholders, software demos come in a variety of flavors. In this post we outline some of the key ingredients for making the most of this flexible and interactive medium.

Pick a flavor

The “flavor” of a demo is a byproduct of its audience and motivation. Turn the adage “know your audience” into an actionable item by defining who will attend. Distill a reason for attendance and an associated level of technical depth. Additionally, consider the formality of the setting. For instance, a weekly internal demo to a colleague may be a less formal affair than one given at a global conference.

Gather your ingredients

Software demos provide a unique opportunity for real-time interaction with the audience. Limit the amount of time spent on material that could otherwise be conveyed via press release, white paper, or slide show. Instead, focus on engagement through guided use case examples; this is the bread and butter of good software demos.

But what defines a good use case example? To answer this, the Stack Overflow community proposes the concept of a minimal, complete, and verifiable example (MCVE):

Your code examples should be …

  • …Minimal – Use as little code as possible that still produces the same problem
  • …Complete – Provide all parts someone else needs to reproduce your problem in the question itself
  • …Reproducible – Test the code you’re about to provide to make sure it reproduces the problem
(How to create a Minimal, Reproducible Example, n.d.)

Always make sure that the examples you choose align with the motivations and technical levels of your audience.

Create a Recipe

Make the most of the event by giving it structure and purpose with a formalized schedule. Typically, software demos will consist of three segments: (1) an introduction, (2) use case examples, and (3) a question and answer session. Timeboxing is a great way to partition the time to these segments.

The most unique aspect of demos is the ability to field questions and demonstrate solutions in real time. Therefore, partitioning a significant amount of time for the question and and answer session is encouraged (e.g., 30 minutes of an hour demo).

What if your invitation for questions is met with silence? If there are ancillary topics you would like to cover, then take this time to address them. Otherwise, don’t be afraid to share your contact details and adjourn the meeting early. Appreciate that the audience may still be processing everything you have just shown them.

Taste Test

You’ve defined your audience, prepared used case examples, and formalized a schedule; now what? Taste test your demo with a trial run. Set aside an equivalent amount of time and run through your demo as if it were the real thing. Rarely will the first trial match your expectations, and that is okay. Use this opportunity to fine tune your use cases and adjust time partitions. Prepare for the silent question and answer session by including it as part of your trial run.

As a last slice of advice, when significant technical divides are evident in your audience and/or examples, consider splitting your demo into multiple sessions. For example, “Introducing Support for Python 3” and “Python 3 Support: Architecture, Impact, and Troubleshooting” to separate the conceptual and implementation concerns of a tool’s migration to Python 3.

Successful software demo – Takeaways

  • Define your audience to identify key topics and appropriate levels of technical depth.
  • Emphasize interacting with the product and audience to capitalize on the benefits of the medium.
  • Give your demo structure by developing a plan and leave room for a question and answer session.
  • Fine-tune your timing and examples with a trial run.
  • Consider splitting the demo into multiple sessions when a variety of topics need to be covered.

References

Ian also wrote about

Share:

Legal Notice

This text is the intellectual property of the author and is copyrighted by coderskitchen.com. You are welcome to reuse the thoughts from this blog post. However, the author must always be mentioned with a link to this post!

Leave a Comment

Related Posts

Debugging software in virtual environments
Philipp Paul Hallmen

Debugging software in virtual environments

Imagine you are developing the software of a complex cyber-physical system, e.g. laboratory automation system, industrial robot, etc. To manage complexity, you might develop the

Monitoring Software Quality Coderskitchen
Flavien Huynh

Software quality monitoring: Real use case

Let’s continue unfolding the story of software quality monitoring on a real project.In the previous post, we saw that the price of setting up a

Hey there!

Subscribe and get a monthly digest of our newest quality pieces to your inbox.