Skip to main content

Demos & Presentations

A demo is how a client sees the work they cannot read in a pull request. It earns trust when it is rehearsed and you can name exactly what the audience is looking at, and it loses trust the moment a bug surprises you on screen and you cannot say whether it is even a bug. That difference is almost never the code. It is the preparation.

Why this matters​

A sprint of solid engineering can be undone in a ten-minute demo nobody prepared for. Clients and stakeholders form their judgement of S&P from what they see on screen, so a demo where the presenter is caught out by a defect, or cannot say what the correct result was supposed to be, costs more trust than the defect itself ever would. Predictability and composure in front of an audience are part of the product, not a soft skill bolted on.

This section exists because we have paid that cost: demos where an unexpected bug appeared and nobody could say whether it was a bug or expected behaviour, where the scope of the session was never agreed, where no one owned the outcome. Owning your work (Integrity, Care, Teamwork) means being able to stand in front of an audience and account for every flow you show. This is how you get there.

The standard​

Know the scope before you prepare anything​

A demo can serve very different purposes: a quick touch-base, an internal review with a peer, a milestone sign-off a client's budget hangs on. The preparation is wasted if you do not know which one you are in. Pin down four things first:

  • The objective, in one sentence. "Show the checkout flow end to end so the client signs off on phase one." If you cannot write that sentence, you are not ready to schedule the meeting, let alone prepare slides. The objective decides everything that follows.
  • The audience, and its confidentiality level. Who is in the room determines what you can put on screen. An internal demo can show half-built screens and roadmap detail; a client demo cannot show another client's data, internal cost discussions, or unannounced plans. Decide the audience deliberately, and let the PM help you invite the right people (with reminders, and "optional" for those who may not make it).
  • What each stakeholder needs to see. Stakeholders work differently. Some want the detail, some want one diagram and the outcome. Prepare a dish for every taste (see the table below) rather than a single firehose.
  • The format and the clock. How long, online or in person, who else presents. Agree the time-box up front and ask someone to keep you honest on it during the session.

Write down ideas as rough notes the moment they occur, from the day the work starts, not the night before. Capturing thoughts early (a flow worth showing, a question the client will ask) turns demo prep from a blank page into an editing job, which is far faster.

Prepare until nothing on screen can surprise you​

This is the heart of the section and the part we have got wrong before. The goal is simple to state and demanding to meet: you should be able to predict exactly what the audience will see at every click, including where it falls short.

  • Know the expected result of every flow you will show. Before you demo a feature, pull its acceptance criteria and its Qase test cases and have the expected result in front of you. If you cannot state what "correct" looks like before you click, you cannot tell a bug from intended behaviour when it happens live, and that is precisely how we have ended up debating on screen in front of a client. Knowing the expected result is what lets you say "that is the bug" or "that is working as designed" with zero hesitation. This is the same definition-of-ready discipline from Estimation and Communication & Collaboration, applied to what you present.
  • Triage known issues before the demo, never during it. Run the exact flows you will present, on the exact environment you will present from, the day before. Keep a written known-issues list with the Jira ticket for each. A bug you already know about is "a known limitation, tracked as PROJ-123, fix is in this sprint." The same bug discovered live is a credibility hit. Owning the gap out loud always beats hoping nobody clicks it.
  • Demo from a stable, seeded environment. Present from staging or a dedicated demo environment with known, prepared data, not your half-broken local with three branches checked out. Pre-create the accounts, records, and state your script needs. Use feature flags to hide work that is not ready rather than navigating around it live (see CI/CD & Release Process).
  • Have a fallback for when the live system fails. Record a screen capture of the happy path, or keep annotated screenshots ready. Connections drop and environments wobble; a backup means a network blip becomes a five-second pivot instead of a dead-air panic.
  • Divide the work and assign roles. A demo is teamwork, not a solo act. Even a small one benefits from explicit roles, and nobody should be improvising who covers what.
RoleOwns
Presenter / narratorSpeaks to the objective, drives the narrative, owns the room and the session outcome
DriverShares the screen and clicks through flows, so the narrator can watch the audience instead of hunting for a button
TimekeeperSignals time remaining at agreed marks, so a long demo does not overrun
Question catcherWrites down every question, especially the ones you pin for later, so none are lost

On a small demo one person may wear several hats, but the hats should be named beforehand, not discovered mid-session.

A dish for every taste: tailor to the audience​

