Singapore product workshops: identify what a restricted demo cannot prove

The problem

A Singapore product manager sees a successful prototype demonstration and treats it as evidence for an end-to-end service, although the environment disables the integrations required for the actual customer outcome.

Define the outcome beyond the screen

Write the event that must actually occur for the service to succeed: a payment recorded, a notification received or a downstream request created. List the systems involved in that outcome. A confirmation page may be only one step. Ask which parts the demonstration performs and which are mocked, disabled or represented by a preloaded example. Put the intended outcome beside the moment the screen changes. A form ending at a confirmation page and a request appearing in another service are separate observations. Name the particular dependency that connects them, and record whether its action was attempted. Choose a shareable learning question rather than listing every possible integration. Prepare the options and constraints for discussion, then establish which dependency the demonstration actually exercised beyond its visible interface. Check a button’s promised outcome separately from that observation.

Keep six fields for each required step

Record the intended outcome; input and environment; step or dependency involved; its stated demonstration state; observation actually available; and missing check. Distinguish a real action within the exercise, a supplied example, a simulated response and a disabled path. Write unknown when the presenter has not described the arrangement. A diagram connecting two systems shows a proposed relationship, not an observed transfer. Likewise, a record shown beside a screen may be preloaded or belong to another attempt. Retain the example identifier and origin needed to compare the observations, using wholly invented practice material or material the actual setting permits.

Use the environment’s documented boundary

OGP's FormSG self-hosting overview describes an evaluation demo with payment and webhook features disabled. That is an example of why an environment's purpose matters. It does not make the demo defective; it limits the conclusions you can draw from it. Read the actual demonstration conditions before planning stakeholder claims or choosing the next workshop. The recorded overview distinguishes evaluation, development, production and customisation routes. Its evaluation example describes forms expiring after three hours and disables payment and webhook features. Keep those conditions with that documented environment; they do not establish the restrictions of every other demo or the suitability of a production arrangement. An evaluation can answer a question about a visible flow while leaving the disabled path unexamined. Keep the environment’s stated limits beside each observation; a source description does not supply an observed transfer. Read the selected offer’s own environment description before preparing the claim you want feedback on.

• FormSG | OGP International ↗ · Source checked 20 October 2026

Trace a wholly invented request beyond its confirmation page

Every service, record and screen in this case is invented. A toy request labelled K2 is entered in a demonstration form. The example displays “Request received” on its final screen. Its setup note says the downstream connector is disabled. A destination panel also shows a request labelled K1, explicitly loaded before the K2 attempt. The observed K2 screen can establish that visible demonstration state; the earlier K1 panel cannot establish that K2 reached the destination. The card records K2’s form result, the disabled connector, the preloaded K1 origin and the missing K2 destination observation. Calling the whole service complete would skip the step the case has not exercised.

Prepare an evidence-gap table

For each required dependency, note the demonstrated behaviour, the unresolved question and the observation that would answer it. Include an unsuccessful or delayed response, not only the happy path. Use invented transactions and a safe environment for discussion. A product session should help prioritise which missing observation affects the decision, rather than demand a complete integration during the event. Use a question tied to the outcome: “This example shows K2 at the final screen, but the connector is disabled and the destination item is preloaded K1. What observation would distinguish a screen-only result from K2 reaching that destination?” That wording exposes the gap without demanding a live connection in a public room. Ask whether an appropriate supplied scenario, explanation of the dependency or permitted exercise can address it. Do not upload real requests or create a payment to make the demonstration more convincing. The missing observation is useful preparation even when the session cannot perform it.

Match a later observation to the exact claim it answers

Continue the wholly fictional account. A separate permitted learning scenario supplies a destination record marked K2 and states that it was created by the corresponding K2 attempt in that scenario. Under those stated toy conditions, the supplied record answers the destination-transfer question for that attempt. Record that it was supplied scenario evidence rather than your own executed integration test. It leaves notification delivery unexamined if the scenario provides no notification observation. A receiving record also does not establish every input, every retry or a production service. If the later panel instead shows K1 again or omits its origin, retain the K2 gap. Match identifiers and conditions before widening the conclusion.

Keep the absent or delayed result as an unresolved condition

If a learning example has no corresponding destination record, describe that absence within the stated observation window. Ask whether the supplied scenario defines a delayed response, an unattempted action or information still unavailable. A blank panel alone does not identify a defect or its cause. Distinguish the expected outcome, the actual observation and the explanation being proposed. Keep any suggested follow-up as proposed until an appropriate exercise supplies its result. For a recovery question, record which changed state the proposed rollback restores. For a handover question, inspect which records the receiving person can actually use. Keep those checks separate from the missing K2 transfer.

Choose feedback that changes the next test

Look for a practical product review or integration discussion if the unresolved question is outside the visible interface. Show the gap and ask what can be checked independently before connecting systems. Record a bounded next test and the decision it informs. Do not upgrade a peer's confidence, a prototype's appearance or event attendance into production-readiness evidence. Save the original card and the reply: which question was addressed, which evidence or explanation was supplied, which step remains unknown and the next decision it could inform. A strategy talk may help frame a trade-off without inspecting the connector; a practical review needs an actual permitted dependency discussion. Ask about participant activity and input before expecting individual help. In the invented K2 account, the destination question can become clearer while notification delivery stays open. Use Boardzip’s free product search after naming that gap, then confirm the organiser’s programme, preparation, access and any charges. Search availability and an encouraging comment supply no operational acceptance.