13 - Release Readiness Gates¶

Purpose¶

Define explicit go/no-go gate criteria for each major release milestone so launch decisions are evidence-based, cross-functional, and auditable.

Gate Framework¶

Gate ID	Gate Name	Milestone Link	Decision Type
G0	Discovery and requirement readiness	Pre-MVP scope freeze	Proceed / hold
G1	MVP scope freeze approval	2026-04-15	Freeze / rework
G2	MVP launch readiness	2026-06-01	Go / no-go
G3	MVP evidence gate	2026-08-31	Progress to MSP / iterate
G4	MSP feature completeness	2026-10-15	Complete / gap close
G5	MSP commercial launch	2026-11-15	Go / phased go / no-go
G5.1	MSP-R2 scale gate	2027-02-15	Go / hold

Visual Gate Controls (Agile + PMBOK)¶

Release Gate Timeline

PMBOK phase-gate control overlaid on Agile release cadence. Color shifts identify where risk tolerance changes across the program timeline.

Gate Criteria Readiness Board

A visual control board for gate meetings. It turns criteria into explicit decision signals and mirrors PMBOK quality-control checkpoints.

Tooling Examples For Gate Operations¶

Jira: implement a gate workflow (Gate Prep -> Gate Review -> Go/No-Go) with required approver and condition fields.
Azure DevOps: use pipeline environment approvals/checks so deployments are blocked until gate criteria are marked passed.
GitHub: treat branch protection, required status checks, and CODEOWNERS approvals as technical gate evidence.
Jama Connect / IBM DOORS Next: package requirement baseline, verification coverage, and review sign-off as a formal gate packet.

Industry Context: Gate-Based Release Decisions¶

Amazon applies gate logic before engineering begins, not only before launch. The Working Backwards process requires a written press release and FAQ (PR/FAQ) before a feature receives resourcing. If the team cannot write a compelling customer announcement for the feature, the feature does not get built. This is a pre-G0 gate: the criterion is whether the value proposition is defensible in writing, not whether the code passes tests. The artifact forces product clarity at the cheapest possible moment in the development cycle.

Spotify’s Squad Health Check model formalizes release readiness as a standing health dimension rated alongside quality of process, technical health, and team morale. Release readiness is assessed with a traffic-light system — green, amber, red — before each squad ships. It is not treated as a final checklist applied after development completes; it is a continuous signal reviewed throughout the cycle. That model is the direct precedent for the G3/G4 structure here.

Google Chrome enforces a Launch Readiness Review (LRR) for anything touching the user-visible web platform. Any P0 bug on the LRR blocks launch regardless of timeline pressure or executive escalation. The Chrome team has delayed major releases on this basis. That precedent is reflected in the rule in this framework: any failed P0 criterion blocks full go-live, without exception negotiated at the gate meeting.

Gate Criteria By Milestone¶

G0 - Discovery And Requirement Readiness¶

Entry criteria:

Top discovery assumptions validated for conversion, attendance, and continuity.
Requirements matrix contains IDs, priorities, CP tags, and owners.
Risk register linked to P0 and CP-Yes requirements.

Pass criteria:

P0 requirements have acceptance criteria and verification method.
No unresolved blocker in compliance, billing, or reliability domains.

Approvers: Product, Engineering, Tutor Ops, Legal/Security.

G1 - MVP Scope Freeze Approval¶

Entry criteria:

MVP backlog locked with signed requirement baseline.
Test plan and analytics instrumentation plan approved.

Pass criteria:

Scope variance <=5% from baseline.
All CP-Yes requirements staffed and scheduled.

Approvers: Product Council.

G2 - MVP Launch Readiness¶

Entry criteria:

Staging reliability, quality, and support runbooks completed.
Tutor staffing and continuity readiness verified.

Pass thresholds:

Critical defects open: 0
Sev-1/Sev-2 unresolved incidents: 0
Booking-to-first-session median <=72 hours
COPPA consent flow tested end-to-end

Approvers: Product, Engineering, Tutor Ops, Success, Legal.

G3 - MVP Evidence Gate¶

Entry criteria:

At least 8 weeks of cohort performance data.

Pass thresholds:

Free-session-to-paid conversion >=25%
Attendance adherence >=75%
Learners on-track by week 8 >=65%
Parent NPS >=45

Decision outcomes:

Proceed to MSP-R1.
Proceed with condition and remediation plan.
Hold and run correction cycle.

Approvers: Product, Growth, Curriculum, Finance.

G4 - MSP Feature Completeness¶

Entry criteria:

Subscription, retention, and trust capabilities merged and tested.

Pass criteria:

Billing workflows pass acceptance tests.
Retention operations playbook validated.
Security and legal launch packet complete.

Approvers: Engineering, Revenue Ops, Security, Legal.

G5 - MSP Commercial Launch¶

Entry criteria:

G4 complete and launch plan approved.

Pass thresholds:

Month-3 retention forecast >=75% (based on leading indicators)
Tutor continuity >=85% in pre-launch cohorts
Gross margin forecast >=65%
Support SLA readiness >=95%

Approvers: Product Council + Executive Sponsor.

G5.1 - MSP-R2 Scale Gate¶

Entry criteria:

Post-launch stabilization window complete.

Pass criteria:

No unresolved high-severity incident trend.
Group/scale features show positive unit economics.

Approvers: Product, Finance, Operations.

Required Artifacts For Every Gate¶

Scope baseline and requirement diff report.
Defect and reliability summary.
KPI scorecard against gate thresholds.
Risk log with open items and owners.
Support, tutor ops, and escalation runbooks.

Go/No-Go Decision Log Template¶

Date	Gate	Decision	Conditions	Owner	Next Review
YYYY-MM-DD	Gx	Go / Hold / No-Go	Example: launch with capped cohort size	Product Council	YYYY-MM-DD

Release Control Rules¶

Any single failed P0 gate criterion blocks full release go-live.
Conditional go-live requires documented blast-radius limits and rollback triggers.
All no-go decisions require remediation plan within 5 business days.
Post-release readout is mandatory at D+7 and D+30.