72-Hour Product Launch Recovery Plan

Recommendation: partial/gated launch as the default plan, with a full launch only if the PDF totals bug is fixed and independently verified by objective gates before Friday. Do not launch incorrect PDF exports to all customers. The best feasible outcome is to preserve customer trust by launching Smart Reports progressively, protecting the 3 enterprise renewals with high-touch handling, and keeping the option open for a full launch if the fix is proven safe. Plan assumptions: You are the project DRI. Backend Engineer 1 owns debugging the reporting service. Backend Engineer 2 owns tests, data validation scripts, and deployment support. Senior Frontend Engineer owns feature-flag and UI fallback work. QA Engineer owns reproduction, regression, and sign-off. Technical Writer owns release notes, support docs, and customer-facing wording drafts. Customer Support owns enterprise outreach with you and prepares frontline responses. Marketing/Comms is pulled in for the teaser and press plan, even if not part of the core build team. Tuesday, 5:00 PM to 11:00 PM 5:00 to 5:30 PM: Declare launch-risk war room. Owner: Product Manager. Actions: freeze non-critical Smart Reports changes; create a single launch decision document; confirm Friday 5:00 PM launch target, Friday 9:00 AM press embargo, and CEO constraint: no embarrassing shipment. Define the critical issue as data accuracy in exported PDFs under specific timezone settings. 5:30 to 6:30 PM: Reproduction and blast-radius mapping. Owners: QA Engineer, Backend Engineer 1. Actions: capture exact timezone settings, datasets, report types, and export paths that produce the 8% variance; determine whether the incorrect total appears only in exported PDFs or also in the in-app report view/API; save known-good and known-bad examples in staging. 5:30 to 7:00 PM: Technical triage. Owners: Backend Engineer 1, Backend Engineer 2. Actions: inspect suspected timezone aggregation/conversion code; identify recent commits; add logging in staging; create a minimal failing test if possible. Backend Engineer 2 starts a validation script that compares PDF totals, API totals, and database source totals across representative timezones. 6:30 to 8:00 PM: Contingency engineering. Owner: Senior Frontend Engineer. Actions: confirm whether PDF export can be separately hidden or disabled behind the feature-flag system. If no separate flag exists, prepare a minimal UI change to hide or disable the PDF export button for Smart Reports while leaving the core report view available. Add clear in-product copy: “PDF export is being finalized and will be available soon.” 7:00 to 8:00 PM: Customer and press containment planning. Owners: Product Manager, Technical Writer, Customer Support lead, Marketing/Comms. Actions: draft three versions of messaging: full launch, progressive rollout, and delay. Prepare CEO briefing. Identify account owners for the 3 enterprise customers and collect their timezones, use cases, renewal dates, and whether PDF export is explicitly required. 8:00 to 10:30 PM: First fix attempt and test design. Owners: Backend Engineer 1, Backend Engineer 2, QA Engineer. Actions: attempt a small, targeted fix only if root cause is sufficiently understood. Build a regression matrix covering affected timezones, UTC, customer local timezones, daylight-saving boundaries, monthly/weekly ranges, and at least the 3 enterprise customers’ likely configurations. 10:30 to 11:00 PM: Nightly decision checkpoint. Owner: Product Manager. Criteria: If the bug is isolated and a low-risk fix is in progress, continue full-launch recovery path. If the bug is not isolated, immediately treat partial/gated launch as the operating plan while continuing investigation. Send CEO a written status: issue, impact, current hypothesis, next gate, and recommendation not to promise full launch yet. Wednesday, 8:00 AM to 6:00 PM 8:00 to 8:30 AM: Standup and owner confirmation. Owner: Product Manager. Actions: restate goal: prove full launch safe or execute controlled partial launch. No one works on non-launch work unless released by you. 8:30 to 11:30 AM: Root-cause push. Owners: Backend Engineer 1, Backend Engineer 2. Actions: trace timezone handling from data query through aggregation through PDF rendering. Compare PDF export logic with in-app report logic. Backend Engineer 2 expands automated tests using the known failing cases. 8:30 to 11:30 AM: QA verification harness. Owner: QA Engineer. Actions: create a repeatable test pack in staging. Required cases: the original reliable repro, the top customer timezones, daylight-saving transitions, month-end boundaries, and reports with enough volume to expose percentage variance. QA records exact pass/fail evidence. 9:00 to 11:00 AM: Enterprise discovery calls. Owners: Product Manager and Customer Support/account owners. Actions: contact the 3 enterprise customers individually. Message: “Smart Reports is on track for Friday, but we are doing final data-accuracy validation. Because your team is a priority user, we want to confirm your timezone, reporting workflow, and whether PDF export is required on day one. We will not expose you to inaccurate reports.” Do not disclose chaotic internal details. Capture whether controlled early access is acceptable. 11:30 AM to 12:00 PM: Gate 1: full-launch viability. Owner: Product Manager with QA and Backend Engineers. Full-launch path continues only if all are true: root cause is identified or narrowed to one code path; there is a credible fix expected by Wednesday end of day; the issue is confirmed not to corrupt stored data; and the team can separately disable PDF export if needed. If any criterion fails, full launch is no longer the primary plan; partial/gated launch becomes the plan of record. 12:00 to 4:00 PM: Implement fix and fallback. Owners: Backend Engineer 1, Backend Engineer 2, Senior Frontend Engineer. Actions: Backend Engineer 1 implements the smallest safe backend fix. Backend Engineer 2 writes regression tests and validation scripts. Senior Frontend Engineer finishes PDF-disable fallback and confirms the Smart Reports main feature can be enabled without PDF export. Code review is mandatory between the two backend engineers. 2:00 to 4:00 PM: Documentation and support prep. Owners: Technical Writer, Customer Support lead. Actions: write support macro for “progressive rollout,” “PDF export coming soon,” and “launch delayed for data accuracy.” Prepare internal FAQ: what is affected, who gets access, how to escalate enterprise accounts, and what not to say. 4:00 to 5:00 PM: QA pass 1. Owner: QA Engineer. Actions: test the fix in staging against the regression matrix. Separately test the fallback path with PDF export disabled. Confirm no broken navigation, no blank reports, and no user-visible incorrect totals. 5:00 to 6:00 PM: Gate 2: Wednesday end-of-day launch path. Owner: Product Manager. Criteria for staying eligible for full launch: fix merged to staging; original bug no longer reproduces; validation script shows PDF/API/source totals match within rounding tolerance; no P0/P1 bugs open; PDF-disable fallback is ready. If criteria are not met, announce internally that Friday will be partial/gated or delayed depending on Thursday validation. Thursday, 8:00 AM to 6:00 PM 8:00 to 9:00 AM: Lead backend engineer return and knowledge transfer. Owners: Lead Backend Engineer, Backend Engineer 1, Backend Engineer 2, Product Manager. Actions: if reachable Thursday morning, get a focused review of the suspected root cause, fix, and any hidden risks in reporting service. Do not let this become an open-ended redesign. 9:00 to 11:30 AM: Expert review and hardening. Owners: Lead Backend Engineer, Backend Engineer 1, Backend Engineer 2. Actions: review timezone assumptions, aggregation boundaries, PDF rendering path, and test coverage. If the lead engineer rejects the fix or identifies broader accuracy risk, move immediately to partial/delay plan. 9:00 to 11:30 AM: QA pass 2. Owner: QA Engineer. Actions: rerun full regression on staging, including original failing case, enterprise-relevant cases, multiple browsers for export initiation, and feature-flag states: off, gated on, PDF disabled, full on. 11:30 AM to 12:00 PM: Gate 3: technical go/no-go. Owner: Product Manager, with QA sign-off and engineering sign-off. Full-launch candidate requires all of the following: original timezone/PDF bug fixed; automated tests cover the failing scenario; QA regression matrix passes; lead backend engineer or two reviewing backend engineers approve; PDF/API/source totals match within accepted rounding tolerance, not percentage variance; rollback/flag-off tested in staging; no P0/P1 issues remain. If any fail, full launch is no-go. 12:00 to 1:00 PM: CEO decision briefing. Owner: Product Manager. Present one of three paths. Path A: full launch if Gate 3 passed. Path B: gated launch with PDF export disabled or restricted if Smart Reports core is accurate but PDF is not fully trusted. Path C: delay if core report accuracy or safe disabling cannot be guaranteed. Recommendation remains Path B unless Path A has passed cleanly. 1:00 to 3:00 PM: Enterprise validation. Owners: Product Manager, Customer Support/account owners, QA Engineer. Actions: if safe, enable staging/demo or controlled production preview for the 3 enterprise customers’ configurations, prioritizing their exact timezones and workflows. If PDF export is not safe, be explicit that the initial rollout includes interactive Smart Reports and that PDF export follows after validation. Offer manual report export assistance from Support for renewal-critical use cases. 1:00 to 4:00 PM: Launch package finalization. Owners: Technical Writer, Marketing/Comms, Customer Support lead. Actions: finalize release notes, known limitations if any, support macros, internal Slack/email announcement, customer email variants, and press language. Press language for partial launch should say “Smart Reports begins rolling out Friday” rather than “available to every customer immediately.” 4:00 to 5:00 PM: Operational readiness. Owners: Backend Engineer 2, Senior Frontend Engineer, QA Engineer. Actions: verify production feature flags, ramp percentages, rollback steps, monitoring dashboards, logs for export errors, and customer-support escalation channel. Prepare a 15-minute rollback protocol: disable Smart Reports flag, disable PDF export flag, notify Support, post internal update. 5:00 to 6:00 PM: Gate 4: communications lock. Owner: Product Manager. Criteria: CEO has approved the launch path; Marketing/Comms has press wording aligned to that path; Support has macros; the 3 enterprise customers have been contacted or scheduled; all internal staff know whether Friday is full, gated, or delayed. Friday, 8:00 AM to 5:00 PM 8:00 to 8:30 AM: Final technical smoke test. Owners: QA Engineer, Backend Engineer 1, Backend Engineer 2. Actions: run production-adjacent smoke tests with flags limited to internal users. Validate report creation, totals, PDF export if enabled, and flag rollback. 8:30 to 8:50 AM: Gate 5: press embargo decision before 9:00 AM. Owner: Product Manager with CEO and Marketing/Comms. Criteria: If full launch criteria passed and smoke test is clean, allow full-launch press wording. If partial criteria passed, revise press to “rollout begins today” and avoid promising universal immediate PDF availability. If neither passed, ask press contacts to update with delay language before embargo lifts, or issue a short accuracy-first delay statement. 9:00 to 10:00 AM: Press and internal alignment. Owners: Marketing/Comms, Product Manager, Technical Writer. Actions: release only the approved language. Internal staff receive the same version within 5 minutes so Sales and Support do not contradict it. 10:00 AM to 12:00 PM: Controlled production enablement. Owners: Backend Engineer 2, Senior Frontend Engineer, QA Engineer. Actions for full path: enable to internal users, then 5% of paying customers, monitoring totals/export errors and support tickets. Actions for partial path: enable Smart Reports for internal users, the 3 enterprise customers if their configurations passed, and a small preselected cohort; keep PDF export disabled or limited unless fully validated. Actions for delay path: keep feature off; enable only internal demo if safe. 12:00 to 12:30 PM: Gate 6: customer rollout expansion. Owner: Product Manager. Full rollout expansion criteria: no incorrect totals observed; no P0/P1 tickets; export success rate acceptable; QA spot checks pass; Support volume manageable. Partial rollout expansion criteria: core reports stable; disabled PDF path is clear; enterprise customers are not blocked without workaround. If criteria fail, pause ramp and move to delay/rollback messaging. 12:30 to 3:30 PM: Execute selected launch path. Owners: Product Manager, Backend Engineer 2, Senior Frontend Engineer, QA Engineer, Support. Full path: ramp 5%, 25%, 50%, 100% with checks every 45 minutes. Partial path: keep feature gated; enable the 3 enterprise customers only if validated, plus limited cohort; do not enable affected PDF exports; provide Support-assisted exports or manual reports for enterprise renewals. Delay path: send customer update and target next checkpoint; do not enable customer-facing feature. 3:30 to 4:30 PM: Final Friday status and customer communications. Owners: Product Manager, Marketing/Comms, Customer Support, Technical Writer. Actions: send broader customer communication if launch is partial or delayed. If full launch succeeded, send normal availability email. If partial, say rollout has started and some accounts will receive access progressively while final export validation completes. If delayed, say data accuracy validation found an issue and launch is being held until resolved. 4:30 to 5:00 PM: Close or continue war room. Owner: Product Manager. Actions: publish final status to CEO and internal staff. Confirm weekend/on-call ownership if any customers are enabled. Record decisions, remaining bugs, customer commitments, and next update time. Decision gates and explicit criteria Gate 1, Wednesday noon: Continue full-launch recovery only if root cause is reasonably isolated, stored data is not corrupted, a fix is feasible by end of day, and PDF export can be disabled as fallback. Gate 2, Wednesday 5:00 PM: Full launch remains possible only if fix is merged to staging, original repro passes, validation tests match source totals within rounding tolerance, no P0/P1 remains, and fallback is ready. Gate 3, Thursday noon: Full launch candidate only if QA regression, automated tests, and engineering review all pass. Otherwise choose partial/gated if core reports are accurate and PDF can be disabled; choose delay if core accuracy is uncertain or PDF cannot be safely disabled. Gate 5, Friday 8:50 AM: Press language must match reality before embargo. No “available to all” language unless full launch criteria have passed. Gate 6, Friday 12:30 PM: Expand rollout only if production smoke and early cohort show no accuracy issue, no P0/P1 tickets, and Support volume is manageable. Risk register Risk 1: Incorrect customer-facing totals in PDFs damage trust and renewal conversations. Severity: critical. Mitigation: do not full launch unless PDF totals pass regression; create separate PDF-disable fallback; validate against source data. Contingency: launch Smart Reports without PDF export, or delay entirely if PDF cannot be isolated. Risk 2: Reporting service knowledge bottleneck because lead backend engineer is unavailable until Thursday. Severity: high. Mitigation: pair both mid-level backend engineers, keep fix minimal, add tests rather than broad refactor, prepare focused review agenda for Thursday. Contingency: if lead engineer cannot validate or rejects the fix, do not full launch. Risk 3: Marketing and press have already created public expectation for Friday. Severity: high. Mitigation: shift wording from “available to all” to “rollout begins”; decide before Friday 9:00 AM; prepare delay statement. Contingency: publish accuracy-first message: “We found a final data-validation issue and are holding broad release until resolved.” Risk 4: Three enterprise customers expect the feature for renewals. Severity: high. Mitigation: contact them directly Wednesday; validate their exact configurations; offer controlled access if safe; provide manual reporting workaround if PDF is delayed. Contingency: executive/account-level call explaining that inaccurate financial/reporting totals would be worse than a short delay, with a firm next update time. Risk 5: Partial launch creates confusion for Support, Sales, and customers. Severity: medium. Mitigation: give Support exact eligibility rules, macros, escalation path, and known limitations; ensure all internal messaging uses the same wording. Contingency: pause rollout and send a clarifying customer update if ticket volume spikes or messaging diverges. Risk 6: A rushed fix causes regression outside the known timezone bug. Severity: high. Mitigation: narrow patch scope, mandatory review, automated regression matrix, staged flag ramp, rollback tested. Contingency: disable feature flag immediately and revert to delay communication. Communication plan CEO: Send written updates Tuesday 11:00 PM, Wednesday noon, Wednesday 6:00 PM, Thursday noon, Friday 8:50 AM, and Friday 5:00 PM. Use concise format: current launch path, evidence, risks, decision needed, and customer impact. If partial is needed, say: “We can preserve the Friday commitment in a controlled way, but we should not expose unverified PDF totals. I recommend rollout begins Friday with PDF export disabled/restricted unless Thursday validation fully passes.” Three enterprise customers: Contact Wednesday morning individually through account owners with you present. Say: “You are a priority account for Smart Reports. We are completing final data-accuracy validation and want to confirm your reporting timezone and day-one workflow. Our goal is to have you using Smart Reports Friday, but we will not put inaccurate totals in front of your team.” If partial: “We can enable interactive Smart Reports for your account Friday once your configuration passes validation; PDF export will follow after final validation, and Support can assist with manual exports in the interim.” If delayed: “We found an accuracy issue in final validation. Because your reports are renewal-critical, we are holding release rather than giving you incorrect totals. We will provide a confirmed next update by [specific time] and a workaround for the reports you need.” Broader 40,000-customer email list: Do not send a panic note Tuesday. Prepare by Thursday. If full launch passes, send normal availability email Friday. If partial: “Smart Reports rollout begins today. We are enabling access progressively to ensure a reliable experience. Some export capabilities may appear after final validation for your account. You will see Smart Reports as soon as it is enabled for your workspace.” If delayed: “During final validation we found an issue that could affect report accuracy in certain export scenarios. We are delaying broad availability until it is resolved because accurate reporting is non-negotiable. We will share the next availability update on [date/time].” Internal staff: Start an internal launch-risk channel Tuesday 5:00 PM. Send status after every gate. Support gets macros and escalation rules by Thursday 5:00 PM. Sales/CS get a one-page explanation: what is launching, who is eligible, what to say to enterprise accounts, and what not to promise. If partial or delayed, internal wording must avoid blaming sick staff or exposing unnecessary technical uncertainty. Final recommendation Proceed toward Friday with a partial/gated launch as the planned outcome, not an unconditional full launch. Full launch is acceptable only if all technical gates pass by Thursday noon and Friday morning smoke tests remain clean. If the PDF issue is not fully fixed but core Smart Reports are accurate and PDF export can be disabled, launch gated access Friday, prioritize the 3 enterprise customers after validating their configurations, and communicate “rollout begins” to the broader market. If core accuracy is uncertain or PDF export cannot be safely isolated, delay the launch. This balances the CEO’s desire to proceed, the public Friday expectation, the enterprise renewal pressure, and the overriding constraint that shipping incorrect report totals would be embarrassing and trust-damaging.

