Most showcase decks are written from the changelog. That is why they are dull. A changelog is ordered by merge date, and merge date is the one ordering that carries no argument. Order the same work by what changed for the person using the product and a third of the entries stop earning a slide.
Why does showing beat describing?
A described feature has to be taken on trust. A shown one does not, and the difference is audible: when a screen goes up, people read it before you finish the sentence. Spend that effect early. The image belongs on the slide where you name the feature, never in an appendix.
Slideable has content widgets built for this. A device mockup puts a capture in a frame, so a screenshot reads as a product rather than as a rectangle somebody pasted. A pull quote gives one customer sentence the whole slide instead of burying it as a bullet. A QR code turns the closing slide into a link somebody can follow from a chair six metres back. A logo wall does the adoption slide without a table nobody reads.
- One screen per slide. Two screenshots side by side means neither gets read.
- Crop to the thing that changed. Your sidebar, your tab bar and your notification badge are not the feature.
- Caption in the present tense, describing what the user does, not what the team built.
- If the screenshot needs a laser pointer, it needed a tighter crop.
Should you do a live demo or record it?
Live demos are the default because they feel braver. Price the bet before you take it. Say each demo works nine times in ten, which is generous given the wifi in most meeting rooms. Put four of them in one session and the chance all four run clean is 0.9 to the fourth: about 66%. One session in three ends with you apologising, and the apology is the part people remember.
A live demo is not more honest than a recording. It is the same claim with a one-in-three chance of collapsing while you make it.
The version that survives contact with a projector: record the happy path, play it in the deck, and keep the live build open in another window for the questions. You get the reliability of a video and the credibility of a running system, and you decide which one the room gets rather than letting the network decide.
- Record at the resolution the room projects at, not the one your laptop runs at.
- Cut every loading state longer than a second. It reads as slowness.
- No cursor hunting. The mouse should move like somebody who already knows where the button is.
- Twenty to forty seconds. Past that the room starts reading its phone.
Screenshot or mockup: which one?
Both, for different audiences. A flat screenshot is right when the room uses the product daily, because a frame around a familiar screen is furniture. A device mockup is right when the audience has never seen the product, or when the point is that it works on a phone. Framing says this is a product. Flat says this is a document.
The failure is the same in both directions and it is always the uncropped capture. A full window drags in browser chrome, a half-loaded avatar, somebody's test account named zzz, and a clock that dates the deck. Crop first, frame second. If a colleague cannot tell in two seconds what changed, the crop is still too wide.
How do you present work that slipped?
Say it, on its own slide, before anyone asks. The room is already keeping score, and the cost of them raising it is far higher than the cost of you raising it. A slip you announce is a status update. The same slip found in the Q and A is a credibility problem that follows you into next quarter.
Three parts, in this order: what it was, where it stands today, and the date it lands or the sentence saying it is cancelled. Give the reason in one line and make it a real one. Scope grew, the dependency was worse than we thought, we chose the other thing. All three are respectable. A passive construction with no subject in it is not.
A cut feature announced by the team is a decision. The same feature discovered by the audience is a cover-up.
Put it at slide fifteen, not slide eighteen. Late enough that the shipped work has been argued, early enough that the room leaves with your next commitments on screen rather than your worst news.
How do you build this without losing a week to it?
The 18-slide product showcase is one of 94 layout archetypes in the Slideable library, and every slot in it carries a maxChars budget: the length the box was drawn for. Treat that budget as the edit, not as a nuisance. A feature explanation that does not fit the box is usually two features wearing one name, and splitting it is the fix. Resizing the text is not.
Charts are the other place these decks rot. There are eight chart types, edited in place with no spreadsheet step, drawn in the deck's brand palette automatically. That matters more than it sounds: the adoption curve pasted from a screenshot of a dashboard is the wrong colour, the wrong typeface, and three weeks stale by the time you present it, and every one of those is visible from the back of the room.
It runs in the browser with no account, so the first draft costs you nothing. And an MCP server exposes 52 tools, which means an agent in Claude, Claude Code, Cursor, Codex, Gemini CLI or VS Code can read the deck, write to it and review it alongside you. That is worth more here than on any other kind of deck, because the agent is already sitting in the repository this one is about.
Common questions
- How many slides should a product showcase deck have?
- Eighteen is the right size for a quarter of shipped work presented in 25 to 30 minutes, which is roughly 80 seconds a slide. Three features get three slides each, and everything else is cover, claim, commitments, scoreboard, infrastructure, the slip, adoption, next steps and the ask. For a two-week sprint demo, cut to six: claim, two features with a screen each, what slipped, and what is next. The failure mode is not too few slides, it is one slide carrying three features.
- Should I do a live demo in a product launch presentation?
- Record the happy path and play the recording, then keep the live build open in a second window for questions. If a demo works nine times in ten and you run four of them, the odds that all four run clean are about 66%, so one session in three ends in an apology the audience remembers better than the product. A recording gives you the same claim with none of the network risk, and having the live system a keystroke away preserves the credibility people think they are buying with a live demo.
- How do I present a feature that did not ship?
- Put it on its own slide, around three-quarters of the way through, and say three things: what it was, where it actually stands today, and the date it lands or a plain sentence saying it is cancelled. Avoid the word de-prioritised, because every audience translates it back to cut and now distrusts the rest of the deck. A slip you raise yourself is a status update, while the same slip surfaced in questions becomes a credibility problem that carries into the next review.
- Should screenshots go in a device mockup or flat on the slide?
- Use a flat screenshot when the audience uses the product every day, such as an internal sprint demo, because a frame around a familiar screen only adds furniture. Use a device mockup for customers and for anyone seeing the product for the first time, and whenever the point is that it works on a phone. In both cases crop to the part of the screen that changed: a full-window capture carries browser chrome, test data and a clock that dates the deck the moment you present it again.
- What is the difference between an internal sprint demo and a customer product showcase?
- The internal version can assume context and should spend its slides on numbers, trade-offs and the unglamorous infrastructure work, because the room already knows what the product does. The customer version has to establish the problem before every feature and needs framed screens, a pull quote and a clear ask at the end. The order of the slides is the same in both, but the internal deck moves faster through the problem slides and slower through the scoreboard, and only the internal deck should show what slipped in full detail.