Choose a Product Demo Scenario That Shows a Real Workflow

By pitch.dogFoundation11 min read20 September 2026

Business

Pick one task the person in front of you already recognizes. Show where that task starts, what someone does, what the product changes, who has to pick it up next, and where the product's involvement ends. Then stop.

That last step is the one presenters rush. A boundary feels like a confession — something to get past before the impressive part. It works the other way. A demo that shows its own edge tells the viewer which of their questions the product can answer and which ones belong somewhere else. That is the difference between a demonstration and a pitch that happens to involve a screen.

The alternative is a tour. The tour visits the dashboard, the settings page, the supplier list, the reporting view, the integrations page. Every stop is real and every screen works. What the viewer carries away is a vague sense that the product has a lot in it. Ask them afterward what it does, and they describe a menu. Ask them what it would change about their week, and they guess.

A demo should let them answer the second question. Everything below is about choosing the scenario that makes that possible, and about being honest about the conditions inside it.

Start from the task, not the feature list

Two people can watch the same product and need two different demonstrations.

An investor is asking whether the problem is real, whether anyone pays to solve it, and whether this team's approach holds up. A buyer inside a company is asking something narrower and more practical: if we adopt this, what changes on Monday, and who has to agree before it does? The same three features can serve both conversations — but not in the same order, and not with the same ending.

So before choosing a scenario, write down the decision the room is about to make. Not "they'll see the product." The actual next step: another meeting, a pilot, a budget line, a signature. Peter Kazanjy's 2015 essay on demo scripting for founders makes the case for contextual use cases and a connected workflow rather than an unrelated feature tour. That's a sequencing method from a first-person account, not a measurement of what demos achieve — it tells you how to arrange the hour, not how much the arrangement earns you. Treat it that way and it's useful.

Then name what finishing the task looks like. Not finishing the app. If the task is "get twelve broken chairs replaced," the end is chairs ordered and a purchase order out the door, not a successfully navigated settings screen.

Choose one task. This is where most presenters flinch, because they have four good ones. Four tasks in one sitting produce a viewer who remembers none of them clearly.

The example we'll use

The rest of this article works through a fictional scenario, invented here so the details stay consistent and nothing has to be dressed up as a real deployment. No working product was run for it and no timing was measured.

A company called Meridian Labs — also invented — has about sixty people. Dana runs the office. Twelve chairs on the second floor have broken backs, and she needs replacements. The purchasing tool in the demo has a supplier catalog already loaded with the chair at $310 each, and three configured thresholds: requests under $2,500 approve automatically, requests from $2,500 to $10,000 go to a manager's approval queue, and anything above $10,000 goes through the finance team's process outside the tool.

Dana's request comes to $3,720. That number matters, because it decides which path the request takes. Everything downstream follows from it.

Establish the starting state before the first click

A viewer who doesn't know what's already set up can't tell what the product is doing. They'll attribute your preparation to the software.

Say the setup out loud. The supplier import happened before anyone walked in. The thresholds are configured. Dana is signed in as a requester, and Priya from finance is signed in as an approver. One sentence covers the parts nobody came to watch: "This supplier list was imported last week, and I'm not going to spend our time there." That's not an evasion. It's a summary with a label on it.

Then decide what you're showing: a request entered live, or a record opened from a prepared state.

Both are legitimate, and they demonstrate different things. Typing the request demonstrates the input — the form, the fields, what Dana has to know to fill it in. Opening a prepared request demonstrates the machinery downstream of input. If you open a prepared record, say so. The failure mode is a presenter who types nothing, opens a request that was created yesterday, and lets the room assume the product produced it. The room may leave believing the hardest part is easy.

Permissions deserve the same treatment. If Priya approves, the demo needs an account with the approver role, and the viewer needs to know that's a role. Otherwise somebody reasonably concludes that any requester can approve their own request, and you've shown a rule that doesn't exist.

Follow the action, the response and the consequence

Now the causal path, in three parts.

Dana submits. Twelve chairs, the model from the catalog, the second floor as the location. The relevant detail is that the request matches a catalog entry, which is why a price attaches to it at all.

The tool responds. It finds the catalog item, multiplies by twelve, arrives at $3,720, applies the threshold, and routes the request into the approver's queue with the reason attached — above the automatic limit, below the finance review line. What Dana can now do: watch the status. What she cannot do: push it forward. That constraint is the product's contribution, and it should be visible rather than mentioned.

A person picks it up. Priya opens the queue, sees the request with its total and the reason it landed there, and approves it. This is the handoff, and it's manual. Do not narrate it as though the tool decided. The tool routed; Priya decided. That distinction is exactly the kind of thing a buyer needs to be able to repeat to a colleague.

The consequence. The purchase order goes to the supplier. Dana's request now shows that the order has been sent. And here the tool's knowledge stops: it can tell you the order went out. It cannot tell you the chairs will arrive on Tuesday, or that they'll be the right ones. The supplier is an external dependency, and pretending otherwise sets up a conversation you'll lose later.

The temptation at this point is a detour. There's a spend-by-category chart two clicks away and it's genuinely good. But if the presenter opens it mid-path, the viewer now has two threads to hold, and when you come back — "so, back to the chairs" — you've spent an explanation on reconnecting. The detour doesn't just cost time. It breaks the causal chain the viewer was following, and reconnection is the expensive part. That chart may be the right thing to open. Just not here.

