The Product Demo is the team’s demoable output at the end of the team’s week — not necessarily Friday. It is the concrete thing the team has committed to produce, and it is what the team brings into the BoardProduct BoardTwo or more stakeholders who see the team's weekly demo and coach it — the human in the loop, with no single lead. Meeting. Week Planning is, in the end, about this artifact: without a credible demo, the rest of the rhythm has nothing to anchor on.

The rule: live or concluded only

You present only work that is live in production, or research that has been concluded. Nothing else qualifies — no intentions, no “nearly done,” no mock-ups dressed up as real.

• Software is preferably already in production.
• Research, design, and interaction are backed up by test results and data.

Structure

Every slice of the demo answers the same three questions:

• What was the problem? Why this work mattered.
• How did we solve it? Shown via a screenshot, a graph, or a live demo — the real thing, working.
• What does the data say? The signal that proves or disproves the solution.

Come with a plan for feedback. The demo is the input to the discussion half of the Board Meeting, so frame each piece in a way the Product Board can react to.

Per discipline

Each discipline frames its slice the same way: the problem, the solution shown, and the data. The template below is the skeleton to fill in — one block per discipline.

Common pitfalls

• Demoing mock-ups, prototypes, or staging builds as if they were in production.
• Presenting research that has not actually concluded.
• Burying a non-result instead of capturing it as a Lesson Learned.
• Showing the build without any data on whether it worked.