{ "plan_title": "Smart Reports 72-Hour Launch Recovery Plan", "recommendation": { "chosen_option": "Partial/Gated Launch", "justification": "This strategy best balances the conflicting constraints. It avoids shipping an 'embarrassing' and data-corrupting bug, thereby upholding quality standards as requested by the CEO. It allows the marketing launch and press embargo to proceed on schedule, delivering on the public promise. Crucially, it provides the core functionality to the three high-value enterprise customers, meeting the spirit of the renewal commitment. A full delay would miss all deadlines, while a full launch with the bug would cause significant reputational damage. A partial launch, disabling only the faulty PDF export via feature flag, is a standard industry practice that mitigates the highest risks while maintaining launch momentum." }, "timeline": [ { "time_block": "Tuesday 5:30 PM - 9:00 PM", "theme": "Triage and Investigation Kick-off", "actions": [ { "task": "Convene emergency 'war room' meeting with the available team.", "owner": "Product Manager (You)" }, { "task": "Document exact bug reproduction steps and define the scope of affected timezone settings.", "owner": "QA Engineer" }, { "task": "Begin preliminary code investigation of the reporting service, focusing on timezone and data aggregation logic. Document all findings and hypotheses.", "owner": "2 Backend Engineers" }, { "task": "Create a shared communication channel and a central planning document.", "owner": "Product Manager (You)" }, { "task": "Send an initial holding update to the CEO.", "owner": "Product Manager (You)" } ] }, { "time_block": "Wednesday 9:00 AM - 5:00 PM", "theme": "Parallel Paths: Fix Attempt and Containment Planning", "actions": [ { "task": "Continue deep-dive investigation to isolate the root cause of the calculation error.", "owner": "2 Backend Engineers" }, { "task": "Investigate the technical feasibility of using feature flags to disable ONLY the PDF export function, or disable the entire feature for users in affected timezones.", "owner": "Frontend Engineer, Product Manager" }, { "task": "Draft communication templates for all audiences (CEO, enterprise, public) for three scenarios: full launch, partial launch, and delay.", "owner": "Product Manager" }, { "task": "Hold a team sync and make a preliminary decision on the most likely path.", "owner": "All Hands" } ] }, { "time_block": "Thursday 9:00 AM - 5:00 PM", "theme": "Decision and Execution", "actions": [ { "task": "Brief the returning Lead Backend Engineer on all findings. Have them validate the root cause analysis or the proposed containment strategy.", "owner": "Lead Backend Engineer, 2 Backend Engineers" }, { "task": "Implement the chosen solution (either the bug fix or the feature flag for partial launch) and deploy to the staging environment by 1:00 PM.", "owner": "Backend Engineers, Frontend Engineer" }, { "task": "Execute a full regression test on the Smart Reports feature in staging, focusing on data integrity and the implemented change.", "owner": "QA Engineer" }, { "task": "Update all help documentation and release notes to reflect the final launch state.", "owner": "Technical Writer" }, { "task": "Proactively call the 3 enterprise customers to set expectations based on the final plan.", "owner": "Product Manager, Head of Customer Support" } ] }, { "time_block": "Friday 9:00 AM - 5:00 PM", "theme": "Launch Day Execution", "actions": [ { "task": "Coordinate with Marketing to ensure the 9:00 AM announcement and press release align with the final launch decision (full, partial, or delay).", "owner": "Product Manager" }, { "task": "If delaying, send the 'delay' email to the 40,000 customer list before 9:00 AM.", "owner": "Marketing, supervised by PM" }, { "task": "If launching, deploy the feature to production at 1:00 PM.", "owner": "Backend Engineers" }, { "task": "All-hands-on-deck monitoring of system logs, performance metrics, and customer support channels post-launch.", "owner": "Entire Team" }, { "task": "Hold a final end-of-day check-in at 5:00 PM.", "owner": "Product Manager" } ] } ], "decision_points": [ { "gate_name": "Go/No-Go for Full Fix", "timing": "Wednesday 1:00 PM", "criteria": "Has the team identified the root cause with high confidence AND is the estimated time for a fix, full regression test, and deployment under 16 hours?", "if_go": "Prioritize development of the full fix.", "if_no_go": "Immediately pivot to the Partial Launch (containment) plan as the primary target. The full fix becomes a secondary, best-effort task." }, { "gate_name": "Final Launch Go/No-Go", "timing": "Thursday 4:00 PM", "criteria": "Is the chosen solution (either the full fix or the partial launch containment) stable, fully tested, and verified on the staging environment with no new critical regressions?", "if_go": "Approve the Friday launch. Execute the corresponding communication plan.", "if_no_go": "The launch is delayed. Immediately trigger the 'Delay' communication plan for all audiences." } ], "risk_register": [ { "risk": "The fix introduces a new, more severe bug.", "priority": "High", "mitigation": "A full regression test of the entire feature will be performed by QA on staging, not just a test of the specific bug fix.", "contingency": "If a new critical bug is found, the launch is immediately delayed. There is no partial fix for this scenario." }, { "risk": "The three enterprise customers react negatively to a partial launch or delay, impacting renewals.", "priority": "High", "mitigation": "Proactive, honest, and personal phone calls will be made on Thursday to manage expectations. Frame the decision around our commitment to data quality and their business.", "contingency": "If a customer relationship is at risk, escalate immediately to the CEO and Head of Sales to formulate a specific retention plan (e.g., service credit, executive call)." }, { "risk": "The Lead Backend Engineer is unreachable for longer than expected (i.e., past Thursday morning).", "priority": "Medium", "mitigation": "The team must operate as if they are on their own. The Wednesday decision to pivot to a containment plan cannot wait for the lead engineer.", "contingency": "If the lead engineer is still unavailable by the final Go/No-Go gate on Thursday, the launch is automatically delayed. We will not ship a change to this critical service without their final review." }, { "risk": "Public messaging around a partial or delayed launch causes customer confusion and negative sentiment.", "priority": "Medium", "mitigation": "The Product Manager will personally approve all external communications. Drafts for all scenarios will be prepared in advance.", "contingency": "Prepare a follow-up FAQ or blog post to provide more detail if needed. Customer Support will be equipped with clear talking points." } ], "communication_plan": { "ceo": { "audience": "CEO", "method": "Direct Slack Message / Brief Call", "updates": [ "Tuesday EOD: Initial alert and plan for investigation.", "Wednesday Afternoon: Update on the pivot to the partial launch strategy as the primary path.", "Thursday EOD: Final Go/No-Go decision and summary of customer communications." ] }, "enterprise_customers": { "audience": "3 Enterprise Customers (ARR ~$600k)", "method": "Personal Phone Call", "timing": "Thursday Afternoon", "message_if_partial": "We are excited to launch Smart Reports tomorrow. As a valued partner, we wanted to inform you that to ensure 100% data integrity, we've temporarily disabled PDF exports while we resolve a timezone-specific issue. All other features are live. We expect exports to be enabled early next week.", "message_if_delay": "Out of an abundance of caution and commitment to quality, we are delaying the Smart Reports launch by a few days to resolve a critical bug found in final testing. We know you were anticipating this and we apologize. We will provide a firm new date by EOD Friday." }, "general_customers": { "audience": "40,000 Customers on Email List", "method": "Marketing Email / Blog Post", "timing": "Friday 9:00 AM", "message_if_partial": "Smart Reports is here! [Marketing copy]... Note: To ensure accuracy for all our global users, PDF exports are being rolled out progressively and will be available for all users next week.", "message_if_delay": "An update on Smart Reports: We're taking a few extra days to apply the final polish. Our team is committed to an exceptional experience and we want to ensure everything is perfect. Look for the official launch early next week!" }, "internal_staff": { "audience": "Company-wide, especially Sales and Support", "method": "Slack Updates", "timing": "Daily EOD and after each decision point", "message": "Provide transparent, concise updates on the problem, the plan, the risks, and the final decision. Ensure customer-facing teams have clear, approved talking points." } } }