Product risks: launch judgment
This is a prospective product-risk register for a fictional sample, not a report of incidents.
| Risk | Signal to observe | Response before further investment |
|---|---|---|
| A high readiness percentage substitutes for required gates | A participant says a launch should proceed despite a listed blocker. | Test the blocker explanation and the distinction between summary and permission. Preserve the required-gate rule. |
| Evidence text is mistaken for verified evidence | A reviewer assumes the app validated a URL, rehearsal, or claim. | Explain that current validation checks presence, not truth. A real workflow would need provenance and accountable review. |
| An old approval is treated as permanent | A participant expects Go to survive removal of required evidence. | Observe the withdrawal event and require a fresh decision in the scenario; reconsider wording if the transition is missed. |
| Simulation is mistaken for a deployment | A participant expects a button to change a real service. | Treat misunderstanding as a stop signal in the study. Keep all actions local and explicitly simulated. |
| A local timeline is treated as a compliance audit log | A participant assumes identity verification or tamper resistance. | State that browser storage is an inspection aid. Shared audit controls require a separately designed identity and retention policy. |
| An exported simulation is treated as launch authorization | A reviewer forwards the JSON as proof that a production Go occurred. | Put the fictional/no-production-action boundary and exported phase, decision, and blocker summary in the file and completion message. Treat any real-approval inference as a stop signal. |
| Incompatible saved browser data is silently replaced | A reviewer loses an older local plan after opening a newer build or hand-editing storage. | Preserve the raw payload, show the sample plan with a warning, and require an explicit reset before replacement. |
| Restored text creates an unusable or misleading decision state | Evidence or rationale exceeds the supported bound, or a pre-launch Go coexists with current blockers. | Enforce the same 500-character limits in controls and validation; reject inconsistent saved Go states and ask the reviewer to reconstruct the decision. |
| Export status describes an earlier plan after edits | A reviewer reads a success notice after changing a dependency or check. | Clear the notice on the first plan mutation and require a new export for the new state. |
| The two response options oversimplify incident management | A reviewer assumes every incident should pause or roll back. | Bound the exercise to its fictional scenario. Do not use it as an operational incident procedure. |
After formative sessions, prioritize any misunderstanding of evidence presence, simulation, or withdrawn approval before navigation, reporting, or template refinement. The product owner should record the corrective hypothesis, retest owner, and pass condition before the next scope decision. Risk reduction in a prototype is not proof of production reliability or compliance.