Read the room and prepare for the people actually in it. The same feature is a different demo for different stakeholders:

StakeholderWhat they care aboutLead with
Executive / sponsorBusiness outcome, risk, what is nextOne sentence of impact and one diagram, then stop
Product ownerDoes it meet the acceptance criteriaThe criteria, ticked off live against the working feature
Client / end-user proxyWhat it does for their usersThe user journey in plain language, technical detail kept in reserve
Technical peer / reviewerHow it works, where the risks areArchitecture, trade-offs, the corner cases you handled

You will not know exactly who turns up, so prepare the layers and pull up the one the room wants. Listen closely to what the decision-makers say and let it steer you: a nod toward detail or a glazed-over "so what does this mean for launch" tells you which dish to serve.

Write the script​

Turn your rough notes into an actual script and bold the beats that matter most. A script is not a crutch for the under-prepared; it is what lets you stay composed while a room of people watches you. It also forces you to confront the order of operations and spot the gaps before the audience does.

  • Open with a one-minute intro, if time allows. The single most important thing the intro does is state the objective of the session, so everyone is measuring the same thing. As a bonus it can handle the formalities (introducing whoever is presenting with you) and an icebreaker; a light, genuine opener sets the tone and settles your own nerves.
  • Script the demo flow click by click, with the expected result inline. "Click Export. You should see the file download within two seconds and open cleanly in Excel." Writing the expected result into the script is what keeps you in control when the live system does something else.
  • Anticipate the questions and prepare answers. Everyone in the room expects you to understand the implications of what you built. List the hard questions a skeptical client or PO would ask, and have answers ready. You will not predict all of them, and that is fine (see below).

Rehearse, and apply Nemawashi​

Two things separate a demo that lands from one that limps, and both happen before the meeting.

  • Get the script vetted by people you trust. Apply Nemawashi: socialise the demo with peers before it is live. They will tell you where the scope is off, where a flow is confusing, or where you are about to walk into a question you cannot answer. Peers give honest feedback because they know you take it on the work, not personally, and that feedback makes the whole team's demos better. If the room is genuinely surprised on the day, it usually means the scope was never socialised and nobody caught it.
  • Rehearse out loud, end to end, on the real setup. Reading the script silently is not rehearsing. Run it aloud, at least once on the actual environment you will present from, more if you are nervous or new to this. This is where you catch the flow that takes nine seconds to load, the data you forgot to seed, the transition that does not make sense out of your head. Rehearse the unhappy paths and the likely questions too, not just the golden path.

