Launch Control — product requirements

Product brief

Problem. Launch readiness is often scattered across checklists, chat, status documents, and meetings. That makes it difficult to answer the questions that determine a responsible decision: who owns each dependency, what evidence proves a required check, why was Go granted, and what response followed a post-launch issue.

Opportunity. Give a B2B SaaS launch lead one inspectable local workspace that turns readiness policy into visible rules and preserves the decision trail.

Product decision. Launch Control models a disciplined launch conversation. It deliberately stops short of deployment orchestration or incident management: every action, person, evidence record, and outcome is fictional and device-local.

Restore, input, and export contracts

The browser session preserves incompatible saved JSON until the reviewer explicitly chooses Reset sample; the app shows the sample plan for continued review and does not overwrite the raw payload on mount. Evidence and decision rationale each accept at most 500 characters in the UI and in restored-plan validation. A pre-launch saved Go is accepted only when current required gates still pass; otherwise the saved session is rejected as inconsistent so an old approval cannot bypass a blocker. Export notices describe the plan at the moment of export and clear as soon as a plan edit changes that snapshot.

Users and job to be done

User	Job	Evidence needed before acting
Product or launch lead	Decide whether a simulated launch can proceed	A named owner, ready dependency, completed required check, evidence, and recorded decision
Functional owner	Supply readiness information and see the effect of a missing prerequisite	The dependency state, related locked check, and the blocker explanation
Review participant	Reconstruct the decision and response sequence	A timestamped timeline of decision, launch, and sample-incident events

Scope, constraints, and principles

Launch Control uses fictional Northstar sample data. It has no production connection, authentication, deployment action, traffic control, source-control integration, messaging, paging, paid service, or real incident response. Browser storage and exported JSON stay local to the device.

The product follows four principles:

Readiness is a rule, not a score. Required gates cannot be bypassed by an aggregate percentage.
A decision needs evidence. Mandatory checks need an owner, completion, and nonblank evidence; Go also needs a rationale.
A cleared gate can regress. Removing required evidence or changing a required dependency withdraws Go permission and requires a new decision.
State changes must be inspectable. The local timeline shows decisions, changed-evidence snapshots, the simulated launch, and the required sample-incident response; unchanged field focus does not create a record.

Core user story

As a launch lead, I can verify owners, dependencies, checks, and evidence before recording a decision so the simulated launch cannot proceed on incomplete information.

Primary workflow

Review dependencies and the blocker explanation for the seeded Analytics 2.4 sample launch.
Assign or confirm fictional owners, set dependencies to Ready, and complete the newly unlocked required checks with sample evidence.
Choose Go or No-go, record a rationale, and inspect the resulting timestamped decision.
Simulate the launch only after every required rule clears and a Go decision exists.
Trigger the sample post-launch issue, choose Pause rollout or Roll back release, then review or export the timeline.

Functional requirements and acceptance criteria

Requirement	Acceptance criterion
Model ownership and prerequisites	Every dependency has an owner and readiness state. A check whose dependencies lack an owner or Ready state remains locked and explains why.
Require evidence for mandatory work	A required check passes only when it is unlocked, has an owner, is complete, and contains nonblank evidence. Readiness changes immediately while one snapshot is recorded when a changed evidence edit is completed; optional checks do not change the launch rule.
Enforce the decision rule	Go or No-go can be recorded with a timestamp and rationale. Simulate launch is enabled only in pre-launch when every required gate clears and the current decision is Go; prerequisite controls become read-only once the simulated launch phase begins.
Handle regression honestly	If a required dependency or evidence regresses after Go, the Go decision is withdrawn, the timeline records that withdrawal, and a new Go decision is required after the blocker clears.
Make the response trail inspectable	Simulated launch and subsequent state changes appear in a local timestamped timeline with a distinct event identity. A sample post-launch issue requires either Pause rollout or Roll back release before it is resolved.
Support recovery and review	Sample reset restores fictional fixtures. The current readiness, decision, and timeline can be exported as local JSON with its phase, blockers, and fictional-simulation boundary. Storage failures are explained while the current tab remains usable.
Make the demo broadly inspectable	Hash navigation supports browser back and forward. Native labels, visible focus treatment, keyboard controls, responsive layouts, empty states, and errors are supported.

Acceptance examples at the decision boundary

Scenario	Current required behavior	Product interpretation
A dependency is Ready but has no owner	Readiness remains blocked and its dependent check remains locked.	Status alone does not establish responsibility.
Mandatory evidence contains only spaces	The check does not pass.	Presence requires nonblank text; the app does not verify the truth of that text.
Required evidence is removed after Go	Withdraw Go and append the withdrawal event.	A previous decision must not silently survive a changed prerequisite.
The missing evidence is restored	A new Go decision is still required before simulated launch.	Resolving a blocker is distinct from granting approval.
An optional check is incomplete	It does not enter the required-gate calculation.	Optional work cannot secretly become a launch prerequisite.
The launch has already completed	A second simulated launch is unavailable in that phase.	A launch action belongs to a particular state transition.
Saved records contain blank or ambiguous identities	Reject the stored session and show the known fictional launch with a warning.	Restored timelines and gate relationships must remain reconstructable.

Rationale and evidence are review inputs, not independently verified proof. Authenticity, approval permissions, and production policy enforcement remain outside this sample.

Enforced behavior versus review judgment

The sample enforces the sequence of required inputs: owner and Ready state for dependencies; unlocked, completed mandatory checks with nonblank evidence; a recorded Go before simulated launch; and withdrawal of Go after a required regression. It also requires an explicit pause or rollback after the sample issue.

The sample does not enforce whether evidence is true, whether a person has authority to approve, whether the release should proceed in production, or which incident response is operationally correct. For example, “Sample rehearsal notes” satisfies the presence requirement for the fictional check, but it is not validated proof. That distinction is part of the product contract, not a claim that the displayed text is trustworthy.

Explicit non-goals

Deployment orchestration, paging, traffic control, source-control integration, authentication, production incident management, notifications, approval permissions, and real launch data are outside this sample. A simulated launch must never be presented as a software deployment.

Evaluation plan — proposed, not measured

Research is staged. First, conduct five moderated formative sessions with product operations or release leads to identify workflow failures and refine the task; do not apply a percentage threshold to that small diagnostic sample. Then run a 20-participant task study using the same seeded scenario. Ask each participant to identify initial blockers, supply the missing readiness information, record a decision, launch the simulation, respond to the sample issue, and explain the timeline. Obtain consent and record task time, incorrect launch attempts, misinterpretations, abandonment, and confidence.

Evaluation question	Measure and denominator	Proposed target	Guardrail
Can a reviewer explain why launch is blocked?	Correct blocker explanations / all participants	18/20	No participant should believe the demo deploys real software.
Can a reviewer complete the gated flow?	Unassisted gated-launch completion / all participants	17/20	Record abandonment separately rather than omitting it.
Does the incident flow end with a decision?	Completed pause or rollback responses / all started incident scenarios	100%	The two sample response paths do not model a production incident program.

Automated checks verify the launch policy and controls; they do not establish human usability, demand, reliability, or business impact. No user research or production outcome is claimed.

Product integrity update · September 21, 2026

Launch Control exports must remain useful as a recovery artifact after the live session changes. The contract therefore records a schema version and serializes a detached plan snapshot. Timeline identity collisions are treated as no-ops, preventing duplicate audit entries during repeated actions. Reset also removes stale export feedback so the command surface describes the restored session.

All of these behaviors apply to the fictional browser simulation. No export or reset action operates a real release.