Software development teams have a number of processes and ceremonies they use to achieve peak collaboration and effectiveness. However, in my experience, one of most under-appreciated and underutilized events is the Demo.

Far too often, the demo is an afterthought. With the agenda frequently coming from the question “so, what do we have to demo?” the demo then becomes a reactive, last-minute scramble to make the in-flight work presentable or to put together a perfunctory and banal status report.

So, how can you and your team find new value and breathe new life into your demos?

Know Your Audience

Who is your audience? What motivates them? What do you want from them? What visibility is your work getting through the normal course of development and releases? And how can your demo augment what your audience already knows?

The answers to these questions can help guide and influence the style and structure for a demo that is uniquely your team. Just as individuals on the team shape and evolve the team’s culture, those people interested in the team’s work also have an influence on how the team operates and presents itself. And similarly, the audience’s tastes and preferences may change over time; it is important to adapt to those changing circumstances.

Audience personalities and expectations should be a formative factor in planning a demo. For audiences primarily interested in seeing progress the team is making, visualizing roadmaps and timelines regularly help keep the audience engaged and informed. For audiences interested in more technical details, diagrams and systems-level details help to deepen a shared language and open up opportunities for a dialog. For an audience interested in the business outcomes, the team is driving and influencing, data visualizations showing the impact on the business may be more engaging than the features or changes themselves.

And, of course, variety is important: if you have an eclectic or diverse audience, consider rotating through different styles to appeal to a larger audience or having multiple, smaller demos with purpose-built audiences.

Less is More

Resist the urge to demo everything the team has done or worked on since the last demo. If a particular task or piece of work does not meaningfully contribute to the story you want your demo to tell, leave it out. This may be particularly difficult to do if certain team members worked exceptionally hard on something that isn’t being showcased; experiment with ways of weaving their contributions into the narrative, providing opportunities for different team members to present content, or rotating team members within the visible work from demo to demo.

Transitioning from Reactive to Proactive

An unintuitive, but powerful, strategy for crafting the team’s outward narrative is to use the upcoming demos to influence the execution of the team’s work. By planning the content and periodicity of the demos themselves upfront, the team can intentionally scope and sequence their deliverables to showcase their progress and best work to their stakeholder audience.

Demos are a fantastic tool for breaking down large, long-running projects into milestones. And despite common misconceptions, demos do not always need to be about showing newly launched features. Here’s a couple examples about how that might play out:

International Expansion

A team is underway on a multi-quarter initiative to prepare their product and business for international expansion. From the beginning, the team knew that the majority of the work would be “under the hood” and not obviously visible in their regularly-scheduled monthly demos for quite a while. In fact, for the existing market, if they do their jobs well, this work won’t be noticeable at all. Knowing that their demo audience would still want reassurance that this high-profile initiative was progressing on schedule, the team planned their monthly demos upfront.

The first demo planned was going to show off how the project would be phased. Sure, some foundational work would already be done, but it wouldn’t be ready to show off yet. What the team was able to finalize though is how they would approach development, what milestones they were defining for themselves, and the launch plan they were anticipating.

In order to plan for future demos, the team strategically planned certain consumer-facing features to develop alongside their infrastructural work. One demo would show off their invoicing changes, which would now show receipts in local currencies. Another demo would show off certain pages that would be in the consumer’s native language. Had the demo not been a factor in the sequencing of this work, these features may not have appeared until much later, but the team decided that the incremental visibility would help to assure their stakeholders of the progress they were making.

In each of these demos, they would reference the original demo’s project plan, bringing continuity to the narrative. Even though the project plan would change as the team discovered new information and had to change course, the format of the material remained consistent and gave the audience a frequent look into what the team was working through.

Business as Usual

A team is maintaining a legacy application, but there haven’t been many major features added to it recently — at least none that would make for a visually impressive demo. The work the team is doing is very impactful to the business though, as this system is a major revenue engine. For this team, they know that their demo audience primarily cares about the health of the business and the outcomes this team is driving.

This team decided that the message they wanted to deliver on a bi-weekly basis is that the changes are having a significant business impact. This impact primarily reflected in improvements to Operational Efficiency (internal customers are able to do their jobs more effectively) and Net Promoter Score (external customer feedback about their willingness to recommend this product to others).

Both of these metrics take a significant amount of time to measure and do not necessarily make sense for a bi-weekly demo. Instead, the team decided to structure their demo to focus on three things:

• Long-term trends with changes they have released over the past weeks and months
• New changes they have introduced (or are introducing) with hypotheses and predictions related to standard business KPIs
• Internal and external customer feedback and testimonials

To make the demos more engaging, the team decided to invite some of their internal customers to the demo to show off the particular changes that have made their lives easier.

Dry-Runs

Just as important as shipping new features, it’s important to treat the demo as part of the team’s output. And just like newly-launched features, demos deserve review and polish as well. Consider hosting a Demo Dry-Run for the presenters before the actual event.

Identify a few individuals within or outside the team to offer feedback about the proposed demo. Prioritize those with strong presentation skills themselves who are also capable of giving clear, constructive feedback. Understanding the material and context beforehand is valuable in giving feedback that is both stylistic and structural. Look for feedback on timing, content, readability, and delivery.

One piece of feedback you may receive is that the story just isn’t compelling enough yet. This is ok. While predictability is important, on occasion it may be advantageous to cancel the scheduled demo if it means that the next demo has an even more powerful story to tell.

The demo is a quintessential component for enabling a team to tell their story and outwardly represent their team’s culture and achievements. Yet, so many teams approach their demo reactively and lose this valuable opportunity. By reframing their demos as a cornerstone of the execution process, teams can craft a long-running narrative to keep their audience engaged and coming back for more.