Include the limit that changes the evaluation

Now Dana tries the floor refresh: twenty-four chairs at $310, six desks at $900, a total of $12,840. The tool declines to route it. It names the threshold it exceeded and points to the finance process, which lives somewhere else.

Stop the demo there.

That's a better ending than a clean success, because the viewer's next thought was going to be "what happens when it's bigger?" — and now the answer is sitting in front of them, in the product, with a hard stop. Answering that in the demo costs you thirty seconds. Answering it in Q&A costs you the credibility of your earlier answer.

The stop does something else too. It shows that the tool is not pretending to be the entire procurement process. A product that visibly knows its edge is easier to trust about everything inside it.

What the demo can and cannot be evidence of

When you describe conditions to the people watching, four labels do a lot of quiet work.

Real — it actually happened in the session. Dana's request was typed. The threshold fired. The queue updated.
Configured — someone set it up before you arrived. The $2,500 and $10,000 thresholds, the supplier catalog, the category mapping. These will behave differently in the viewer's own configuration.
Simulated — invented or sandbox material standing in for something live. A sample supplier, a test email address, a masked customer name.
Manual — a person did it. Priya's approval. Not the product.

Meridian's thresholds are configured. Nobody should leave thinking the product has an opinion about $10,000, or that its supplier prices come from somewhere other than an import you ran. Say the labels plainly and you avoid most of the misunderstanding.

What the demo cannot be is evidence of reliability, typical time savings, or what happens across a customer base. One successful run is one run, through a path you chose. That's the honest ceiling on what any demonstration shows, and it doesn't weaken it. It just means the sentence after the demo ends should be "here's what this would look like with your rules," not "so you can see it works."

Rehearse the explanation, not the clicks

Walk the exact sequence out loud before you deliver it, and listen for narration that only names controls. "I'll click here, then here, then this dropdown" describes your hands, not the task. What the viewer needs is why each step is happening.

Then test it: could someone who didn't see the demo describe the task, what the product did, and what remained for a person? If they can't get the handoff, it's buried. If they can't get the task, the scenario was too clever.

Check the state you're starting from, too. A previous rehearsal can leave the request already approved, which quietly removes the most interesting moment from the demo.

And watch your final sentence. "So you can see it works" closes a door. Better to end on the thing you genuinely don't know yet about their setup.

The script

For the Meridian example, the sequence is short enough to write on one page:

Starting state, stated aloud. Supplier catalog loaded with the chair at $310. Thresholds configured at $2,500 and $10,000. Dana signed in as requester, Priya as approver.
Dana enters the request. Twelve chairs, second floor. Total comes to $3,720.
The tool responds. Matches the catalog item, applies the threshold, moves the request to the approval queue with the reason attached.
Priya approves. A person makes the decision. The tool routed it; she decided.
The result. A purchase order goes to the supplier, and the request shows that it went. Beyond that, the tool has nothing to say.
The limit. Dana tries the floor refresh — twenty-four chairs and six desks, $12,840. The tool declines to route it and names the threshold. The demo ends on the refusal, not on a success.
The unresolved question, put to the room. "Your approval path probably isn't one manager and one queue. Where does a request like this actually go in your company, and where's the line above which this stops being the right tool?"

That last question is the point of the whole exercise. A demo earns its place by making one contribution visible, in a task the viewer already has, under conditions you've labeled honestly. The boundary isn't the part to hide. It's what makes the rest believable.

Frequently asked questions

How do I choose the scenario for a product demo?

Start from one task the person in front of you already recognizes, and from the decision the room is about to make — an investor and an internal buyer are asking different questions, and the same features serve them in a different order with a different ending. Name what finishing that task looks like, not finishing the app: for replacing twelve broken chairs, the end is chairs ordered and a purchase order out the door. Choose one task. Four good ones in one sitting produce a viewer who remembers none of them clearly.

Why end the demo on a request the tool refuses?

Because the viewer's next thought was going to be what happens when it is bigger. Answering that inside the demo costs about thirty seconds; answering it in Q&A costs the credibility of your earlier answer. The stop also shows that the tool is not pretending to be the entire procurement process, and a product that visibly knows its edge is easier to trust about everything inside it.

Is it acceptable to open a prepared request instead of typing one?

Both are legitimate and they demonstrate different things. Typing the request shows the input — the form, the fields, what the requester has to know to fill it in. Opening a prepared request shows the machinery downstream of input. If you open one, say so. The failure mode is letting the room assume the product created the request, which can leave them believing the hardest part is easy.

What do the four labels — real, configured, simulated, manual — cover?

Real means it actually happened in the session: the request was typed, the threshold fired, the queue updated. Configured means someone set it up before you arrived — the two thresholds, the supplier catalog, the category mapping — and those will behave differently in the viewer's own configuration. Simulated means invented or sandbox material standing in for something live. Manual means a person did it: the approver's decision, not the product. The tool routed; she decided.

What can a demo not be evidence of?

Reliability, typical time savings, or what happens across a customer base. One successful run is one run, through a path you chose. That is the honest ceiling on any demonstration, and the sentence after the demo ends should be 'here's what this would look like with your rules,' not 'so you can see it works.'