You Have a Demo Date. What Actually Needs to Work?

A demo date tells you when to show something, not what you can responsibly promise.

• Start with the decision the audience must make after the event. The software only needs to produce the evidence for that decision.

• A demonstration, a limited pilot and a production release create different commitments. Do not use the same acceptance criteria for all three.

• Choose one complete workflow. Label every dependency, data source and step as real, synthetic, simulated, manual or untested.

• Real customers create responsibilities that a presentation does not: access control, support, monitoring, recovery, data handling and an accountable owner.

• Write what the event does not validate. A clean walkthrough is evidence of the path shown, not evidence about every condition around it.

The deadline pressure is real. A conference slot, customer meeting or board review will not move because the product team wants more discovery. The answer is not to call whatever fits the date an MVP. It is to choose the smallest honest commitment the event requires, then make that commitment testable.

Ask one question before anyone estimates features: what should this audience be able to decide when the event ends?

A prospective customer may need enough evidence to join a limited pilot. An internal sponsor may need enough evidence to approve a larger investment. A current customer may need enough evidence to move a live workflow onto the product. Those are three different decisions, even when the calendar invitation says demo.

Write the commitment as one sentence: After this event, this audience should be able to decide whether to take this next step, based on this evidence. If the sentence names several audiences, several steps or several kinds of evidence, the event is carrying more than one commitment. Split it before you split the build.

This is where a deadline becomes useful. It cuts anything that does not change the next decision. A settings screen, a second user type or a polished dashboard may be valuable later. If the audience can make the intended decision without it, it does not belong in this event's acceptance criteria.

The label matters because it tells the audience what kind of commitment sits behind the software. Calling a prototype production does not make it safer. Calling a production dependency a pilot does not remove the responsibility created when a customer starts relying on it.

GOV.UK's alpha guidance, last updated May 8, 2019, draws a useful boundary: build prototypes only complex enough to test the riskiest ideas, keep them away from public use and expect that the code may be discarded. The government phases are not a timetable for your product. The useful part is the separation between learning from a prototype and operating a service.

A limited pilot sits between those commitments. Real, named users complete a real task inside a controlled boundary. The boundary is the product decision. It limits who can enter, which data they can use, how much dependence they can place on the result and what the team will do when something fails.

Production begins when customers are allowed to rely on the software as part of their work. That can be a narrow release. It still needs an operating owner, support, monitoring, recovery and a truthful account of the limits that remain.

The smallest useful scope is not the shortest presentation. It is the shortest complete path from a real starting condition to evidence the audience can use. A dashboard tour is not complete if the decision depends on where its numbers came from. A form submission is not complete if the decision depends on what an employee receives next.

1. Name the audience and intended decision

Be specific enough that another stakeholder can disagree. Prospective customers should understand the concept is vague. Three invited operating partners should decide whether to enter a pilot is better. The decision tells you how much truth the event has to carry.

2. Mark the start and finish of one workflow

Write the trigger, the people involved and the visible result. A supplier receives an invitation, submits a document and sees that it was approved is a workflow. Login, uploads, dashboard and notifications is a feature list. The first can be accepted. The second can only be toured.

3. Label what is real, simulated, manual or untested

A manual step is not automatically a problem. It may be the fastest honest way to learn whether the customer values the result. The problem begins when the audience believes an integration ran, a decision was automatic or a record was stored safely when a person staged the outcome behind the screen.

4. Set the data and access boundary

State whether the event uses synthetic data, approved sample data or live customer data. State who can sign in, who can see each record and what happens to the data afterwards. The boundary should tighten as uncertainty rises. Do not use sensitive data to make a demonstration feel more realistic.

5. Name dependencies, evidence, risks and owners

Every outside system, approval, account and person needed for the workflow belongs on the card. Record what evidence the event will capture, what risk remains after a successful run and who can accept that risk. If the owner is everybody, the decision still has no owner.

If those fields cannot be settled before the event, the missing work belongs in product discovery. Discovery should reduce the commitment or expose the dependency. It should not turn an unknown into a confident date.

This is an illustrative scenario, not a client story. A company is preparing a supplier-onboarding portal for an industry event. The core workflow is: a supplier receives an invitation, signs in, uploads a business document, and sees the review status after an employee accepts or returns it.

