Running a Demo That Ends With a Decision
A demo exists to get a decision, not applause: show the path a real customer takes, ask the one question you need answered, and leave out everything that does not bear on it.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
What decision should the room make by the end of your demo?
The team lead says: "Can you demo saved carts at Thursday's review? Finance, support and the PM will be there. You have fifteen minutes."
Show everything that was built: start with how it works under the hood, walk through the feature, then the edge cases you handled. Rehearse so nothing breaks. End with "Any questions?"
The first five minutes are architecture. Finance and support drift before the part that concerns them, and the room's attention is gone by the time it matters.
- The first five minutes are architecture. Finance and support drift before the part that concerns them, and the room's attention is gone by the time it matters.
- "Any questions?" gets "Looks great!" and nothing else. The open question — keep saved carts for 30 days or 90, which has a storage cost and a privacy consequence — is never asked, and gets decided by default in the code.
- Showing every edge case invites detail conversations. The room leaves with five new requests about button copy and no decision on the thing that was blocking.
- A smooth demo on tidy test data hides what the room most needed to see: how the saved cart looks for a customer with twenty items, one of which has since gone out of stock.
What is really going on
- A demo is a meeting with a working thing in it, and a meeting needs an outcome. Applause is not an outcome; it is what the absence of one sounds like.
- People react to seeing it in ways they never react to a document. Support spots the confusing message; finance spots the discount shown twice. That reaction is the value of a demo, and it has to be pointed at the decision.
- Attention is front-loaded. The first two minutes decide whether non-engineers engage, so the problem and the question go there, not the architecture.
- What you show sets the agenda. Show an unfinished detail and the room will discuss it. Leaving things out is not hiding them; it is choosing what this meeting is for.
- A question with named options and a recommendation can be answered in the room. "What do you think?" cannot (Options, Not Answers).
Start from the question
Before choosing what to show, write down the one question the room should answer. Everything else in the demo is chosen to make that question easy to answer. If you cannot name a question, you may have an update, and an update is better as a message.
Thursday review. Finance, support and the PM are in the room, some half-watching laptops. You have fifteen minutes.
"So, saved carts! Let me start with a quick overview of how we store the cart server-side now, because it is actually quite interesting — we moved from session storage to a table keyed by customer…"
"Customers told support their carts were gone when they came back. Here is what happens now. At the end I need one decision: how long we keep saved carts — thirty days or ninety. Let me show you as a customer would see it."
What to show and what to leave out
The test for every minute is whether it helps the room answer the question. That usually means one realistic path, the awkward case that bears on the decision, and nothing else.
| Show | Leave out | Why |
|---|---|---|
| A returning customer finding their cart, with realistic items and prices | The table design and the migration | The room decides on what customers see, not on how it is stored. |
| The saved cart where one item has sold out since | Every other edge case you handled | This is the case that changes with 30 versus 90 days: the longer we keep carts, the more of them go stale. |
| What support will see when a customer asks about an expired cart | Unfinished screens and placeholder copy | Unfinished work becomes the topic; support's view is what makes the decision concrete for them. |
The ask
End with the question, the options, what each costs, and your recommendation — then stop talking and ask for the decision. Silence after a clear question is uncomfortable for a few seconds and usually produces an answer.
How long should saved carts be kept?
when Most returning customers come back within a few weeks, and we want to keep as little personal data as we can.
cost A customer returning after a month finds an empty cart; support needs a line for that.
when Purchases in this store are considered over months — furniture, gifts planned early.
cost More stale carts with sold-out items, more stored data, and a change to the privacy notice.
when Saved carts are effectively a wishlist and customers treat them that way.
cost Data kept indefinitely, which needs a retention decision from whoever owns privacy, not from this room.
After the demo
A decision made out loud in a room lasts about a week. The follow-up message is what makes it a decision: sent the same day, with the answer in the first line and the other feedback collected below it, so nothing raised in the room is lost (Writing for Stakeholders).
1**Decided at Thursday review:** saved carts expire after 30 days (PM, with finance and support).2 3**We will revisit if:** support sees customers looking for carts older than 30 days.4 5**Other feedback raised, not decided:**6- Support: sold-out message should link to similar items — added to backlog7- Finance: discount shown on saved cart should match checkout — bug, fixing this sprint8 9Architecture notes for anyone curious: <link>The decision and its owner go first; the revisit condition means nobody has to reopen it on a hunch.
How to do it
Most important first.
- Decide the question before you build the demo: "Should saved carts expire after 30 days or 90?" If there is no question, it may be an update, not a demo.
- Open with the problem and the question in two sentences, then show.
- Show one path the way a real customer would take it, with realistic data, including the one awkward case that bears on the decision.
- Leave out architecture, edge cases unrelated to the question, and anything unfinished that will pull focus. If asked, say "not in today's demo, happy to show you after".
- End with the options, the cost of each, your recommendation, and a direct request for the decision. Write it down in the follow-up the same day.
- Have a recording or screenshots ready in case the live version fails. The decision should not depend on the staging server.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Open: "Customers told support their carts were gone when they came back. This is what happens now. At the end I need one decision from you: how long we keep saved carts."
- Narrate for the people in the room, not for engineers: "Support — this is the message a customer sees if something in their saved cart has sold out since."
- Ask with options and a recommendation: "Thirty days or ninety? We recommend thirty. It covers the customers we see coming back, and we keep less personal data. Ninety needs a change to the privacy notice. Can we decide now?"
- Follow up in writing the same afternoon: "Decided at Thursday's review: saved carts expire after 30 days. We will revisit if support sees customers looking for carts older than that."
- "It is a review, not a decision meeting." Then I will ask the question and collect the answer in writing afterwards — but the people who can answer it are all in that room.
- "Show them the architecture, they will appreciate the work." I will link it in the follow-up for anyone who wants it. In the room, fifteen minutes goes to the decision.
- "What if they ask about something you left out?" I will say it is not in today's demo and show them after. That keeps the question on the table.
What can go wrong
- The demo as performance: tuned to impress, with staged data that hides the real problems.
- The ask too vague: "Thoughts?" collects opinions, not a decision.
- The ask too loaded: one option presented as the answer, the room asked to rubber-stamp it, and the objection arriving a week later by email.
- No follow-up: the decision is made in the room, not written down, and two weeks later three people remember three different answers.
- Demoing a prototype to people who then treat it as the product: "Great, so it ships Friday?"
- "A demo that went smoothly was a good demo." A demo that produced a decision was a good demo. Smooth is optional.
- "Showing more shows more progress." Showing more dilutes the question, and progress was never the point of the meeting.
- "Demos are for the end of a project." An early demo with one narrow question is cheaper than a late one with ten (The First Version That Teaches You Something).
Knowing whether it worked
- The follow-up message has a decision in it, with a name and a date.
- People outside engineering speak during the demo. Support raises the thing they would otherwise have raised as a ticket after launch.
- Fewer "I did not know it worked like that" messages after the launch.
- Stakeholders start asking to see things early — the sign that demos are where decisions happen.
- With many stakeholders, one demo cannot carry every question. Either pick the question for this room, or run separate short demos with different asks.
- Recorded demos for distributed teams work if the question is in the first thirty seconds and the way to answer — a thread, a poll, a deadline and default — is explicit.
- In a company-wide review your demo competes with a dozen others. The ones with a clear ask are the ones that get something back.
- Leaving out work the team is proud of can make people feel unseen. If that matters, give it a separate slot rather than diluting the decision.
- Focusing on one question defers other feedback. Some of it would have been useful, and you will get it later or not at all.
- Realistic data and a rehearsed path take preparation — often an hour or two you would rather spend building.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- TEAM-SPECIFICTeams with a regular sprint review can use it as the decision point. Teams working asynchronously need recorded demos with the question up front and an explicit deadline and default, or the decision drifts.
- PRODUCT-SPECIFICAn internal demo to stakeholders is a decision meeting. A demo to an external B2B customer is closer to sales, where showing breadth is part of the point — the question there is usually "does this solve your problem?", asked of the buyer.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.