{"slug":"strategy/business-strategy/50-gtm-strategy","title":"50 — GTM Strategy","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/50-gtm-strategy.mdx","bytes":9060,"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).\n\n---\n\n## Purpose\n\nThis is the operating strategy for taking the Operational Capability Platform\nto market. It turns the commercial canon into a focused motion without reducing\nthe category to a single department, connector, or AI surface.\n\n## 1. The motion\n\n> **Category-led, activation-assisted, proof-gated:** establish IntegrateWise\n> as the operational capability platform; activate a bounded ecosystem around\n> a material operational problem; prove a governed outcome; expand through\n> additional Workbenches, capabilities, and connected systems.\n\nThe category story creates demand. Guided activation turns demand into a safe\nfirst result. Proof—not a logo, a connector count, or a launch date—earns the\nright to repeat and expand.\n\nCustomer Success with HubSpot can be one early proof motion. The same is true\nfor Sales, Operations, Finance, or another operational Workbench where the\nsupported capability and evidence path are stronger. None is described as the\ncompany's sole wedge in public positioning.\n\n## 2. Market map\n\n| Audience                                    | Commercial question                                                                | Entry proof                                               |\n| ------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------- |\n| Executive sponsor                           | Can we make AI, teams, and systems a governed operating capability?                | Platform map, control boundary, and cross-system outcome. |\n| Operational leader                          | Can this role act with the right context rather than reconstructing it?            | Role-relevant Workbench and an approved workflow.         |\n| IT, security, and governance                | Can we enable it without weakening identity, policy, approvals, tenancy, or audit? | Architecture, governance path, and receipt.               |\n| Developer, architect, and ecosystem partner | Can we discover and extend supported capability safely?                            | SDK/API/MCP quickstart and a supported integration path.  |\n\nThe first evaluation must have a sponsor, a work owner, and a technical/control\nowner. If one is missing, the motion is education or discovery—not an\nactivation commitment.\n\n## 3. Activation and proof playbook\n\n| Step     | Decision                                                                        | Evidence before advancing                                                            |\n| -------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |\n| Qualify  | Is there a material cross-system operational problem and accountable champions? | Current process, expected outcome, affected systems, authority, and success measure. |\n| Bound    | Which supported systems, capability, Workbench, and policy scope will be used?  | Written scope, security/identity path, and no unsupported product promise.           |\n| Activate | Can the organization reach useful context and an available governed capability? | Working connection/onboarding path and an active user/work owner.                    |\n| Prove    | Does the platform complete an approved, auditable outcome?                      | Evidence → proposal → approval → execution → receipt, plus a documented result.      |\n| Expand   | Where does the next outcome compound value?                                     | A named next Workbench, capability, team, or system with a sponsor and rationale.    |\n\nThe selling unit is not a generic demo. It is a credible path from a real\noperational problem to the first governed outcome in the customer's connected\necosystem.\n\n## 4. Channel architecture\n\n| Channel                           | Role now                                                                                                                          | Measure                                                                             |\n| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |\n| Platform website and product tour | Explain the category and route each visitor to Platform, Workbenches, Capabilities, Ecosystem, Developers, Resources, or Pricing. | Qualified route completion and high-intent activation requests.                     |\n| Founder and operator content      | Teach operational continuity and governed intelligence with concrete operating stories.                                           | Qualified conversations, audience fit, and message restatement.                     |\n| Guided activation                 | Convert evaluation into a bounded proof without compromising governance or technical safety.                                      | Time to first governed outcome and proof completion quality.                        |\n| Developer and MCP ecosystem       | Build technical trust and enable supported extension.                                                                             | Documentation activation, public SDK use, and supported integration completions.    |\n| Customer/design-partner proof     | Turn permissioned results into credible proof for the next buyer.                                                                 | Attributable evidence and approved case material.                                   |\n| Partners and marketplaces         | Extend distribution only after support, ownership, and product scope are ready.                                                   | Qualified, supportable opportunity—not listing count.                               |\n| Paid acquisition                  | Deferred.                                                                                                                         | Reconsider only when activation, conversion, and retention economics are evidenced. |\n\n## 5. Phases and gates\n\n| Phase      | Objective                                                                                    | Exit evidence                                                                                |\n| ---------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |\n| Foundation | Align product scope, story, website, developer path, claims, and release readiness.          | The technical go-live gates pass; the public story maps to live/releasable capabilities.     |\n| Prove      | Validate the activation-to-outcome path across more than one applicable operational pattern. | Permissioned outcomes, current evidence, and a repeatable activation checklist.              |\n| Launch     | Make the category visible with proof-backed platform and ecosystem assets.                   | The launch gate in [51](51-launch-strategy.md) passes.                                       |\n| Repeat     | Make discovery → activation → first outcome → expansion reliable.                            | Consistent buyer/champion pattern, delivery capacity, and conversion/retention evidence.     |\n| Expand     | Invest in partners, marketplaces, and scalable acquisition.                                  | Supportable partner motion and channel economics; no unresolved governance or release risks. |\n\n## 6. Founder operating rhythm and scorecard\n\nDuring Foundation and Prove, founder GTM time should favor direct learning over\nvolume: customer/operator discovery and guided activations; the category and\nproof content that explains those learnings; technical/security conversations;\nand one weekly evidence/claims review. The exact time split follows active\npipeline and release readiness, not a fixed Customer Success quota.\n\nReview these weekly:\n\n- Qualified evaluations by executive, operator, technical, and developer lane.\n- Time from activation to first approved governed outcome.\n- Active Workbenches, capabilities, and supported connected systems per\n  activated organization.\n- Approval-to-receipt completion, support load, and governance/security gaps.\n- Proof inventory, permissions, and public-claim freshness.\n- Conversion and expansion signals only after the corresponding evidence is\n  mature enough to interpret.\n\nNo launch, paid program, or broad partner commitment overrides a failing\ntechnical, security, tenancy, or governance gate.\n\n---\n\n**Related:** [00 Current GTM Canon](00-current-gtm-canon.md) · [51 Launch\nStrategy](51-launch-strategy.md) · [Go-Live and GTM Plan](../../operations/GO_LIVE_AND_GTM_PLAN.md)\n"}