Run the demo​

  • Ensure a solid connection, especially when presenting remotely. Test screen-share and audio before, not during.
  • Follow the script closely. This matters most if you are early in your career, you present rarely, or you get nervous. The script gives you familiarity and a much higher chance of delivering what was asked without the stress of every eye on you triggering a blank.
  • State the expected result before each flow, then show it. "You should see the list re-sort instantly." Saying it first means the audience evaluates against the same bar you do, and a deviation reads as a known, owned thing rather than a fumble.
  • Read the room. Nods and agreement are signal to keep your pace; confusion or silence is a cue to slow down or change the dish. A well-vetted script is hard to be caught out by, so if the room looks lost, the scope was probably misjudged and it is worth pausing to recalibrate.
  • Handle questions you cannot answer cleanly: pin it. "Good question, I want to give you an accurate answer rather than guess. Let me note it and come back to you by end of day." Then actually write it down (that is the question catcher's job) and follow up. Bluffing an answer you are unsure of is the real failure, not admitting you will confirm and revert.
  • Ask for feedback at the end, and at key moments in a longer session. Do not save all feedback for the end of a forty-minute demo; check in at natural breaks.

Follow up in writing​

The demo is not over when the call ends. Send a brief, written recap the same day, to everyone who attended and the people who should have. Writing it down is evidence, it spreads the value of the session to those who missed it, and it reliably surfaces a second round of feedback. A good recap includes:

  • What was shown, in one short paragraph tied back to the objective.
  • Decisions made and sign-offs given.
  • Known issues acknowledged, with their tickets.
  • Open questions, each with an owner and a date (including every question you pinned during the demo).
  • What happens next.

Capture it the way the playbook captures any commitment: in the #[project-name]-client channel, an email, or a Confluence page, per Communication & Collaboration.

Critical thinking​

  • A demo is not a status meeting. If there is no working software to show, do not dress up slides as a demo. Be honest that it is a status update and say why, exactly as the sprint-review guidance in Communication & Collaboration requires. Pretending partial work is complete is the fastest way to lose a client's trust.
  • Hiding a bug almost always backfires. The instinct to route around a known defect and pray assumes nobody clicks the wrong thing. They will. Naming the issue first ("we know X, it is tracked, here is the plan") converts a landmine into evidence that you are on top of the work. Owning the gap is the stronger position, not the weaker one.
  • The script is a floor, not a cage. Follow it closely when nerves are high, but a presenter so locked to the script that they ignore a stakeholder's live reaction has missed the point of being in the room. The script exists to free your attention for reading the audience, not to replace it.
  • "I don't know, I'll confirm and come back to you" is a complete answer. Paired with a real follow-up, it builds more credibility than a confident guess that turns out wrong. The failure mode is bluffing, not admitting a gap.
  • Confidentiality is the presenter's responsibility, and it cuts both ways. A client demo is not an internal demo. Before you share a screen, know which environment, which data, and how much roadmap is safe for this specific audience. The wrong tab in front of the wrong client is its own kind of incident.
  • Over-rehearsing only the happy path makes you brittle. A demo polished to a mirror shine on the golden flow can shatter on the first off-script question. Spend rehearsal time on the unhappy paths and the awkward questions, because that is where live demos actually go wrong.

Checklist​

Before the demo​

  • The objective is written in one sentence and shared with everyone presenting
  • The audience and its confidentiality level are decided; the right people are invited (with reminders)
  • For every flow you will show, the expected result is known and written down (from acceptance criteria or Qase test cases)
  • Known issues are triaged into a list, each with its Jira ticket, ready to be named proactively
  • The demo runs on a stable, seeded environment (not local), with all required data pre-created
  • A fallback exists (screen recording or screenshots of the happy path)
  • Roles are assigned: presenter, driver, timekeeper, question catcher
  • The script is written, with key beats bolded and expected results inline
  • The script has been vetted by a peer (Nemawashi) and rehearsed out loud, end to end, on the real setup

During the demo​

  • Connection, screen-share, and audio are tested before starting
  • The intro states the objective; the session is time-boxed and tracked
  • The expected result is stated before each flow is shown
  • Every question is captured; ones you cannot answer are pinned with a follow-up commitment, not guessed

After the demo​

  • A written recap is sent the same day: what was shown, decisions, known issues, open questions with owners and dates, next steps
  • Pinned questions are answered by the date you committed to
  • Feedback from the demo and the recap is folded back into the work

AI tips​

  • Draft the script from the ticket and acceptance criteria. Paste the feature's tickets and acceptance criteria and ask AI to produce a click-by-click demo script with the expected result noted at each step. It is good at sequencing a coherent narrative; you then correct it against how the feature actually behaves.
  • Build the expected-result cheat sheet. Give AI the acceptance criteria or Qase test cases and have it produce a one-line "what correct looks like" for each flow you will demo. This is the artefact that lets you tell a bug from intended behaviour live, so it is worth generating and then verifying.
  • Generate the skeptical-question list. Ask "what would a demanding client or product owner ask about this feature?" AI is good at surfacing the obvious questions you are too close to see, so you can prepare answers instead of being caught out.
  • Translate technical talking points for the audience. Paste your technical notes and ask AI to rewrite them for a non-technical client, leading with outcome and impact. This is the same translation skill described in Communication & Collaboration, and AI does it well.
  • Draft the follow-up recap from your rough notes. Hand AI your scratch notes and the question catcher's list and ask for a structured recap (what was shown, decisions, known issues, open questions with owners). Then check it for accuracy before sending.
  • Do not let AI tell you what the live system will do. AI has no knowledge of your environment's real data or current bugs, so it cannot replace the dry run. Use it to prepare the words around the demo, never to assume what will happen on screen. The only way to know that is to run it yourself, first.

Resources​

S&P internal:

Playbook cross-references:

  • Engineering Principles -- ownership and professional conduct, the foundation of accounting for your own work
  • Estimation -- the definition of ready and knowing scope, applied here to knowing what "done" looks like on screen
  • CI/CD & Release Process -- demo environments and feature flags for hiding unfinished work
  • Observability & Incidents -- the blameless review model, applied when a demo goes wrong, and the principle that clear communication beats silence

External references: