「X 增长」专栏是我们与 ExponentialX 一起打造的关于 SaaS 与 AI 公司在增长、市场等策略的方法论和实践分享栏目。
有时，过时且臃肿的 GTM 技术栈会阻碍我们自信地执行 GTM 策略。对于结合了 PLG、销售辅助和规模化/AI 驱动的 Outbound 策略的现代软件企业来说，GTM 技术尤其令人痛苦。
如果你问十个人谁是现代 GTM 技术的专家，大概会有八个人告诉你 Austin Hay。Austin 在 Reforge 教 THE MarTech 课程，他曾在 Ramp、Runway、mParticle 和 Branch 等快速成长的企业领导过增长和 GTM 技术团队，目前是 Clarify 的联合创始人。本篇文章我们来一起了解一下 Austin 是如何构建适合阶段并且持久的技术栈的吧~
原文来自：https://www.growthunhinged.com/p/the-next-era-of-gtm-tech
随着对复杂 Outbound 策略关注度的提升，营收团队投资 CRM 技术栈的需求和愿望也变得越来越迫切，就像曾经投资平台技术栈一样。但是，作为营收专业人士，在没有营销同行所拥有的丰富选项情况下，我们如何才能更好地利用工具，而不只是购买更多的基本操作工具，最终陷入技术债务、臃肿和成本高昂的困境？这是一个难以单独回答的问题。但第一步是很明确的，那就是要更好地理解过去的发展过程，以及 CRM 在未来中扮演的角色。在过去十年中，CDP 和 CRM 成为了 MarTech 和 RevTech 中心的概念已经巩固。我们可以将这种巩固分为四个时代：
接下来，Austin 分享了他在过去十年中帮助数十家科技公司创建和维护 GTM 技术栈的过程中获得的宝贵经验，还将讨论当前 RevTech 技术栈的现状，以及现代 PLG 公司如何构建灵活的技术栈。现代 GTM 技术栈围绕四个核心数据组件构建：输入（从哪里获取客户数据）、存储（在哪里保存客户数据）、功能（丰富数据的工具或如分析工具等终端），以及联合（数据如何在其他组件之间移动）。
一个 GTM 技术栈的“好坏”与上述类别中任何单个工具的质量关系不大，更多地取决于它们之间的协作程度。这就是我们所说的技术栈灵活性，也是当今运营收入和 MarTech 系统的关键。- 新的营销和营收挑战需要移动更多数据。 如果你因为供应商或系统复杂性无法移动数据，那就会陷入困境。
- GTM 团队需要快速构建受众和细分群体。灵活性让你能够在各种工具中创建受众，并将受众快速分流，尤其见效于采用数据仓库组织最优先级的业务的情况。
- 公司需要避免产生技术债务和复杂性负担。临时的业务挑战（比如在大型邮件营销活动前发现你的 DTC 供应商在最后一刻更改了 API）需要速度和能力来妥善处理，才不会导致更多的技术债务和系统复杂性。
- 业务需求和工具选择变化迅速。 拥有高度灵活的技术栈意味着你可以轻松地引入和撤换供应商，创建符合你独特需求的最佳工具系统，同时不会混淆或给团队或合作伙伴带来负担。
- 构建世界级软件需要世界级的调试能力。 技术栈的灵活性让你能够快速找到、评估、调试、升级、分类和解决技术栈问题。
简而言之，技术栈的灵活性为 PLG 和 B2B2C 公司提供了支持复杂客户旅程所需的底层灵活性，并使公司能够洞察用户和产品在不同渠道的互动方式。那么，我们如何构建既灵活又耐用的技术栈呢？这是一个复杂的问题，但通过多年来的经验，Austin 开发了一个解决这个问题的框架，这也是他在 2022 年指导 Ramp 前进时使用的框架。注意：要使这个框架发挥作用，营收活动需要被视为一种工程学科，即更多的团队应该在 GTM 机制中投资工程师。
- 好处：为离散、去中心化的操作提供灵活性（例如，两个工具链接受众）。
- 坏处：完全相同的功能导致混淆（例如，两个归因工具）。
- 好处：低依赖性便于更换供应商（例如，围绕 CDP 的分析库）。
- 坏处：单一工具瓶颈在移除时会破坏系统（例如，随机连接）。
- 好处：高数据交换能力满足业务任务（例如，推送/拉取/受众集成）。
- 坏处：不兼容迫使采用变通方案（例如，脆弱的 Hubspot 集成）。
- 好处：有针对性地解决问题，推动良好决策（例如，数据图表、权限）。
- 坏处：不清楚最佳用途，与不良耦合相关（例如，追求新奇工具而不加以精简）。
现在 GTM 工具的选择比以往任何时候都多，其功能和质量千差万别。接下来，我们将回顾 RevTech 领域是如何发展到这一步的，以及现代组织可以做些什么来确保其技术栈在未来发展中的稳定性。
"技术栈"的概念并非新事物，就像 GTM 领域中的许多元素一样，它的根源可以追溯到工程学。
工程师们一直基于已知的框架、工具、语言和服务构建基础设施技术栈。这些"构建块"创造了大量的变化和灵活性，但通常围绕着一个随技术改变而波动的中心重力工具。这个概念在 2015 年左右真正渗透到 GTM 技术领域（以 CRM 为重力中心），并演变成今天许多现代组织使用的去中心化 GTM 技术栈。以下是 Austin 在过去近十年见证的 GTM 技术栈演变的四个不同时代的概述。第一个时代：销售技术（2015年）
2015 年时 Austin 与 Mike Molinet 在 Branch 工作，用当时可用的工具组建了第一个版本的 RevTech 技术栈。它遵循以下基本结构：2015 年 Branch 的原始技术栈图
自此之后，事情变得更加复杂、更加集成、更加自动化。第二个时代：B2C 营销技术（2017年）
传统上，MarTech 技术栈是一个 B2C 特定的技术栈或一组相互连接的工具，用于帮助营销人员接触、获取、增长、留存和变现用户。它具备各种功能，并且相互连接以实现易于归因和规模化。这个定义在 2017 年成为了常态。不再是围绕 CRM 作为中心重力，B2C 公司转而围绕 CDP 进行布局。这种营销技术方法在几乎所有 B2C 公司中都运作良好，因此它具有高度的可重复性，并围绕两个核心组件：- CDP（加载在应用程序前端，将受众和数据流向下游工具）
一旦 B2C 公司具备了这两个核心能力，通常会看到一系列功能被添加到其体系中：- 营销获客（SEO 和 SEM、联盟营销和深度链接）
根据业务的规模、阶段和复杂程度，营销团队会从上述菜单中选择更多或更少的工具。随着这些功能变得更加技术密集（并进入工程领域），许多公司在这些方面之间的界限变得模糊。
第三个时代：B2B2C GTM 技术（2022年至今）
近几年出现了一个新的商业类别：B2B2C（或同时服务个人和团队的公司）。像 Notion、Figma 和 Canva 这样的产品就是其中的佼佼者。其结果是尝试统一 CDP 和 CRM 之间的数据。营销和销售团队不再孤立工作。B2B2C 商业模式（尤其是在产品主导的组织中）要求 GTM 团队密切合作，整合他们的目标，进而整合他们的工具。因此，有效的 GTM 运营需要一个集成的技术栈，反映使用这些工具的团队（销售和营销）和最终产品用户（团队和个人）的集成性质。为了实现这一点，公司必须专注于创建一个高度灵活的技术栈，注重冗余性、耦合性、互操作性和专注性。GTM 技术栈的成熟度（以及什么是"好"）因公司成熟度而略有不同。以下是不同成熟阶段的收入技术栈的几个例子，以及在每个规模下应该关注资源的地方。
早期阶段示例：Thena
要了解早期阶段堆栈的样子，没有比查看客户对话平台 Thena 更好的例子了。去年，种子轮融资的 Thena 通过使用现成工具（如 Keyplay、Clay 和 Clearbit）复制了 5 到 10 名 SDR 的工作。今天，这个技术栈在规模和复杂性上都有所增长。在早期增长阶段的公司中，快速获取工具以应对手头的工作是一种常见的主题。这个技术栈之所以出色，原因很简单：有很多工具来处理很多工作。与其雇用 10 个人来解决基本的 SDR 问题，不如用 10 个工具来代替。这保证了来自各种渠道的稳定潜在客户流量，同样，也带来了一些惊喜和意外收获。如果你生活在一个通过手动 Cold Outreach 获得潜在客户的世界，早上醒来发现邮箱里全是安排好的电话会议，而无需付出任何努力，这确实是令人愉悦的。这种早期工具激增的另一面是维护成本。他们不需要 10 个 SDR，但需要同样多的时间来设置、管理和维护技术栈。这是 GTM 工具扩展后早期团队面临的后果之一。即使你可以用 10 个互相连接良好的工具完成所有想做的事情，你是否能继续维护它？如果出现问题怎么办？"在构建我们的技术栈时，我们面临的最大问题之一是过度构建。我们采用了企业 SaaS 的方法来构建大部分 GTM 技术栈，尽管我们没有足够的人来管理这些工具。起初，我们感觉很好，因为我们能够通过添加自动化工作的工具来有效地从过程中移除人员。但最终，我们有了太多的工具，变得难以管理。在 2024 年春天，我们开始减少使用的工具数量。" — Brendan Kazanjian，Thena 的增长负责人
随着公司获取新工具并在 GTM 技术栈的复杂性的攀升，他们也需要考虑下后续情况。自动化工作的工具可以刺激增长，但是可能没有足够的人力来管理这么多的工具。成长期示例：Postmates
Postmates 的技术栈在 2017 年就已经非常出色了，它有效地复制了一个现代数据技术栈，而这远早于相关知识、工具和能力的普及。特别是，Postmates 在数据收集方面做得非常出色。他们有一个增长产品团队，积极利用 CDP 来跟踪用户和事件。同样，他们坚持通过这个 CDP 传输数据，传递给下游提供商，避免了当时其他公司面临的许多数据往返和重复 SDK 问题。最后，他们自发使用其技术栈来推动增长活动。每当出现新的活动时，他们都会问："我们如何能快速解决这个问题并用试验我们的技术栈？"今天，每个人都认为设置新工具和尝试新功能是理所当然的，但在 2017 年，这是一种新颖的做法。这个技术栈带来的最大挑战是 Postmates 自己造成的。由于在还没有工具来管理第三方资料的情况下就广泛使用了 CDP，这使得技术栈变得难以管理。特别是，Postmates 将实验属性标记到每个用户的配置文件上，但没有使用一个带有轮换值的实验键，而是将每个新实验定义为一个新键，这导致了配置文件记录上的属性膨胀。同样，当时还没有像 2020 年出现的 Iteratively、Avo、Segment protocols 或 mParticle Data Master 这样的数据治理工具。因此，经过四年工程师添加带有定制事件属性的事件后，他们的数据库变得一团糟。今天，如果你从头开始使用 CDP，你可以实施模式来控制进入 CDP 的内容。
规模化示例：Ramp
尽管 Ramp 的目标是为企业提供公司信用卡，但获客漏斗主要以用户为中心。这种模式要求在顶部有一个类似于 CDP 的技术栈（专注于获客），同时在底部有一个以 CRM 为中心的技术栈（专注于企业销售参与）。Ramp 的 GTM 技术栈在某些领域效率非常高，而在其他领域则可以作为一个警示案例。在工具使用方面，特别是在优化方面，Ramp 经常进行类似”断舍离“式的整理，无情地审核他们的工具。如果一个工具找不到它的用途，或者如果用供应商工具替换定制工具更好，他们就会移除它。这有助于整合和集中重叠的功能，并实施基于 SQL 的治理流程。示例：Ramp 的营销团队使用大约五种不同的工具来创建细分和受众，并将所有这些整合到 Hightouch 中，以充分利用仓库中的数据。
然而，没有哪个技术栈是完美的。Ramp 倾向于构建定制、专门的部分，这使得在出现问题时难以替换工具，造成了对工程团队的依赖。此外，还在 HubSpot 和 Salesforce 之间进行了双 CRM 协作，这迫使他们将数据同步到上游工具。有时简单确实更好，特别是在涉及复杂系统的数据时。（技术栈的复杂性通常归结为拥有多少连接以及这些连接的顺序）
无论你的业务处于哪个阶段，都需要在技术栈中做出权衡，以平衡当前的需求与未来的技术债务。不要试图一开始就掌握所有的工具领域。相反，应专注于几个主要领域，并在需要它们之前，在其他领域做得足够好。这里有一个简单的指南，告诉你在不同阶段应该将注意力集中在哪些地方：随着你变得更成熟，尤其是进入增长阶段并进行更多能力评估工作时，您将需要建立仪式来定期审核您的技术栈并了解它所满足的需求。Austin 提供了 Reforge 课程中的 Martech 规格表和技术审计模板，可能有助于您开始处理这项工作，关注并后台回复“ReforgeMartech”即可获得。
工具的爆炸性增长赋予了现代公司混合搭配其技术栈以适应日益复杂的使用案例的能力，但这也增加了出现不良冗余、耦合、互操作性和专注性问题的可能性。
在 Martech 方面，市场变得越来越嘈杂，如可组合 CDP 的兴起，以及越来越多的工具提供数据收集、联合和受众群体创建的核心能力，如 Amplitude、Hightouch、Rudderstack、Snowplow 或 Braze。
虽然 Martech 方面的创新已经取代了一些传统供应商，并给了用户更多选择，但现在我们才刚刚开始看到类似的变革压力被施加到 CRM 解决方案上（主要是 Salesforce 和 HubSpot）。
然而，随着现代 CRM 相关技术专注于更高级的使用案例，比如自动化 Outbound 活动，它们的风险变得像 Martech 领域一样嘈杂和饱和。CRM 仍将继续作为数据收集、联合和受众管理的核心，但它们必须进化以更好地服务于营收团队，通过提供预测和可行的见解。
现代的产品主导型团队值得拥有更好的方式来建立关系和发展营收，无需将大部分时间花费在管理工具和与客户沟通上。可以构建出足够智能的 CRM，它知道何时以及如何调整方向来为你管理复杂性，并帮助你建立更好的客户关系。