Evolving the Demo Process

As a software engineer at Sketch, I work with a client to build an insurance policy visualization platform. The platform enables editing policies, building visualizations, and presenting key performance indicators across individual client dashboards. Our work follows two-week Agile sprints. We refine user stories, build features, and conclude with sprint reviews where we demo our progress to clients. This process is essential for showcasing our work and gathering feedback that shapes the product’s direction.  

Over time, we realized our demo process wasn’t as effective as it could be. This post reflects on how we identified the issues, made changes, and what we learned along the way.  

How We Used to Demo  

Initially, each developer presented their own user stories during the demo. The format was simple: we took turns on a Zoom call, sharing our screens and walking through what we had worked on. It seemed straightforward, but it had serious drawbacks.  

For one, the flow was disjointed. Each time someone switched screen sharing, there was an awkward pause. Developers often focused too narrowly on technical details, listing Jira story numbers instead of highlighting the value of the features. In one particularly rough instance, a developer rigidly walked through stories one by one. The client expressed their dissatisfaction, asking for a less formal, more cohesive approach.  

Identifying the Problems in Software Demos

We realized the issues stemmed from several key factors:  

• Lack of Cohesion: Demos felt fragmented, with developers focusing on their individual contributions rather than presenting the product as a whole.  

• Time Inefficiency: Switching screen shares and repeating introductions led to unnecessary delays.  

• Fatigue: Clients and developers alike found the process exhausting, with too much focus on minor details.  

Feedback from the clients reinforced what we already felt: the demo process wasn’t just inefficient; it wasn’t engaging either.   

Making Changes to the Software Demo Process

Our first step was to rethink how we presented the work. Instead of focusing on individual contributions, we started grouping user stories by areas of the platform. For example, one developer would demo everything related to a particular page or feature set, providing a more cohesive narrative.   

We also implemented a simple tool to streamline planning: a shared Google Spreadsheet. After each sprint, we exported completed Jira stories into this sheet and categorized them:   

• Yes: To be demoed. We select user-facing stories that impact the client’s day-to-day experience, focusing on changes that improve the UI or address key client-reported bugs likely to spark discussion. 

• Just Mention: For updates and bugfixes that aren't immediately visible, but still important. This includes backend or frontend work that lays the groundwork for future features. It also covers consistent updates across multiple pages—like adding a new filter to several tables—where we demo it once and mention where else it applies.  

• No: To be skipped. This includes backend changes, refactoring, and minor bugs that have no visible impact on the user experience. 

This approach kept demos focused and efficient, ensuring meaningful updates took center stage while technical details stayed in the background. 

More Efficient Process for Demonstrating Software Internally

As we refined the process, we went from having every developer participate in the demo to limiting it to two developers handling related sections of the platform. Eventually, when the sprint workload allowed, we moved to a single presenter. This presenter would gather input from the spreadsheet, consult with other developers if needed, and deliver the entire demo, creating a smoother and more engaging experience.  

The Results  

The new process transformed our demos:  

• Efficiency: Demos became quicker, with less downtime and fewer interruptions. This allowed more time for client questions and feedback.  

• Engagement: By focusing on major updates and grouping related stories, we created a narrative that made it easier for clients to follow along and understand the value of our work.  

• Satisfaction: Clients appreciated the streamlined approach. It reduced “demo fatigue” and led to deeper discussions about the platform’s features and direction.  

What We Learned  

• Focus on Value: Highlighting the impact of features, rather than technical details, keeps clients engaged.  

• Streamline Planning: A simple organizational tool, like a shared spreadsheet, can make a big difference in managing priorities.  

• Iterate and Improve: Just like the product itself, the demo process benefits from iteration. Feedback is invaluable.   

Conclusion  

Reworking the demo process has been one of the most impactful changes we’ve made in our Agile workflow. It’s not just about demonstrating what we’ve built—it’s about fostering a conversation with the client and ensuring that our work aligns with their goals. 

We shifted the focus of our demos to the value we provide over individual productivity. And while individual productivity is important, clients are ultimately more interested in how the end product serves them. 

If you’re struggling with disjointed demos or client fatigue, take a step back and evaluate your process. Sometimes, a few small changes can make a world of difference.