Live Product Demo Checklist: 25 Checks Before You Share Your Screen

Focus is about what's visible before you even start talking. A live demo competes with everything else on the screen — a stray notification, a bookmarks bar full of unrelated links, a dozen open tabs — and every one of those is a small, free distraction from the thing you actually want your audience looking at.

• Bookmarks bar and browser toolbar clutter are hidden or removed

  A visible bookmarks bar tells your audience where else you've been, which is rarely the story you want to tell mid-demo. Hiding it takes one click in most browsers and it's easy to forget.

• Extension icons and unrelated toolbars aren't visible

  Separate from the bookmarks bar: the row of extension icons next to the address bar. A password manager, a dozen browser tools, or a company-internal extension all say "this is someone's everyday work browser," not a prepared presentation.

• Notifications are silenced at both the OS and app level

  Muting Slack inside Slack isn't enough if the OS still pops up a banner. Check both — a well-timed calendar reminder or a personal message showing up mid-sentence is one of the most common live-demo embarrassments.

• The correct tab or window is loaded and ready before you start

  Loading the product live, in front of the audience, adds dead air and risk. Have it open, logged in, and on the right screen before you go live.

• Unrelated tabs, apps, and windows are closed

  Not just hidden — closed. Alt-tabbing past a personal email tab, or a screen-share picker showing fifteen windows, both undercut the same thing: the sense that this is the one thing you meant to show.

If you're on camera at all, how you show up is part of the demo — not a separate concern from the product. A webcam bubble that's an afterthought (badly framed, blocking the one button you're about to click) actively works against the thing you spent the other four dimensions preparing.

• Webcam framing is checked — centered, not oddly cropped

  A quick look before the call catches the two most common problems: the top of your head cut off, or your face pushed to one edge of the frame.

• Webcam position and size are a deliberate choice, not whatever the default happened to be

  A camera bubble that's too large competes with the product for attention; too small, and it stops doing its job of keeping you personally present. Pick a size and position on purpose, once, rather than accepting whatever your meeting tool defaults to.

• Lighting and background contrast are acceptable on camera

  You don't need a studio setup — you need to not be a silhouette against a bright window, and not blend into a dark background behind you.

• Microphone and audio levels are checked

  A demo can survive imperfect video. It rarely survives audio your audience has to strain to hear, or that clips and distorts every time you raise your voice.

• Your presenter placement doesn't cover important product content

  The single most common presence mistake: a webcam bubble sitting directly on top of the button, field, or number you're about to point to. Check the specific screens you'll actually show, not just an empty one.

Clarity is whether the thing you're demoing is actually legible to the person watching a compressed video call on a laptop, not whether it looks fine on your own monitor at your own desk. This is the dimension most existing demo advice skips entirely — it's treated as a given, and it usually isn't.

• Product UI text is legible at the resolution your viewer will actually see

  Screen-share compression and a viewer's smaller window both work against small text. If you'd have to squint at a shared recording of your own demo, so will they.

• Zoom is set for a remote call, not your own screen

  Your browser's zoom level, and your product's own UI density if it has one, should both be tuned up from whatever's comfortable when you're sitting six inches from your monitor.

• Content is framed on purpose, not just whatever the window happens to show

  A maximized browser window showing mostly empty page around a small product interface reads as unprepared, even if everything else is clean. Framing the content deliberately is the difference between "a shared tab" and "a presentation."

• The cursor/pointer is easy to follow when it matters

  When you're about to click something specific, a tiny default cursor against a busy interface is easy to lose. This matters most in exactly the moments you most need the audience's attention.

• Distracting empty space or clutter around the content is minimized

  A product interface floating in a sea of blank browser chrome, or crowded against unrelated page elements, both pull focus away from what you're actually presenting.

Safety is about what could go visible that shouldn't — real customer data, an internal tool, a message that pops up at the wrong moment. This is the dimension where the cost of skipping a check is highest and least reversible: once something sensitive has been shown live, it's been shown.

• Sensitive tabs, apps, or data are closed or hidden

  This is about what's around the demo — other open tabs, apps, or windows with anything you wouldn't want seen, closed or hidden before you start, not discovered mid-alt-tab.

• The data visible during the demo is appropriate to expose to the audience

  This is about what's inside the product itself. Real customer names, real financial figures, or another customer's account are all things worth checking for even in a screen you've shown a dozen times before. Demo or test data is the simplest way to make this a non-issue, where it's practical.

• The demo environment is isolated from unrelated personal or work browsing state

  A browser signed into your personal accounts, with your everyday history and autofill, is more likely to surface something unintended than a separate, demo-only environment. A dedicated Chrome profile is one straightforward way to get this; it isn't the only one.

• Login/session state is checked so you don't hit an unexpected auth screen live

  An expired session forces you to log in live, in front of the audience — at best a delay, at worst a moment where the wrong account's data is one misclick away.

• You have a fallback for the riskiest live step in the demo

  Every demo has one step most likely to go wrong — a live integration, a flaky network call, a feature still being polished. Know what you'll do if that specific step fails, before you're standing in front of someone when it does.

The first four dimensions describe what "ready" looks like for one call. Repeatability is whether you can get back to that same state without rebuilding it from scratch every single time — because most people don't give one demo, they give the same demo dozens of times, and rebuilding readiness from zero each time is where all of the other four dimensions quietly slip.

• Your presentation setup is documented or saved so it can be recreated consistently

  This can be a written note of your settings, a saved browser profile, or a tool that stores the setup for you — TabStage's saved scenes are one option, not the only one. What matters is that you're not reconstructing the same setup from memory before every call.

• Visual presentation stays consistent call to call

  A prospect who sees a different framing, background, or webcam placement every time reads it as improvised, even if the product itself hasn't changed at all.

• You have a repeatable pre-call routine, not an ad hoc one

  The other 24 checks are only reliable if you actually run through them the same way every time — a short, consistent routine beats remembering to "do the usual stuff" from memory.

• You've rehearsed the run-through at least once before showing it live

  Not the whole sales pitch — just the mechanical path through the product you're about to click through live, once, recently enough that muscle memory still works.

• You have a recovery plan for the failure most likely to happen

  Different from check 20's single riskiest live step: this is your general plan for when something goes wrong anyway — a rehearsed line, a fallback screen, a way to keep going without the moment derailing the whole call.