Demoing an AI product is harder than demoing traditional software for one reason: the thing might not do what you expect in front of the room. Traditional software is deterministic, so a rehearsed demo runs the same every time. An AI feature produces a distribution of outputs, which means the live run can surprise you, and a fragile demo that only works on one memorized input falls apart the moment someone asks to try their own.
This is both a risk and an opportunity. Done badly, an AI demo exposes a feature that only works on the happy path. Done well, it demonstrates something a slide deck never can: that you built something real, that it holds up under a live input, and that you understand exactly where it is strong and where it is not. This is the structure that lands, whether the demo is a 90-second portfolio Loom or a live moment in an interview or a launch review.
Why AI demos are different
Two properties change everything. First, the output varies, so you cannot fully script it, and any demo that depends on one exact input is one unexpected question away from collapse. Second, the interesting part of an AI feature is often invisible, the eval that makes it trustworthy, the cost model that makes it viable, the guardrail that makes it safe, none of which show up in a screen recording of the happy path. A demo that shows only the output undersells the work and, worse, looks identical to a shallow prototype.
The structure below handles both: it survives a variable output and it surfaces the invisible work.
The 90-second structure
A tight demo has four beats. For a portfolio Loom, this is the whole thing. For a live demo, it is the spine you improvise around.
Beat 1, the problem, in one line (about 10 seconds). State the user problem the feature solves. Not the technology, the problem. "Support agents spend the first two minutes of every ticket drafting a reply from scratch." One sentence, then move.
Beat 2, the feature working, on a real input (about 30 seconds). Show it doing the job. Use a realistic input, not a cherry-picked perfect one, and let the audience see the actual output. This is the proof it exists and works. Keep it moving; do not narrate every field.
Beat 3, the invisible work, made visible (about 30 seconds). This is the beat that separates a PM who understands AI from one who does not. Show or state the eval that proves it is reliable, the cost per interaction that proves it is viable, and the guardrail that proves it is safe. "It holds 94 percent factual accuracy on a 60-case eval, costs about a cent per draft, and when it cannot find a relevant policy it declines rather than guessing." Thirty seconds here is worth more than any amount of output-gazing, because it demonstrates you built the parts that matter, not just the demo-able surface.
Beat 4, the honest edge (about 20 seconds). Name where it is not perfect and what you would do about it. "It is weakest on multi-part questions, which is the next thing on the eval set." Naming the limitation, rather than hiding it, is the single most credibility-building move you can make, because everyone in the room knows AI features have edges, and pretending yours does not reads as either naive or dishonest.
Ninety seconds, four beats, and the audience comes away knowing the feature is real, reliable, viable, safe, and understood by the person presenting it.
Handling the output that might embarrass you
The live-demo fear is that the feature does something wrong in front of the room. Three ways to handle it, in order of preference:
- Design for it, do not hide from it. If your feature has good guardrails, a wrong-ish input becomes a chance to show the guardrail working: it declines, it escalates, it flags low confidence. A feature that fails gracefully in a live demo is more impressive than one that only ever succeeds, because it proves the failure design is real. This is where the guardrails playbook pays off on stage.
- Use a realistic input you have tested, and invite a second one. Run your prepared input first, then offer to take one from the room. Willingness to take a live input signals confidence; a demo that refuses any input but the memorized one signals fragility.
- If it does produce something wrong, narrate it honestly. "That is a good example of the multi-part-question weakness I mentioned, here is how the eval catches it and what the fix looks like." A calm, informed response to a live failure often lands better than a flawless run, because it proves you understand the feature deeply.
The mindset shift: you are not demoing a feature that is always right. You are demoing a feature that is reliable enough, safe when it is not, and fully understood by you. That is a stronger thing to show, and it is demo-proof.
The mistakes that sink AI demos
- Only the happy path. One memorized input, a perfect output, nothing about eval, cost, or failure. Looks identical to a shallow prototype and collapses under a second input.
- Narrating the technology instead of the value. Spending the demo on how it works under the hood while the audience waits to see it do the job.
- Hiding the limitations. Pretending the feature has no weak spots. Everyone knows it does, and the pretense costs you credibility.
- Refusing a live input. Only ever showing the one input that works. The clearest possible signal that the feature is fragile.
- Skipping the invisible work. Showing the output but never the eval, cost, or guardrail, which is exactly the work that proves depth.
For the portfolio version
If this is a recorded portfolio demo rather than a live one, the same four beats apply, and the recording format lets you make the invisible work visible cleanly: cut to the eval results, show the cost number on screen, demonstrate the guardrail declining on an out-of-scope input. A 90-second demo that hits all four beats is a portfolio artifact that does what a resume line cannot, it shows the work rather than claiming it. It pairs directly with the artifacts in the AI PM portfolio projects that get you hired.
TL;DR
- AI demos are hard because the output varies and the important work, eval, cost, guardrails, is invisible in a screen recording.
- Use four beats in 90 seconds: the problem in one line, the feature working on a real input, the invisible work made visible, and the honest edge.
- Beat three, showing the eval, cost, and guardrail, is what separates a PM who understands AI from one who does not.
- Handle risky live output by designing for graceful failure, using a tested realistic input then inviting a second, and narrating any failure honestly.
- Naming the feature's limitation is the most credibility-building move, not a weakness to hide.
- The mistakes that sink demos: only the happy path, narrating tech over value, hiding limits, refusing live inputs, and skipping the invisible work.
The reason a 90-second demo can carry so much weight is that it compresses proof of real, reliable, viable, understood work into the time a resume line gets skimmed. In ShipSet, the program ends with exactly this: a working AI feature and a 90-second demo that shows the eval, the cost model, and the guardrail, so you finish with a demo that proves the work rather than one that hopes the happy path holds.