{"slug":"strategy/business-strategy/51-launch-strategy","title":"51 — Launch Strategy","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/51-launch-strategy.mdx","bytes":8270,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: CANONICAL · Commercial OS\nOwner: Founder\nLast aligned: 2026-07-22\nPrecedence: Implements [00 Current GTM Canon](00-current-gtm-canon.md) and the\noperational [Go-Live and GTM Plan](../../operations/GO_LIVE_AND_GTM_PLAN.md).\n\n---\n\n## Purpose\n\nThe public launch introduces IntegrateWise as **The Operational Capability\nPlatform for the AI Era**. It must make the platform, its twelve Workbenches,\nthe connected ecosystem, developer access, governance, and continuity legible\nas one product story.\n\nLaunch is not permission to claim unsupported coverage. It is a proof-backed\nstatement that the public platform experience is available, safe to evaluate,\nand honest about its current scope.\n\n## 1. Launch thesis\n\n> **AI knows language. IntegrateWise gives it governed operational context,\n> capabilities, and continuity across the systems where the organization works.**\n\nThe launch narrative follows this sequence:\n\n1. Teams, AI surfaces, applications, and data are fragmented.\n2. IntegrateWise connects them through a governed capability fabric.\n3. The Adaptive Spine preserves context and continuity; role-specific\n   Workbenches put the right capabilities into the flow of work.\n4. Governance keeps people in control: the Twin prepares and proposes;\n   consequential actions require approval and produce a receipt.\n\nDo not frame launch as a Customer Success product release, a HubSpot listing,\nor a generic AI-workspace announcement. Those can be launch proof or\ndistribution paths, not the narrative itself.\n\n## 2. Public launch gate\n\nAll conditions below need dated evidence before a launch date is set.\n\n- [ ] The technical production gate in the Go-Live plan is green; no unresolved\n      warning, test/prod-isolation, tenancy, security, or governance exception\n      is hidden by the launch.\n- [ ] The public Platform, Workbenches, Capabilities, Ecosystem, Developers,\n      Resources, and Pricing/activation surfaces reflect current product scope.\n- [ ] A product tour and fallback recording show an actual supported path from\n      context through a governed capability to a human-approved receipt.\n- [ ] The current platform story is demonstrated with real product UI and\n      verified product behavior, not visual concepts presented as implemented\n      product screens.\n- [ ] At least two permissioned proof cases cover meaningful operational work;\n      they may use different Workbenches or ecosystem paths and must state\n      limitations as well as outcomes.\n- [ ] Developer documentation and public contracts accurately state package,\n      Gateway, API, webhook, and capability boundaries.\n- [ ] Security, identity, approval, tenancy, audit, support, incident, and\n      rollback material is current for the scope being offered.\n- [ ] Every public quantitative claim, connector count, named provider,\n      customer logo, certification, and \"one authentication\" claim has a\n      current evidence record—or is removed or explicitly marked roadmap.\n\n## 3. Launch architecture\n\n| Moment      | Story                                                                                              | Essential artifact                                                                                                                              |\n| ----------- | -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| D−21 to D−7 | Define the category and the operating problem: fragmented systems and AI without business context. | Platform page, category narrative, claims register, technical readiness review.                                                                 |\n| D−14 to D−1 | Prove the product architecture through real UI, a role journey, and a governed action.             | Product tour, Workbench demo, governance/receipt demonstration, developer quickstart.                                                           |\n| D-day       | Introduce the connected platform and route each audience to its proof surface.                     | Launch post, platform overview, ecosystem/developer paths, current pricing or guided activation, live support/incident coverage.                |\n| D+1 to D+14 | Deepen proof one surface at a time.                                                                | Workbench stories, capability stories, ecosystem/integration story, developer walkthrough, governance/continuity proof, approved case material. |\n\nThe homepage may use the approved platform or \"Your Last Auth\" campaign line.\nThe latter is conditional: it must not imply universal credential access,\nconnector coverage, or readiness beyond the verified authentication path.\n\n## 4. Day-of runbook\n\n| Window                     | Action                                                                                                                                 | Owner                                  |\n| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |\n| Before public availability | Confirm production release, status route, support coverage, claims, and the live URLs.                                                 | Founder + Platform + Product Marketing |\n| Launch                     | Publish the category announcement and platform tour; route executive, operator, technical, and developer audiences to the right proof. | Founder + Product Marketing            |\n| During launch              | Run rapid triage for product health, support, security questions, and claim corrections.                                               | Platform + Founder                     |\n| D+1 to D+5                 | Publish one proof asset per day: a Workbench, a capability, an ecosystem path, developer access, governance, or continuity.            | Product Marketing + Product            |\n| D+7 to D+14                | Publish only permissioned proof and complete the launch-quality retro.                                                                 | Founder + accountable owners           |\n\n## 5. Measures and launch risks\n\nMeasure audience quality before volume: qualified platform evaluations by\naudience; activation requests; product-tour completion; time to first governed\noutcome; developer-doc activation; support response; proof conversion; and\nclaim corrections required after launch.\n\n| Risk                                             | Mitigation                                                                                                                 |\n| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |\n| \"Another AI assistant\" interpretation            | Lead with the capability fabric, operational ecosystem, Workbenches, and the approval boundary; use real product evidence. |\n| \"Another integration tool\" interpretation        | Show connected capabilities, governed intent, continuity, and role-specific work—not connector count alone.                |\n| Visual concept overpromises the live product     | Mark concept vs. shipping evidence internally; publish only verified UI, functionality, logos, counts, and certifications. |\n| Launch traffic exposes a fragile activation path | Rehearse the supported route, use a waitlist or guided route where appropriate, and keep support/rollback owners explicit. |\n| Security or governance concern                   | Show the current scope, controls, approval boundary, audit path, and documented limitations; never paper over a gap.       |\n\nThe post-launch outcome is a better activation and proof motion, not a vanity\ntraffic spike. If a product, security, tenancy, or governance gate regresses,\npause promotion and communicate only the verified state.\n\n---\n\n**Related:** [00 Current GTM Canon](00-current-gtm-canon.md) · [50 GTM\nStrategy](50-gtm-strategy.md) · [Go-Live and GTM Plan](../../operations/GO_LIVE_AND_GTM_PLAN.md)\n"}