#21 Best Way To Show Progress Is To Demo
Five Reasons To Why You Should Demo More Often
Whenever I’m working on a project, I like to first break it down into milestones and see which ones can be shared in the form of demos with relevant stakeholders. This helps me build trust and manage expectations with them. But there’s more to it. Some of the top-performing teams I know or have worked with, believe in having a demo-driven culture within their engineering teams. Below, I’ll share five reasons why.
Examples of demos are:
Demoing a work-in-progress feature in a website / mobile app.
Using a Jupyter Notebook to call newly developed APIs.
Running a set of instructions on the terminal.
1. Fewer meetings
Time is an expensive currency. The more meetings you schedule to share updates, the more expensive it becomes for your technical delivery. Stakeholders can be internal—Engineering Managers, Directors, VPs, CTOs—or external, like new customers.
What if there was a way to cut down meetings to N-1 (or reduce their length) without losing the flow of information? In my experience, demos can do just that.
Say you have a 1-hour weekly meeting to share progress with leadership, with 40 people on the call. That’s 40 hours spent on that meeting every week.
What if we kept the updates short and sweet by demoing something that gives a clear status update without too many verbal details? So,
If we trimmed that meeting to 30 minutes, that’s 20 hours saved / week.
If we switched to a bi-weekly meeting instead, we’d get back the full 40 hours once every two weeks.
Think about how demos could help in your context. And ask around—would your team appreciate that?
2. Visuals
When preparing for a demo, it’s important to think about your audience and identify the key elements that will help you effectively share progress. One of those elements is visuals.
Most people generally enjoy visuals—they tend to engage more with project updates when they feel tangible, especially if they’re product-specific.
I’ve worked with product managers and designers who found visual demos invaluable, allowing them to pinpoint areas for questions or feedback without diving into technical details.
For example, the goal isn’t to explain how GraphQL works to non-technical individuals but to show how we’re using it to solve a problem—and what that looks like in practice.
That being said, visuals aren’t everything; they’re just one element to consider for your audience. Visuals help you explain:
The previous state
The current state
The future state
I once presented a demo to non-technical stakeholders by simply sharing my code editor and highlighting some Python and configuration files. It was well received—because I was able to clearly explain the three states above relevant to them.
3. Easy to share
One time I worked on a project where the main document was presented as:
# Milestone 1 # Milestone 2
- Goals - Goals
- Demo (link) - Demo (link)
# Milestone 2 # Milestone 4
- Goals - Goals
- Demo (link) - Demo (link)The way all the project details were centralised made it easy for anyone to follow up without needing to ask around. A recorded demo could be shared across multiple channels if needed, allowing stakeholders to skim through or speed it up to 2x when necessary.
Tip: This is one of the most effective ways to onboard new members onto a project.
4. Team engagement
While this point aligns with themes like inclusion and team empowerment, another key reason is to maximise team engagement.
Technical demos often require engineers to present their work. The goal isn’t just to share an engineer’s screen and click around to show progress. Rather, it’s an opportunity for engineers to explain their work and how it connects to the problem stakeholders care about. If engineers can articulate the purpose of the demo and how it functions, stakeholders can ask more specific questions—maximising team engagement.
5. Faster feedback loops
If I were asked to share a project update, some of my general options would be:
Writing a document and sharing it via email.
Scheduling a meeting and sharing it verbally.
Posting a TL;DR message on Slack/Teams.
Scheduling a meeting for a demo.
Sharing a recorded demo.
All of these are viable options, but their value depends on the situation and the type of people requesting the update. Sometimes, your manager just needs a one-sentence update for a slide. Other times, your users want a preview of that new feature.
Demos (4 & 5) are particularly useful for collecting feedback from both technical and non-technical audiences. If your goal is to share progress and gather feedback—do a demo!
Conclusion
Demos are not only a useful way to build trust and relationships with stakeholders; they also increase your project's success rate. Cultivating a demo-driven culture strengthens collaboration between technical and non-technical parties and brings clarity to discussions when delivering projects.
To recap, here are the five reasons:
1. 𝐅𝐞𝐰𝐞𝐫 𝐦𝐞𝐞𝐭𝐢𝐧𝐠𝐬: Demos reduce back-and-forth discussions with stakeholders.
2. 𝐕𝐢𝐬𝐮𝐚𝐥𝐬: People tend to engage more with visual updates.
3. 𝐄𝐚𝐬𝐲 𝐭𝐨 𝐬𝐡𝐚𝐫𝐞: A recorded demo/meeting can be shared across multiple channels if needed.
4. 𝐓𝐞𝐚𝐦 𝐞𝐧𝐠𝐚𝐠𝐞𝐦𝐞𝐧𝐭: Engineers can present their work to stakeholders and answer any immediate questions, maximising team engagement.
5. 𝐅𝐚𝐬𝐭𝐞𝐫 𝐟𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐥𝐨𝐨𝐩𝐬: Stakeholders can provide specific feedback much easier on the presented work, creating faster feedback loops.