Demo

When progress travels only as words, the same sentence keeps coming back. "It's 80 percent done" turns up three weeks running, week four brings "next week for sure," and in week six the feature still doesn't work. Nobody lied. The engineer didn't know either that the last 20 percent would take as long as the first 80.

What makes the sentence dangerous is that the listener can't check it. Sales passes the date to a customer, marketing builds a launch around it, and the founder repeats it to investors. By the time the claim turns out to be wrong, it has already traveled outside the company.

A demo moves that verification off personal credibility and onto the screen. Log in, press the button, watch the result appear, and what works and what doesn't becomes obvious without commentary. A percentage needs interpretation. A running screen doesn't. The team isn't asked to estimate better; the estimate is simply replaced with something anyone in the room can judge for themselves.

The whole thing is clicking through working software in a real environment. Everything else is structure that keeps it short and honest. Fifteen to thirty minutes is typical.

1. Choose what to show. There is one test: does it run right now when you click it. Design documents and mockups aren't material for this session, and there are other meetings for those.
2. Lay down one line of context. Something like "team admins couldn't change several members' permissions at once and had to open each person individually" — who was struggling and why. Without that line the audience watches a screen without knowing why it matters, and the feedback that follows lands on colors and wording instead of on whether the problem got solved.
3. Drive it live. A pre-recorded video or a clickable prototype removes the point of the session. A button that takes three seconds is information. An error mid-flow is information.
4. Say what doesn't work. "Changing permissions works, but nothing is logged and there's no undo yet" draws the boundary. Skip this and the audience assumes the rest is finished too.
5. Collect feedback without deciding on it. Write down what comes up, and handle what gets acted on in the session where priorities are set. Without that split a demo turns into an hour-long planning meeting.
6. Record what's left. Turn the feedback and whatever broke into a list with an owner and a date attached.

The process is deliberately thin. The moment preparation starts taking real time, teams begin postponing the session, and postponing brings back exactly the problem it was meant to prevent. If prep is running past half an hour, the team is usually building something to show rather than picking something to show.

Whoever built it drives it. When a product manager demos on someone else's behalf, the explanation stops at the first snag, and the audience can't tell whether the behavior is intended or unfinished.

On the watching side come the stakeholders — people affected by the outcome or able to affect it, which means sales, support and marketing, anyone who will have to explain this feature to a customer. Their presence pulls post-launch questions forward by several weeks. The moment support asks "what happens to existing settings?", a case nobody considered is on the table.

Two timings work. One is the end of a cycle: a team on two-week cycles shows what finished on the last day. The other is the day a feature first runs, without waiting for the cycle — pull three or four relevant people together and show it for five minutes. That second timing is where a wrong direction costs the least to correct. Change course after two more weeks of building and those two weeks are gone; change course on day one and you lose a day.

Too early and there is nothing to click, so the session fills with explanation. Too late and feedback arrives with no time to act on it. Reading it alongside the definition of done (DoD) — the shared standard for calling work finished — makes the timing easier to pick, and some teams put "demoed" inside that standard.

"Get it into a state we can put in next week's demo."

Not explainable in words, but clickable on a screen.

"Let's look at it in the demo and decide then. The document isn't giving me a feel for it."

Written discussion is going in circles, so judgment waits until there's something running.

"Heads up, the permissions part in the demo is still a mockup."

Warning in advance that part of what's on screen doesn't actually work.

Pagedeck runs a thirty-minute demo every other Thursday afternoon. One week Theo showed the enterprise permissions screen. Selecting several members and changing their roles at once went smoothly, until Sofia asked what happens when an admin removes their own admin rights. Theo tried it live and the screen froze.

That case wasn't in the design document or on the task list. A document review would have left it for a customer to find after launch, most likely as a support ticket from an account admin locked out of their own workspace. Noa sketched a warning dialog on the spot, and Mia wrote the feedback down and sequenced it in the next planning session rather than there. Deciding inside the demo would have spent thirty minutes that belong to other teams.

The most common mistake is preparing it like a presentation. Showing something to a room looks like presenting, so the instinct makes sense. Slides get made, the order gets rehearsed, and a path around the error-prone flows gets mapped in advance. Every one of those polish steps costs the session its purpose. Hide the snags and the audience leaves believing the work is finished, and a session that costs half a day to prepare is the first thing cancelled in a busy week. A demo with one error in it carries more information than a smooth one.

Believing only finished work qualifies is the other common reading. Set that bar and the first few weeks have nothing to show, the session gets skipped, and those weeks pass with the direction unchecked. A half-working screen is fine to put up. It only needs a sentence saying how far it goes. "The list loads and filters work, saving doesn't yet" is a complete and useful demo of three days of work.