1. Demonstration level

Decision after the event: should selected suppliers be invited into a limited pilot?

The interface, sign-in and status change are real in a test environment. The supplier and document data are synthetic. The review email is triggered manually and labelled as manual. The document never enters the production record system. The audience can see the full proposed workflow and ask whether it matches how onboarding works.

The acceptance evidence is a successful end-to-end run, a record of where the audience hesitated and a list of assumptions that need a pilot. It does not validate real-data handling, the production integration, permission boundaries, support or reliability.

2. Limited-pilot level

Decision after the pilot: should this workflow open to the wider supplier group, change or stop?

A named group of invited suppliers uses real accounts and approved data within a written boundary. Authentication, document storage, employee permissions, email and status history are real. A support owner watches the pilot, failures are visible, and a manual recovery path keeps a supplier from being stranded. Any link to the official record system stays limited to the agreed pilot behaviour.

The evidence includes completion of the workflow, support questions, failures, manual interventions and whether the result gave staff enough information to make the next decision. The pilot does not prove broad capacity, every supplier variation or an unrestricted support model.

3. Production level

Decision before release: can eligible suppliers and staff depend on this workflow as part of normal operations?

Real users, real data and every dependency in the accepted workflow are operating. Access changes when a role changes. Monitoring shows whether invitations, uploads, reviews and notifications succeed. Support, retention, backup, recovery and incident ownership are named. The business has agreed what happens when the official record system or email provider is unavailable.

The evidence is no longer one successful walkthrough. It is the release acceptance, security verification appropriate to the data, production-like testing, monitoring, support readiness and a recovery exercise. Production still does not prove future demand or every later workflow. It proves that this released commitment can be operated.

A demonstration team is responsible for telling the truth about what the audience saw. A pilot team is also responsible for the people and data admitted into the test. A production team is responsible for the service continuing after the event, including the ordinary Tuesday when the presenter is not in the room.

GOV.UK's reliable-service guidance, updated January 29, 2026, names the operating work that appears once users depend on a service: regular quality assurance overseen by the team, production-like testing, monitoring and a sustainable response to problems. That list comes from public services, but the ownership change applies much more widely. Real use turns failures into customer events.

Security needs the same specificity. OWASP's Application Security Verification Standard 5.0, published May 30, 2025, provides testable technical controls for web applications. A rehearsed walkthrough does not exercise those controls unless the event was explicitly designed and independently checked to do so.

One person may hold several of these roles in a small company. The names matter less than the absence of a blank. The web application development guide goes deeper on permissions, errors, recovery and handover. This event decision should name the obligations, not duplicate the implementation guide.

A successful run proves that the exercised workflow reached the shown result under the stated conditions. It does not turn the surrounding assumptions into facts.

• Demand. Attention, praise or a request for a follow-up does not prove that customers will adopt or pay for the product.

• Security and privacy. A user signing in once does not prove role boundaries, data protection or resistance to misuse.

• Accessibility. One presenter completing the workflow does not prove that people using different devices, inputs or assistive technology can complete it.

• Data quality and migration. Clean sample records do not prove that historical or customer-supplied data will fit the same path.

• Reliability and capacity. One successful event does not prove sustained use, recovery after failure or behaviour when demand rises.

• Dependency behaviour. A staged response does not prove what an outside system will return, reject or change in production.

• Support and ownership. The presenter knowing how to recover the flow does not prove that the operating team can support it later.

Put the relevant limits beside the evidence, not in a private note after the event. The audience should not have to guess which part of the promise they just saw.

Use one card per event or committed workflow. It is deliberately narrower than a project brief and shorter than a release plan. Its job is to prevent an event from quietly changing the level of commitment.

Finish with one acceptance sentence: For this event, the workflow passes when this audience can produce this result using this data within this access boundary. These steps are simulated. This evidence supports this next decision. It does not validate these remaining claims. This owner accepts the unresolved risks.

If an existing build cannot supply the evidence on the card, the product readiness assessment helps separate what is known from what still needs checking. Do not turn the event into a rescue plan in the same meeting.

Before moving any feature into the event scope, make it answer one line on the card. If it does not change the intended decision or the evidence, move it after the event. That is how a fixed date becomes a useful boundary instead of a reason to pretend a demonstration is a release.