The single most valuable recurring meeting on a healthy engagement is the demo. It is where the sponsor sees real progress in working software, where you build trust by being honest about what is and is not done, and where new priorities surface before they become expensive. But a demo only does that job if it has a deliberate shape. This play is a reusable structure for the deck and the meeting — a format you can run every couple of weeks without reinventing it each time.

When to use this play#

Run this on any engagement where you are accountable to a sponsor, client, or stakeholder group for ongoing delivery — it is the feedback loop at the heart of the zero-to-one and scaling what works plays. Hold it on a steady cadence, typically every one to three weeks. The demo is a visibility checkpoint, not a planning gate and not a status meeting you could have sent as an email.

How to run it#

Build a short deck that frames the live software, then show the software. The deck has a consistent set of sections, each one a slide or two.

1. Title and window. Name the project and the exact date range this demo covers. Anchoring to a window keeps the conversation about this period's progress.
2. Completed spikes. Lead with the de-risking work you finished — the investigations, prototypes, and architecture questions you resolved. Sponsors rarely see this work, and surfacing it shows you are retiring risk, not just adding features.
3. Completed work. Walk what you actually shipped this window, framed as value delivered rather than tickets closed. If the list is long, let it spill onto a second "continued" slide rather than cramming it.
4. Up next. Show what is coming in the next window. This sets expectations and gives the sponsor a natural moment to reprioritize before you start.
5. Roadmap. Give a month-by-month timeline of the major workstreams with a clear status legend — for example Released, Complete, In Progress, and Future — and a visible "go-live" marker. This is where the sponsor sees the whole arc, not just the last two weeks.
6. Name the risks honestly. Add a short, plain callout for anything slowing you down — access issues, integration dependencies, an unresolved decision. Naming a risk on a roadmap slide builds far more trust than hiding it until it becomes a missed date.
7. Then demo the real thing. End on the live software. Let stakeholders see it working and, where you can, interact with it. The deck exists to frame this moment, not to replace it.

Common traps#

• Slides instead of software. If the demo never reaches working software, it has quietly degraded into a status report. The running product is the point.
• Listing tickets, not value. "Closed eleven stories" means nothing to a sponsor; "you can now do X" means everything.
• Hiding the risks. The roadmap slide that omits the slipping dependency is the one that destroys trust when the date moves.
• Treating it as a planning gate. Reprioritization is welcome, but the demo is for visibility; do not let it turn into a backlog-grooming session.
• No consistent window. When the cadence drifts, stakeholders lose the rhythm that makes progress legible.

Signals it's working#

The sponsor consistently sees working software and reacts to it, surprises at the roadmap level are rare because risks were named early, reprioritization happens in the open, and the demo feels like a trusted routine rather than a performance.