present

Demo, Pitch, or Update? Pick the Right Container

Published April 6, 2026 · 8 min read

Most presentation problems are actually meeting design problems. The presenter prepares the wrong kind of content for the situation, or no one has named what kind of meeting this is, so the presenter and the audience have entirely different ideas of what success looks like.

A demo that the audience was expecting to be a decision meeting leaves everyone feeling vaguely unsatisfied — the audience didn’t get a decision, and the presenter doesn’t understand why the great demo didn’t move anything. An update that the presenter hoped would generate enthusiasm produces the opposite — busy executives want a decision, not a status report.

The fix is choosing the container deliberately before you start preparing anything.

Who it’s for

ICs and leads who get pulled into meetings without a clear job-to-be-done, and people who consistently find themselves “presenting” without getting what they actually came for.

The three containers

Update

Job-to-be-done: Create a shared, accurate picture of current reality so that the people in the room are making future decisions based on the same information.

What good looks like: Everyone leaves with the same understanding of status, blockers, and risks. The “so what” is explicit — not a review of what happened, but a clear statement of what it means for what happens next.

What it is not: An opportunity to showcase effort, justify decisions already made, or generate enthusiasm for work in progress. An update that’s designed to make the team look good is not an update — it’s a performance.

Structure for an update:

1. Current state in one sentence — where are we against the plan?
2. What changed since last time — new information, new risks, new constraints
3. What it means — the “so what” that the audience needs to act on
4. What you need from the room, if anything — a decision, a clarification, a resource

An update with no “what it means” is a log. People can read logs; they don’t need a meeting for it.

Pitch

Job-to-be-done: Earn a decision or a concrete commitment to the next step.

What good looks like: The meeting ends with either an explicit yes, an explicit no, or an explicit path to one of those two outcomes with a named owner and date.

What it is not: A chance to share interesting information. A pitch that “went well” but produced no decision or commitment has failed its purpose. Many pitches are actually very good presentations that lack a clear ask — fix the ask, and the pitch often starts working.

Structure for a pitch:

1. The question you need answered (state it upfront)
2. The context that makes it the right question right now (brief)
3. The options with tradeoffs (at least two real ones)
4. Your recommendation with rationale (one recommendation, stated clearly)
5. The explicit ask — what you need from this room, today

Pitches fail most often because the presenter conflates being persuasive with being informative. Persuasion requires a clear ask. Information does not.

Demo

Job-to-be-done: Show what something does in a way that lets the audience connect it to a specific situation they care about.

What good looks like: At least one person in the room says some version of “how would this work for [specific thing we do]?” — which means they’ve made the conceptual leap from “this is interesting” to “this might be relevant to us.”

What it is not: A feature walkthrough. A feature walkthrough answers the question “what can this thing do?” A demo answers the question “what would it be like if we used this?” The difference is narrative: a demo must be anchored to a specific situation the audience recognizes, not a generic scenario you invented.

Structure for a demo:

1. Establish the situation — a specific, realistic scenario that mirrors the audience’s work
2. Run the demo inside that scenario — don’t break the narrative to show unrelated features
3. Name what changed — “before, this step took 4 hours and 3 people; after, it’s 20 minutes and one”
4. Stop — don’t keep going to show more features; end at the point of maximum relevance
5. Invite reaction — “does this match the way you’d approach it, or would it look different?”

A demo that ends with “any questions?” is leaving the most important part of the conversation undone.

Comparison table

Naming the container before the meeting

The most reliable way to run a better meeting is to tell people what kind of meeting it is before it starts. Not in the meeting title (“demo” is not a meeting type, it’s a format) — in the first sentence of the calendar invite or the first words you say:

“This is an update — I’m going to give you the current picture on [X] and flag two decisions we’ll need to make before the end of the month.”

“This is a pitch — I need a go/no-go on [Y] by end of day today.”

“This is a demo — I’m going to show you what [Z] looks like in a scenario similar to what your team deals with, and I want your honest reaction.”

When the audience knows the container, they show up with the right expectations. They know whether to be in decision mode, information mode, or evaluation mode. That single shift changes the quality of the conversation in the room.

Worked example

Three different meetings about the same product feature, requiring three different containers:

Monday with the engineering team: Update. “We’re at 60% of the migration, on track for Friday. Two risks: the legacy auth system doesn’t support the new token format, which will need a one-day workaround. And the staging environment is three weeks behind production, which means our test coverage has a gap. Nothing that changes the plan, but I want you aware before we hit those.”

Tuesday with the VP of Product: Pitch. “I need a decision on whether to ship with the legacy auth workaround or delay a week for a cleaner implementation. Here are the tradeoffs: shipping with the workaround gets us to market faster but creates technical debt we’ll need to address before we can add enterprise SSO — probably next quarter. Delaying gives us a clean foundation but means we miss the window for the partnership launch. My recommendation is to ship with the workaround and schedule the debt paydown explicitly. What I need from you today: your read on that call.”

Thursday with the enterprise prospect: Demo. “I’m going to show you what onboarding looks like for a new hire in a team your size — say, someone joining your operations team on their first week. Watch for where this intersects with the Workday integration you mentioned.” [Run the scenario.] “The part that tends to surprise people is that step four used to require IT involvement — now the new hire self-provisions. Does that map to how you’d handle it, or is your IT process different?”

Same product. Three different meetings. Three different containers. Three completely different experiences.

Common mistakes

Running a demo when you need a decision. Demos are intellectually satisfying and emotionally safe — you’re showing something real, people respond positively, and no one has to commit to anything. This is why people who are nervous about a decision meeting often accidentally run a demo instead. Notice the substitution and correct for it.

Doing an update when you need buy-in. Updates are informational; they don’t generate momentum. If you need people to care about something, an update is the wrong container. Name the decision you need and run a pitch.

Asking for two things. “We’re going to do a quick update and then I wanted to demo the new feature and also we have a decision to make” is three meetings compressed into one. Pick the primary container. Put the others in a follow-up.

Practice prompt

Look at your calendar for the next two weeks. Pick three meetings you’re running or presenting in. For each one, write down: what container is this? What is the one thing that would make this meeting a success? If you can’t answer those two questions in one sentence each, you’re not ready to prepare content yet.

Related reading

• The 12-Minute Arc — works inside any container
• The Stakeholder Heat Map — know who you’re pitching before you choose a container
• How to present data without losing the room — specifically for evidence-heavy updates and pitches