## 1. Mandate, Audience, and Definition of Done **Outcome.** A new mobile application extends the existing web-only SaaS product onto mobile devices, giving current and prospective customers a native way to access the product's core workflows. The launch is timed to a fixed, non-negotiable external event — the company's annual user conference, approximately 14 weeks from plan initiation (week of December 21–27, 2026) — and must not repeat the migration-messaging failure that drove a 300% support-ticket spike during last year's web-redesign launch. **Stakeholders.** - **Launch Lead** (owns day-to-day coordination across functions): role not yet named — see `<VALIDATE: launch-lead-assignment>`. - **Go/No-Go decision owner** (final authority on Section 12 approvals): role not yet named — see `<VALIDATE: launch-lead-assignment>`. - **Accountable owner if the launch slips or breaks**: role not yet named — see `<VALIDATE: launch-lead-assignment>`. **Requirements table** | ID | Requirement | Source | |---|---|---| | R1 | Deliver a new mobile app exposing the existing SaaS product's core workflows on mobile | Supplied | | R2 | Launch date is fixed to the annual user conference, ~14 weeks from plan initiation (week of Dec 21–27, 2026) | Supplied | | R3 | App Store review (up to 2 weeks) must be built into the submission timeline | Supplied (hard constraint) | | R4 | Migration/onboarding messaging must avoid the ambiguity that drove last year's 300% support-ticket spike | Supplied (context-derived) | | R5 | Support must have a staffing/capacity plan for launch week, informed by the prior ticket-spike incident | Supplied (context-derived) | | R6 | Mobile platform scope (iOS only vs. iOS + Android) is unspecified and must be confirmed before scope can lock | Unverified — `<VALIDATE: android-scope-confirmation>` | | R7 | Whether the existing web app is being deprecated or remains alongside the new mobile app is unspecified | Unverified — `<VALIDATE: web-sunset-status>` | | R8 | Launch Lead and go/no-go decision owner are unspecified | Unverified — `<VALIDATE: launch-lead-assignment>` | **Explicit exclusions.** This plan does not cover: the post-launch feature roadmap for the mobile app; long-term growth, retention, or paid-acquisition campaigns; a web-app deprecation/sunset plan (out of scope regardless of how R7 resolves — a separate plan would govern that decision if made); international/localization expansion beyond what is already supported by the existing web product. **Solution shape.** - *Technical/operational* (owned by Engineering): iOS/Android build readiness, cross-platform authentication, backend load capacity, staged-rollout mechanism, kill-switch. - *Go-to-market judgment calls* (owned by Marketing/Comms and Sales): migration/onboarding messaging, conference positioning, sales talking points. - *Cross-cutting* (owned by Support and Legal/Compliance): support capacity and mobile-specific help content; privacy/data-handling disclosures required for app store submission. **Completion criteria** (externally checkable, one per requirement cluster): - Platform scope is locked in writing (iOS confirmed; Android decision documented either way). - App Store review approval obtained for the submitted build (and Google Play approval, if Android is in scope). - Cross-platform authentication passes a staging/production-parity test with existing web accounts. - Migration/onboarding messaging has been user-tested with no unresolved critical clarity issues. - Support has a signed-off staffing/capacity plan for launch week from Support leadership. - The Section 9 dry run has been executed and identified runbook issues have been fixed. - Every action row in Section 12 carries a non-blank "Approved by / Date." A completed written plan is **not** completion. Completion is defined and evidenced only in Section 13. ## 2. Launch Lead Instructions ``` Coordinate this launch against real teams and real system state, not an assumed one. Check current deploy status, support queue volume, and open incidents before treating anything as ready. Reuse an existing runbook or checklist if one already covers part of this launch. Resolve every <VALIDATE> item by confirming with the actual owning team or checking the actual system — not by assuming it's probably fine. Produce a real, dated runbook and real assigned owners; do not stop at a general checklist. Run the dry run defined in Section 9, capture what actually broke or was unclear, and fix the plan before the real launch. Stop scheduling around a dependency that keeps slipping unacknowledged; report a concrete blocker when progress needs a decision, resourcing, or access outside your authority. Do not mark a team "ready" without their own confirmation, invent a system check that wasn't run, or assume a rollback path works without testing it. Continue safe, low-risk preparation while a go/no-go-critical item is unresolved. Trigger the actual go-live, send external communications, or declare launch complete only within approved authority. Report progress using actual confirmations and actual dry-run results, and clearly separate planned, rehearsed, and live-confirmed status. Operational defaults (which internal channel hosts launch-day coordination, how often status updates go out) may be chosen and documented autonomously. Do not autonomously invent team sign-offs or claim a rollback was tested when it was not. ``` In particular: do not assume `<migration-messaging-readiness>` is solved because messaging existed for last year's web redesign — that redesign's own messaging caused a 300% support-ticket spike, so this launch's migration/onboarding messaging must be independently drafted, user-tested, and confirmed clear before App Store submission, not inherited or reused from last year's material. ## 3. Readiness and Dependency Assumption Ledger **Technical / system readiness** | ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A1 | iOS app build is feature-complete and ready for release-candidate submission | Unverified — `<VALIDATE: ios-build-readiness>` | Low | App Store submission slips, consuming the fixed 2-week review window against a fixed conference date | | A2 | Android is in scope for this launch | Unverified — `<VALIDATE: android-scope-confirmation>` | Low | Scope (Section 4), runbook, and store-listing work cannot lock until resolved | | A3 | Existing web accounts authenticate successfully in the new mobile app | Unverified — `<VALIDATE: cross-platform-auth-readiness>` | Low | Existing customers cannot log in on launch day; immediate, high-severity incident | | A4 | Mobile-specific backend/API capacity is load-tested for expected launch-day traffic | Unverified — `<VALIDATE: mobile-backend-load-readiness>` | Low | Outage or degraded service during the highest-visibility window of the launch | | A5 | A staged-rollout mechanism (phased store rollout % or server-side flag) exists for the mobile release | Unverified — `<VALIDATE: mobile-rollout-mechanism>` | Low | No ability to limit blast radius if a defect surfaces post-launch | | A6 | A kill-switch / disable mechanism for mobile app functionality exists and is documented | Unverified — `<VALIDATE: mobile-kill-switch>` | Low | No safe containment path if a critical defect ships | | A7 | App/Play store listing assets (screenshots, description, Apple Privacy Nutrition Label, Play Data Safety form) are finalized | Unverified — `<VALIDATE: store-listing-readiness>` | Low | Submission is rejected or delayed on administrative grounds, consuming review-window slack | | A8 | The existing web app remains available unchanged; the mobile app is additive, not a replacement | Unverified — `<VALIDATE: web-sunset-status>` | Low | Changes the entire migration-messaging strategy (R4) and support framing; direct repeat-risk of last year's failure | **Team readiness** | ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A9 | Launch Lead and go/no-go decision owner are formally assigned | Unverified — `<VALIDATE: launch-lead-assignment>` | Low | No one has authority to trigger Section 12 actions or make blocker calls | | A10 | Support is staffed and trained on mobile-specific issues, with mobile macros/FAQ prepared | Unverified — `<VALIDATE: support-readiness-mobile>` | Low | Repeat of last year's 300% ticket spike, this time from a completely new surface (mobile) | | A11 | A support staffing/capacity surge plan exists for launch week | Unverified — `<VALIDATE: support-capacity-plan>` | Low | Queue backlog and SLA breach during the highest-traffic week of the year (conference week) | | A12 | Sales enablement materials on the mobile app are updated and delivered | Unverified — `<VALIDATE: sales-enablement-mobile>` | Low | Sales gives inconsistent or inaccurate answers about the app at the conference | | A13 | Engineering on-call coverage is scheduled for launch week and the conference dates | Unverified — `<VALIDATE: oncall-coverage>` | Low | Slow incident response during the highest-visibility window | | A14 | Migration/onboarding messaging is finalized and user-tested | Unverified — `<VALIDATE: migration-messaging-readiness>` | Low | Direct repeat of last year's root cause | **External dependencies** | ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A15 | Apple App Store review approval is obtained for the submitted build | Unverified — `<VALIDATE: app-store-review-approval>` | Low | Launch cannot occur on iOS by the fixed conference date | | A16 | Google Play review approval is obtained (conditional on A2) | Unverified — `<VALIDATE: play-store-review-approval>` | Low | Android launch slips independently of iOS | | A17 | Legal/compliance review of mobile-specific privacy disclosures and data handling is complete | Unverified — `<VALIDATE: mobile-privacy-compliance-review>` | Low | Store submission is blocked (Apple requires this disclosure), or a regulatory exposure ships | | A18 | Conference logistics (keynote slot, demo booth, timing) are confirmed with organizers | Unverified — `<VALIDATE: conference-coordination>` | Low | Launch messaging and conference programming are misaligned | | A19 | App Store review can take up to 2 weeks | Supplied (hard constraint) | High | N/A — treated as fixed | | A20 | Target launch date is fixed to the annual user conference, ~14 weeks from plan initiation (week of Dec 21–27, 2026) | Supplied | High | N/A — treated as fixed | | A21 | Last year's web-redesign launch saw a 300% support-ticket spike in week one, attributed to unclear migration messaging | Supplied | High | N/A — treated as historical fact informing this plan | The dependency most likely to force a delay is **App Store review approval (A15), contingent on iOS build readiness (A1) and store-listing completeness (A7)**. Against a fixed conference date and a hard 2-week review window with no stated slack for rejection/resubmission, any slip in build readiness or listing completeness directly threatens the launch date. This is the first chain Section 9's dry run must probe. ## 4. Launch Tier and Scope Definition ``` LAUNCH TIER: Major public launch IN SCOPE: - New native mobile app, iOS — confirmed in scope (App Store review is an explicit named constraint on this launch). - New native mobile app, Android — scope not yet confirmed. <VALIDATE: android-scope-confirmation> (go/no-go-critical) - Core existing SaaS workflows, ported to mobile. The specific feature set shipped in the mobile build is an engineering/product scoping decision not detailed in the supplied inputs; this plan governs launch mechanics, not the feature-completeness definition itself. Feature-complete build status is tracked as A1. ROLLOUT MECHANISM: Staged rollout recommended (not 100%-at-once), given last year's support-load failure on a launch of comparable visibility. Proposed default: phased store rollout starting at a reduced percentage, stepping up across defined monitoring windows (see Section 6 and Section 11). This is a plan recommendation, not a confirmed technical capability — see A5. FEATURE-FLAG / CONFIG IDENTIFIER: none supplied. To be assigned by Engineering as part of implementation once A5 is resolved. KILL-SWITCH / DISABLE MECHANISM: none supplied. <VALIDATE: mobile-kill-switch> (go/no-go-critical) — this is a gap to close, not an assumed safety net. DEFERRED TO A LATER PHASE: - Any mobile-exclusive features beyond initial release parity — deferred pending product roadmap; not detailed in this plan. - Web app deprecation/sunset — deferred and out of scope regardless of how A8 resolves; would require a separate plan if pursued. - International/localization expansion beyond current web-product support — deferred. ``` **Evidence rule.** This scope is a draft for review, not a locked commitment. It is not authorized for execution by virtue of appearing here; go-live is gated exclusively by the approvals in Section 12. ## 5. Cross-Functional Readiness Contracts **Engineering** - Readiness criteria: iOS build feature-complete and release-candidate ready (A1); cross-platform authentication tested against production-parity data (A3); backend load-tested for launch-day traffic (A4); staged-rollout mechanism and kill-switch functioning and documented (A5, A6); store listing technical fields complete (A7). - Owner: Engineering Lead – Mobile (name TBD, see A9). - Confirmation method: written sign-off in the launch tracking doc, plus a passing load test report and a passing auth-parity test report. - Deadline: T‑minus 4 weeks (build/backend readiness), T‑minus 3 weeks (rollout mechanism and kill-switch documented). - Escalation: unresolved by deadline → escalate to Launch Lead, then to the Accountable owner (A9) for a scope or date decision. **Support** - Readiness criteria: mobile-specific macros/FAQ prepared and reviewed (A10); staffing surge plan for launch week, sized against last year's 300% spike as a floor scenario (A11). - Owner: Head of Support (name TBD, see A9). - Confirmation method: written sign-off from Support leadership confirming staffing levels and content readiness; ticket-volume baseline documented. - Deadline: T‑minus 2 weeks. - Escalation: unresolved by deadline → escalate to Launch Lead; if staffing cannot be secured, this blocks the corresponding Section 12 go-live row. **Marketing / Communications** - Readiness criteria: migration/onboarding messaging drafted, user-tested, and confirmed clear (A14) — the direct mitigation for last year's root cause; conference-specific launch messaging aligned with logistics (A18). - Owner: Marketing Lead – Product Launches (name TBD, see A9). - Confirmation method: written sign-off plus documented user-testing results for messaging clarity (not internal review alone). - Deadline: T‑minus 3 weeks (draft), T‑minus 1 week (final, tested). - Escalation: unresolved by T‑minus 1 week → escalate to Launch Lead; this is treated as go/no-go-critical given the direct link to last year's failure. **Sales** - Readiness criteria: enablement materials on the mobile app delivered and reviewed with the sales team (A12). - Owner: Sales Enablement Lead (name TBD, see A9). - Confirmation method: written confirmation that materials were delivered and a Q&A session held. - Deadline: T‑minus 2 weeks. - Escalation: routine — unresolved items are logged and confirmed before finalizing, but do not block go-live. **Legal / Compliance** - Readiness criteria: mobile-specific privacy disclosures and data-handling review complete (A17) — required for App Store submission itself, not only for launch. - Owner: Legal/Compliance Lead (name TBD, see A9). - Confirmation method: written sign-off attached to the store submission package. - Deadline: T‑minus 5 weeks (must precede submission, which itself must precede the 2-week review window with buffer — see Section 8). - Escalation: unresolved by deadline → blocks App Store submission entirely; escalate immediately to Launch Lead and Accountable owner. **Functions explicitly not involved in this launch:** Finance (no pricing or billing change was indicated in the supplied inputs) and Localization/i18n (no international-expansion requirement was supplied; the mobile app follows the existing web product's current language support). These are scope decisions, not oversights, and can be revisited if either assumption changes. **Internal vs. external claim separation.** Internal-only: staffing levels, specific ticket-volume baselines, engineering load-test figures, and any unresolved `<VALIDATE>` status. Eligible to reach customers or the public only once confirmed: the fact that a mobile app exists and its general availability; migration/onboarding guidance for existing web users (only after A14 is resolved); general support-channel availability. No readiness-contract detail becomes a customer-facing claim until the owning function's own sign-off is on record. ## 6. Launch Architecture and Runbook Map **Launch-day runbook skeleton** (times relative to the approved go-live trigger, "L") | Time | Step | Owner | |---|---|---| | L‑24h | Final pre-launch checklist review (Section 9 dry-run findings closed out) | Launch Lead | | L‑12h | Confirm current system state: deploy status, open incidents, support queue baseline | Engineering Lead – Mobile, Head of Support | | L‑2h | Final go/no-go check against Section 12 approval status | Launch Lead | | L (trigger) | Execute approved go-live action(s) per Section 12 — staged rollout begins | Engineering Lead – Mobile | | L+1h | First monitoring checkpoint: error rate, crash rate, auth success rate | Engineering Lead – Mobile | | L+4h | Second monitoring checkpoint; support ticket volume vs. baseline | Head of Support | | L+24h | Go/no-go decision on expanding rollout percentage (per Section 11 staged monitoring) | Launch Lead | | L+1 week | First post-launch review against Section 9 checks and Section 1 completion criteria | Launch Lead | **Communication map** | Message | Depends on readiness contract | Owner | |---|---|---| | Internal all-hands launch note | Engineering + Support + Marketing contracts confirmed | Launch Lead | | Customer-facing announcement (migration/onboarding guidance) | Marketing contract (A14) | Marketing Lead | | Support macro / help-center content | Support contract (A10, A11) | Head of Support | | Sales talking points | Sales contract (A12) | Sales Enablement Lead | | Conference keynote/demo content | Marketing contract + conference logistics (A18) | Marketing Lead | Deliberately not used for this launch: a broad press/media push is not scoped here, since no PR requirement was supplied — if desired, it would need its own readiness contract before being added. No communication outside those mapped above is authorized by this plan; anything else requires a new entry in Section 5 first. ## 7. Validation and Readiness Requirements | id | What must be established | How to establish | Dependent tasks/actions | Status until resolved | |---|---|---|---|---| | `ios-build-readiness` | iOS build is feature-complete and release-candidate ready | Run the dry run / get explicit Engineering sign-off | Blocks App Store submission and Section 12 submission action | Build treated as not ready; submission cannot be scheduled | | `android-scope-confirmation` | Whether Android is in scope for this launch | Confirm current status with the owning team before finalizing | Blocks Section 4 scope lock and Section 5 Engineering contract scoping | Scope treated as iOS-only pending confirmation | | `cross-platform-auth-readiness` | Existing web accounts authenticate successfully in the mobile app | Run the dry run / get explicit Engineering sign-off | Blocks Section 12 full-launch action | Treated as unverified; full launch blocked | | `mobile-backend-load-readiness` | Backend/API capacity is load-tested for launch-day traffic | Run the dry run / get explicit Engineering sign-off | Blocks Section 12 full-launch action | Treated as unverified; full launch blocked | | `mobile-rollout-mechanism` | A staged-rollout mechanism exists and functions | Run the dry run / get explicit Engineering sign-off | Blocks Section 4 rollout mechanism, Section 11 staged monitoring | Treated as unavailable; only 100%-at-once would be possible, which is not recommended | | `mobile-kill-switch` | A kill-switch/disable mechanism exists and is documented | Run the dry run / get explicit Engineering sign-off | Blocks Section 12 go-live action | No containment path exists; go-live blocked | | `store-listing-readiness` | Store listing assets and privacy disclosures are finalized | Confirm current status with the owning team before finalizing | Blocks App Store/Play submission | Submission cannot proceed | | `web-sunset-status` | Whether the web app is being replaced or remains alongside mobile | Confirm current status with the owning team before finalizing | Blocks Marketing's messaging strategy (A14) and Support content (A10) | Messaging defaults to "additive" framing pending confirmation | | `launch-lead-assignment` | Launch Lead and go/no-go decision owner are named | Confirm current status with the owning team before finalizing | Blocks all Section 12 approvals (no one has authority to sign) | No individual has authority to trigger any Section 12 action | | `support-readiness-mobile` | Support is staffed/trained with mobile-specific content ready | Run the dry run / get explicit Support sign-off | Blocks Section 12 full-launch action | Treated as unverified; full launch blocked | | `support-capacity-plan` | A staffing surge plan exists for launch week | Confirm current status with the owning team before finalizing (go/no-go-critical, escalate if unresolved) | Blocks Section 12 full-launch action | Treated as unverified; full launch blocked | | `sales-enablement-mobile` | Sales materials delivered and reviewed | Confirm current status with the owning team before finalizing | Informs Section 12 communication readiness only | Logged as pending; does not block go-live | | `oncall-coverage` | Engineering on-call is scheduled for launch week/conference | Confirm current status with the owning team before finalizing | Blocks Section 12 full-launch action | Treated as unverified; full launch blocked | | `migration-messaging-readiness` | Migration/onboarding messaging is finalized and user-tested | Run the dry run / get explicit Marketing sign-off | Blocks customer-facing announcement (Section 6) and Section 12 announcement action | Treated as unresolved; direct repeat-risk of last year's failure if not confirmed | | `app-store-review-approval` | Apple has approved the submitted build | Confirm current status with the owning team before finalizing (external dependency; go/no-go-critical) | Blocks Section 12 iOS go-live action | Not yet submitted/approved; iOS launch blocked | | `play-store-review-approval` | Google has approved the submitted build (conditional on A2) | Confirm current status with the owning team before finalizing | Blocks Section 12 Android go-live action | Not yet submitted/approved; Android launch blocked | | `mobile-privacy-compliance-review` | Legal/compliance review of mobile privacy disclosures is complete | Run the dry run / get explicit Legal sign-off | Blocks store submission entirely | Submission cannot proceed | | `conference-coordination` | Conference logistics are confirmed with organizers | Confirm current status with the owning team before finalizing | Informs Section 6 communication timing only | Logged as pending; does not block go-live | Before treating any of the above as newly required, check existing system dashboards, open support/engineering tickets, and the prior web-redesign launch retro for information that may already answer part of the claim. No readiness claim in this plan is to be treated as confirmed, or silently dropped, based on convenience — every item above either resolves through the owning team's confirmation or remains flagged into Section 12. ## 8. Preparation Sequence and Requirement Traceability **Preparation sequence** 1. Confirm platform scope (A2) and web-sunset status (A8); lock Section 4 scope. *Depends on: none.* 2. Assign Launch Lead and go/no-go decision owner (A9). *Depends on: none — should occur in parallel with Task 1.* 3. Engineering closes build readiness (A1), cross-platform auth (A3), backend load testing (A4), rollout mechanism (A5), kill-switch (A6). *Depends on: Task 1 (scope).* 4. Legal/Compliance completes mobile privacy/data-handling review (A17). *Depends on: Task 1.* 5. Complete store listing assets, including privacy disclosures from Task 4 (A7). *Depends on: Tasks 3, 4.* 6. Submit build(s) to Apple App Store (and Google Play, if A2 confirms Android), with buffer ahead of the hard 2-week review constraint (A19). *Depends on: Tasks 3, 4, 5.* 7. Support finalizes mobile-specific content and staffing surge plan (A10, A11). *Depends on: Task 1 (web-sunset status determines messaging framing).* 8. Marketing drafts and user-tests migration/onboarding messaging (A14); confirms conference logistics (A18). *Depends on: Task 1.* 9. Sales enablement materials delivered (A12). *Depends on: Task 8 (messaging must exist first).* 10. Engineering on-call scheduled for launch week and conference (A13). *Depends on: none — scheduling task.* 11. Run the Section 9 dry run against all of the above. *Depends on: Tasks 1–10 at least partially complete; a dry run may proceed with documented stand-ins for still-open items.* 12. Resolve all go/no-go-critical `<VALIDATE>` items using real team/system confirmation, not dry-run stand-ins. *Depends on: Task 11.* 13. Go-live only once every go/no-go-critical item in Section 7 is resolved and every Section 12 action is approved. *Depends on: Task 12.* 14. Final task: report the status of every unresolved item to the Launch Lead and Accountable owner before any go-live trigger is attempted. *Depends on: continuous, throughout.* **Traceability table** | ID | Function/Step | Owner | Acceptance check | |---|---|---|---| | R1/A1 | Engineering build readiness | Engineering Lead – Mobile | Passing release-candidate build sign-off | | R6/A2 | Scope decision | Product/Launch Lead | Written scope decision in tracking doc | | A3 | Engineering auth testing | Engineering Lead – Mobile | Passing auth-parity test report | | A4 | Engineering load testing | Engineering Lead – Mobile | Passing load-test report against defined traffic target | | A5 | Engineering rollout mechanism | Engineering Lead – Mobile | Staged rollout demonstrated in a non-production environment | | A6 | Engineering kill-switch | Engineering Lead – Mobile | Kill-switch exercised and confirmed functional | | A7 | Store listing | Engineering Lead – Mobile / Legal | Listing package complete, including privacy disclosures | | R7/A8 | Web-sunset decision | Product/Launch Lead | Written decision in tracking doc | | R8/A9 | Leadership assignment | Executive sponsor | Named individuals recorded in tracking doc | | A10 | Support content | Head of Support | Macros/FAQ reviewed and published internally | | R5/A11 | Support capacity plan | Head of Support | Signed-off staffing plan with named surge coverage | | A12 | Sales enablement | Sales Enablement Lead | Delivery confirmation + Q&A session held | | A13 | On-call scheduling | Engineering Lead – Mobile | On-call schedule published covering launch week + conference | | R4/A14 | Migration messaging | Marketing Lead | User-testing results showing no unresolved critical clarity issues | | R3/A15 | App Store submission/approval | Engineering Lead – Mobile | Apple approval notice on file | | A16 | Play Store submission/approval | Engineering Lead – Mobile | Google approval notice on file (if A2 = in scope) | | A17 | Privacy/compliance review | Legal/Compliance Lead | Signed-off review attached to submission package | | A18 | Conference coordination | Marketing Lead | Written confirmation from conference organizers | ## 9. Dry-Run and Go/No-Go Readiness Checks The checks below describe a rehearsal, not the real launch. A pass on any row is evidence that the runbook and team roles work as designed — it is not evidence that the real launch, under real customer traffic and real store-review timing, will go smoothly. Where a `<VALIDATE>` item is still open at dry-run time, the dry run uses a documented stand-in (noted per row); passing the rehearsal with a stand-in leaves that item **unresolved** for the real launch. | Assumption/Req | Check level | Method | Expected result | Pass condition | Prerequisites | |---|---|---|---|---|---| | A1 (build readiness) | dry-run | Install release-candidate build in a staging environment | App launches and core flows function | No critical defects found | Release-candidate build exists | | A3 (cross-platform auth) | dry-run | Log in with existing web-product test accounts on the RC build | Login succeeds, session matches web account state | 100% pass on test account set | RC build; test account set | | A4 (backend load) | dry-run | Synthetic load test against mobile endpoints | System holds at target traffic level with acceptable latency | No error-rate threshold breach | Load-test environment; defined traffic target | | A5 (rollout mechanism) | dry-run | Exercise staged rollout in a non-production environment | Rollout percentage increases as configured | Mechanism behaves as designed | Rollout tooling access | | A6 (kill-switch) — rollback-path test | dry-run | Trigger the kill-switch in a non-production environment | App functionality disables per design | Confirmed disable behavior, confirmed re-enable behavior | Kill-switch implementation (A6 must first exist — if not, this row cannot run and is logged NOT RUN) | | A10/A11 (support readiness) — support-load stress check | dry-run | Simulate a support-ticket surge scenario against the launch-week staffing plan | Documented staffing plan can plausibly absorb a spike comparable to last year's 300% | Support leadership confirms plan holds under the scenario | Staffing plan drafted | | A14 (migration messaging) | internal-review | User-test draft messaging with a representative sample | No unresolved critical clarity issues reported | Testers correctly understand what is/isn't changing for them | Draft messaging exists | | A15/A16 (store approval) — fallback plan | internal-review | Confirm current submission status and, if not yet submitted, define the fallback if approval is pending near the target date | Documented fallback (e.g., delayed public rollout vs. delayed conference messaging) | Fallback plan exists and is agreed by Launch Lead | Submission timeline from Section 8 | | Section 1 requirements (overall) | full-launch | N/A | NOT RUN until Section 12 approvals granted | N/A | All above dry-run/internal-review rows passed | What a dry-run PASS proves: the runbook steps are workable and team roles are understood. What only the real launch proves: whether the system holds under genuine customer traffic and whether store review/approval actually lands inside the planned window. These are not the same evidence and are not to be conflated in reporting. ## 10. Risk, Compliance, and Support Boundaries - **[No-go rule — Critical]** Going live while any go/no-go-critical item in Section 7 is unresolved is not permitted under this plan. The corresponding Section 12 action stays BLOCKED BY VALIDATION until resolved. - **[Rollback risk — Critical, until A6 resolved]** An untested rollback path is a critical risk. Mitigation is the Section 9 kill-switch rehearsal specifically — not a general assumption that "we can roll back if needed." Until that rehearsal passes, rollback capability is treated as unproven. - **[Support boundary — High]** Support is equipped to answer questions covered by the mobile macros/FAQ produced under A10. Anything outside that scope (e.g., account-specific data discrepancies between web and mobile) escalates to Engineering per the on-call path (A13), not handled at first-line support. - **[Scope-change risk — High]** No scope change (e.g., adding Android mid-preparation, expanding the initial feature set) may occur without updating Section 4 and re-running the affected parts of Section 5 approval. No day-of scope change is permitted without Launch Lead and Accountable owner sign-off. - **[Message-consistency risk — High, direct link to prior failure]** A conflicting message across support macros, the customer-facing announcement, and sales talking points is the specific failure mode that drove last year's ticket spike. Mitigation: all three (Section 6 communication map) must trace to the same approved messaging (A14) before any of them ships; Marketing owns final consistency review before Section 12 approval. - **[Regulatory/data-handling risk — Critical]** This launch introduces new mobile-specific data collection (device permissions, push notification tokens, analytics) that did not previously exist for this product. This triggers the Legal/Compliance review at A17, which is also a hard prerequisite for store submission itself, not an optional launch nicety. - **[Timeline risk — Critical]** The fixed conference date combined with the hard 2-week App Store review constraint leaves limited room for rejection/resubmission cycles. This is addressed procedurally in Section 8's submission-buffer sequencing but remains a genuine risk if build readiness (A1) or listing completeness (A7) slips. The risk that remains genuinely unassessable until Section 7's go/no-go-critical items resolve is **whether the launch can occur on iOS by the fixed conference date at all** — this depends on A1, A7, A15, and A17 resolving with enough runway left inside the 2-week review window, which cannot be judged until those items report real status. ## 11. Launch Day, Verification, and Rollback Plan **Pre-launch checks — runnable now:** internal-review and dry-run rows from Section 9 that do not depend on external approval (build smoke tests, auth-parity tests, load tests, messaging user-testing). **Blocked on validation:** any full-launch row, App Store/Play Store approval status (A15/A16), and anything gated by Launch Lead assignment (A9), since no unnamed role can authorize Section 12 actions. **Approved go-live trigger:** execution of any go-live action requires the corresponding Section 12 row to be READY FOR HUMAN REVIEW and formally approved (signed, dated). No action in this section is self-authorizing. **Staged rollout monitoring — explicit checkpoints:** - Checkpoint 1 (L+1h): error rate, crash rate, and auth success rate within acceptable range → proceed to next rollout step, otherwise hold at current percentage. - Checkpoint 2 (L+4h): support ticket volume vs. baseline within the capacity plan's tolerance (A11) → proceed, otherwise hold and engage Support leadership. - Checkpoint 3 (L+24h): both of the above stable → Launch Lead may approve expansion toward full rollout, subject to a fresh Section 12 approval for that step. **Full launch — AND conditions (all required):** - Section 9 dry run passed at its stated levels (not rehearsal-stubbed for go/no-go-critical items). - Every Section 12 action required for full launch is approved and dated. - Every go/no-go-critical Section 7 item is resolved through real confirmation. **Post-launch verification (first monitoring window):** one concrete check — mobile-specific error rate and support ticket volume against the pre-launch baseline established under A11 — plus explicit confirmation that no deferred scope from Section 4 (e.g., Android, if not in scope; any deferred feature) was accidentally shipped. **Rollback.** Before assuming any rollback path, confirm the actual current live state (which rollout percentage is live, on which platforms). Disabling the mobile app via the kill-switch (A6) does not undo data already written by users through the app, nor does it retract communications already sent (A14 announcement, sales talking points). Containment means executing the named kill-switch and notifying Support and Engineering — it is not assumed to be a silent, complete revert. ## 12. Go-Live and Communication Approval Register | Action ID | Purpose | Scope/Audience | Expected effect | Trigger condition | Status | Approved by / Date | |---|---|---|---|---|---|---| | ACT-1 | Submit iOS build to App Store review | Apple App Store review team | Review process begins (up to 2 weeks) | Tasks 3–5 of Section 8 complete | BLOCKED BY VALIDATION (`ios-build-readiness`, `store-listing-readiness`, `mobile-privacy-compliance-review`) | ____ / ____ | | ACT-2 | Submit Android build to Play review (if in scope) | Google Play review team | Review process begins | ACT-1 conditions + `android-scope-confirmation` resolved affirmatively | BLOCKED BY VALIDATION (`android-scope-confirmation`) | ____ / ____ | | ACT-3 | Run the dry run in a shared staging environment | Internal (Engineering, Support, Marketing) | Section 9 checks executed | Section 8 Task 11 reached | READY FOR HUMAN REVIEW | ____ / ____ | | ACT-4 | Flip mobile app to initial staged rollout percentage | Subset of app store userbase | App becomes live at reduced rollout | All Section 11 full-launch AND-conditions met | BLOCKED BY VALIDATION (all go/no-go-critical Section 7 items) | ____ / ____ | | ACT-5 | Send customer-facing migration/onboarding announcement | All existing web customers | Customers are informed of the new mobile app | `migration-messaging-readiness` resolved; ACT-4 approved | Blocked on prior action (ACT-4) and `migration-messaging-readiness` | ____ / ____ | | ACT-6 | Expand rollout toward full percentage | Full app store userbase | App reaches full availability | Section 11 staged-rollout checkpoints pass | Blocked on prior action (ACT-4) | ____ / ____ | | ACT-7 | Execute rollback via kill-switch | All mobile app users | Mobile app functionality disabled | Only if a launch-day incident requires containment | Contingency only — not scheduled | ____ / ____ | Approving one action never implies approval of any other action in this table. Listing ACT-7 here documents the contingency path; it does not authorize executing it now or at any point absent an actual incident. ## 13. Completion Evidence and Handoff A final completion report for this launch must contain: - What actually shipped, and to whom — the real rollout percentage and platform(s) reached, not the planned scope from Section 4. - Every Section 9 check itemized as PASS / FAIL / NOT RUN / BLOCKED, each with one line of concrete evidence (e.g., "load test: PASS — held target traffic with no error-rate breach"), not a general "looked fine." - Dry-run results and live-confirmed results reported in separate columns or sections; a dry-run PASS is never presented as evidence that the live launch succeeded. - The actual go-live time and the name of who approved it under Section 12, stated only if it actually occurred — otherwise the report states plainly "NOT YET LIVE." - The status of every unresolved Section 7 item at handoff, named individually (not summarized as "a few open items"). - Any residual limitation still true at handoff (e.g., Android not yet submitted, rollback untested beyond the dry run). - Exact next steps required to close any outstanding validation or approval item, with an owner and date for each. No team confirmation, dry-run result, or approval may be fabricated or implied in this report. A completed plan document or a clean rehearsal, on their own, are not evidence that the actual launch succeeded — only live-confirmed results against the criteria in Section 1 and the approvals in Section 12 constitute that evidence.