我对 GTM 其实谈不上了解，平时也只是偶尔听人聊起这个方向。今天刷到这篇文章，觉得里面有些观察值得分享。
平时我们讨论具身智能，更多关注模型、数据、硬件和算法，很少从 GTM 的角度去看这个行业。文章提供了一个不太一样的切入点：一项技术从实验室走向真实业务，中间究竟需要解决哪些问题？客户如何理解技术价值，团队又该如何建立信任？这些问题未必直接涉及算法，却同样决定了技术能否真正落地。
当然，文章更多呈现的是这个岗位理想的一面。技术、产品、客户和商业之间的连接听起来很有吸引力，但实际工作远没有那么简单。尤其在早期团队里，很多职责并没有清晰的边界，既要懂技术，又要理解客户，还要对商业结果负责。岗位描述里的空间很大，真正做起来可能也是另一回事。
所以，推荐这篇文章并不是想讨论 GTM 是不是一个值得入行的方向，而是觉得对于做具身智能的技术同学来说，偶尔换个视角看看技术之外的世界，也挺有必要。至于职业选择，还是得看具体团队、职责和实际能获得的支持，别只被一个听起来不错的 Title 吸引。
以下是正文
在 Physical AI 领域工作的经历，让我逐渐理解如何寻找客户、建立技术信任，以及将机器人技术推向市场。
过去几个月，越来越多的人开始问我同一个问题：机器人行业究竟应该如何做 GTM？
有时，提问者是在销售、增长或商务合作领域工作，希望转入机器人和 Physical AI 行业；有时，他们是正在寻找首批客户的创业者，是已经做出令人印象深刻的技术成果、却不知道如何将其转化为商业机会的工程师，也有人只是想了解，一家机器人公司究竟如何从 X 上一个令人惊艳的 Demo，走向真正被客户使用并愿意为之付费的产品。
有一段时间，我很难给出一个简单的答案。在机器人行业工作得越久，我就越意识到其中的原因：这个行业实际上还没有一套成熟、统一的 GTM 方法论。
技术正在以惊人的速度发展。围绕 Robot Learning、Simulation、Teleoperation、Data、Evaluation、Foundation Models、Developer Infrastructure、World Models 和 Deployment Tooling 等方向，新的市场类别不断涌现。几年前，某些公司如今正在商业化的问题，甚至还没有形成明确的软件产品类别。
与此同时，机器人公司还面临着软件公司不必完全面对的挑战：物理世界。硬件必须真正可靠地工作，模型必须能够在受控环境之外运行，系统还必须与现有业务流程集成。机器人需要处理环境变化、系统故障、边缘情况、人、物体，以及现实世界中各种不可预测的因素。
从工程突破到真正部署，中间总需要有人解决一个问题：如何将这些技术能力转化为一门生意？这正是 GTM 要解决的问题。
在参与 Simulation、Robot Data、Developer Ecosystems、Robotics Platforms、Hardware、Partnerships、Outbound、Content 和早期客户需求探索等工作之后，我开始用不同的方式理解机器人行业的 GTM。它远不只是销售、营销、冷邮件，或者在网上发布一些令人惊艳的机器人视频。
在我看来，机器人行业 GTM 的核心，是将技术上的不确定性转化为商业信任。
客户最初会提出一系列问题：这项技术真的有效吗？它能否适配我们的机器人和任务？能否融入现有工作流程？是否值得投入工程资源和资金？
优秀的 GTM 应该逐一回答这些问题，让客户逐渐从对某项技术能力感兴趣，转变为有信心真正采用它。
这正是我希望在本文中探讨的内容，也是我目前在这个行业工作后形成的一些认识。
GTM 远不只是销售
GTM 通常被定义为公司将产品推向客户所采用的策略。这个定义没有错，但对于一家早期机器人公司来说，它并不完整。
在实际工作中，机器人行业的 GTM 可能意味着与机器人研究人员交流，确认你认为存在的问题是否真的存在；也可能意味着研究一家公司的技术栈，判断它是否有可能成为客户；或者与工程师一起确定潜在客户需要看到什么样的技术证据。
它还可能涉及寻找能够提供有价值反馈的首批 Design Partners、设计 Pilot、制作技术 Demo、撰写 Outbound 信息、开展客户需求探索，以及与研究人员和创业者建立联系。
此外，还需要将工程成果转化为内容，让更多人理解这项技术为什么重要。
根据公司的发展阶段，你可能需要同时承担其中好几项工作。有时你在做销售，有时在做研究或内容创作，还有时你需要根据市场反馈，帮助团队调整产品本身。
这也是我认为机器人行业非常有意思的地方。尤其是在产品和市场仍然共同演进的早期创业公司中，工程、产品、销售、商务合作、内容和客户成功之间的边界可能非常模糊。
这也意味着，不同机器人细分领域的 GTM 策略可能完全不同。
机器人行业不存在统一的 GTM 模式
我最早认识到的一件事是，简单地说自己向机器人公司销售产品，实际上几乎没有意义。因为这个行业包含了拥有完全不同客户、产品和商业化挑战的企业。
向仓库销售自主机器人，与销售 Robot Foundation Model 的商业模式完全不同。Simulation Platform 的采购方和技术要求，与 Teleoperation Data 公司也不一样。
Humanoid Robotics 初创公司、Manipulation 公司、Observability Platform，以及机器人开发者生态平台，虽然都属于广义上的机器人行业，但它们面对的用户、预算、销售周期和产品采用动机可能截然不同。
Physical AI 技术栈正在不断扩展，涵盖 Foundation Models、Autonomy、Simulation、Robot Learning、Data Infrastructure、Observability、Hardware 和 Deployment Tooling 等领域。
理解一家公司在整个技术栈中的位置至关重要，因为这决定了谁真正面临它试图解决的问题、谁可能为解决方案付费，以及客户在做出决策之前需要看到什么证据。
因此，我已经不再从“我们应该向哪些机器人公司销售产品”这个问题出发，而是开始问一个更有价值的问题：
我们真正解决的瓶颈是什么？
这看起来只是一个很小的区别，但它会改变后续几乎所有工作，包括如何定义 Ideal Customer Profile（ICP）、如何撰写 Outbound 信息，以及如何与客户交流。
销售瓶颈，而不是销售概念
大多数客户不会每天早上醒来，想着自己需要更多 Physical AI Infrastructure。他们面对的是一个具体问题，这个问题正在拖慢工作进度，或者阻碍他们实现某个重要目标。
对于一个团队来说，收集足够数量的有效机器人数据可能成本高昂、耗时漫长。另一个团队可能已经积累了大量 Teleoperation Data，却不知道如何将其组织成适合训练或评估的数据。
还有一些团队发现，在不断变化的部署条件下评估机器人策略，需要投入过多工程资源；或者机器人在某个环境中表现良好，但场景一旦发生变化，性能就会明显下降。
其他公司可能正在面对系统集成困难、故障难以复现、部署成本高昂，或者某个特定应用场景下自动化的经济性无法成立等问题。
这些都是不同的问题，需要采用不同的 GTM 方法。
将公司描述为 Physical AI Infrastructure Platform，或许能够解释你属于哪个市场类别，却不一定能够说明客户为什么应该关注你。
这一点在机器人行业尤其重要，因为技术本身往往非常令人兴奋，以至于人们很容易将注意力放在系统能够做什么，而不是它究竟能带来什么价值。
一家公司的技术可能非常出色，但客户通常只关心一个更加实际的问题：
这项技术能让我实现什么，是我现在无法做到的？
从描述技术转向理解技术能够带来的实际价值，是我在开展机器人 GTM 时最大的思维转变之一。一旦理解了客户面临的瓶颈，寻找合适客户就会容易得多。
ICP 应该建立在信号上，而不是公司 Logo 上
建立一份看起来很 impressive 的潜在客户名单，其实相当容易，但这并不意味着你真正建立了一个有价值的 ICP。
你可能找到一家大型机器人公司、一家融资充足的 Humanoid 初创公司、一支知名的 Autonomy 团队，或者一个著名研究实验室。公司看起来很有吸引力，技术方向也与行业相关，于是你将它的 Logo 放进 CRM。
突然之间，你似乎已经找到了一批优质潜在客户。
但一家知名公司，并不意味着它就是一个合适的客户。
我现在更加关注的是那些能够表明某个组织确实面临目标问题的信号。
例如，一家公司可能正在将机器人部署到新的环境中，招聘 Simulation Engineer，扩大 Robot Learning 团队，收集 Teleoperation Data，或者开始尝试新的 Manipulation 任务。
其他信号可能来自技术论文、工程博客、招聘信息、产品公告，或者有关 Evaluation、Generalization 和 Deployment 的公开讨论。
有时，一家公司正在内部构建的基础设施，可能与你的产品所解决的问题高度重叠。这也可以成为进一步研究该公司的一个非常有价值的切入点。
当然，这些信号都不能直接证明一家公司的确需要你的产品。它们真正提供的是一个形成假设的依据。
与其仅仅因为一家企业属于机器人行业，就认定它是一个优质客户，不如寻找证据，判断其中某个具体团队是否正在遭遇你的技术能够解决的问题。
这样开展 Outbound 会有效得多，因为你进入对话时提出的是一个经过研究、有具体依据的问题，而不是泛泛的产品推销。
这也让 Outbound 不再只是预约客户会议的工具。
Outbound 也可以是一种市场研究
Outbound 通常被视为一种市场触达活动。寻找潜在客户、撰写信息、预约会议、介绍产品，然后不断重复。
在一个产品类别、购买者和客户需求都已经相当明确的成熟市场中，这种方式可能完全合理。
但在新兴技术市场中，我认为 Outbound 还有另一个重要作用：
它可以成为一种市场研究手段。
每一次客户交流，都是一次学习机会。
你会逐渐发现，哪些问题能够引起客户回应，哪些表达方式更容易引起共鸣，哪些产品能力会被忽略，以及哪些技术问题会被反复提出。
你也会了解到，哪些职位的人能够立即理解问题，哪些组织真正具有采用产品的紧迫性，以及哪些公司虽然觉得技术很有意思，却并不认为它重要到值得真正采用。
你还会发现，哪些团队已经在内部开发了类似方案，他们正在考虑哪些替代产品，以及你在研究潜在客户时做出的哪些假设实际上完全错误。
随着交流次数增加，这些对话会逐渐显现出一些规律。
GTM 活动开始帮助你理解市场本身，而这些信息又可以用于调整产品定位、客户画像、沟通方式，甚至产品路线图。
因此，我不认为早期机器人公司的 GTM 应该始终表现得像是在积极推销产品。
有时，你最应该问客户的问题并不是“你愿意看看我们的产品吗？”，而是：
“你们现在是如何处理这个问题的？”
尤其是在你还不清楚自己的技术究竟适合哪个市场时，这些回答可能比会议本身更有价值。
当然，前提是你愿意带着好奇心与客户交流，而不是假设自己已经完全理解了他们的问题。
不要替客户编造痛点
这是我在技术型客户触达方面最坚持的一条原则。
个性化沟通很重要，前期研究很重要，提出假设也很重要。
但如果你仅仅因为浏览了对方的网站或 LinkedIn 主页，就假装自己已经了解他们内部的问题，很容易失去对方的信任。
例如，下面两种表达之间存在明显区别：
第一种：“我知道 Simulation 正在拖慢你们的部署进度。”
第二种：“考虑到你们正在部署的环境，我很好奇，跨不同条件进行测试是否已经成为团队面临的挑战？”
第一种表达预设了一个你可能根本没有验证过的问题。
第二种表达则说明你已经做了一定的研究，能够提出相关问题，同时也给对方留下了空间，让他们解释自己的真实情况。
机器人行业的受众通常具有很强的技术背景。你联系的许多人，对自己系统的理解可能远远超过你。
如果你夸大产品能力、误解工作流程，或者凭空编造对方并不存在的问题，你很快就会失去技术可信度。
相比一条听起来高度个性化、实际上却建立在错误假设之上的信息，我宁愿发送一条不那么巧妙、但完全准确的信息。
同样的原则也适用于产品本身的描述，尤其是在技术仍处于开发阶段时。
在机器人行业，技术证据胜过产品定位
这是我在这个行业工作以来学到的最重要的一课。
你可以将公司描述为加速具身智能发展、释放可规模化 Physical AI 的潜力，或者构建智能机器人基础设施层。
这些表达听起来可能很有吸引力，但它们并没有回答技术型客户最关心的问题：
它到底能不能真正工作？
物理世界给技术验证带来了异常高的要求。
一个设计精美的产品落地页，无法证明机器人能够在仓库中可靠运行。一句出色的宣传口号，无法证明某个策略能够适应不同环境条件。一份设计精美的演示文稿，也无法证明仿真能够准确复现特定任务中真正重要的现实世界因素。
最终，你必须以客户能够理解和评估的方式展示技术。
如果你销售的是 Simulation，就展示仿真系统，并解释它能够实现什么。
如果你销售的是 Robot Data Infrastructure，就展示数据如何表示，以及如何被实际使用。
如果你销售的是 Evaluation Tooling，就展示评估流程，以及它究竟测量了什么。
如果你销售的是 Teleoperation Infrastructure，就展示真实的工作流程。
如果你销售的是机器人，就展示机器人在明确描述的条件下完成有实际意义的工作。
如果你有 Benchmark，就解释它测量了什么，又没有测量什么。
如果某项能力仍处于实验阶段，就明确说明。如果某项能力只在特定环境中得到验证，就解释验证范围，而不是暗示它能够在所有环境中工作。
技术可信度会随着时间不断积累，但过度承诺造成的损害也会不断累积。
在一个客户通常是工程师和研究人员的行业中，准确说明你已经证明了什么，可能比把产品描述得比实际成熟得多更有价值。
坦诚说明局限性，反而能增强 GTM
这可能与传统营销的做法有些相反，因为传统营销通常希望呈现产品最完美的一面。
但对于新兴技术而言，机器人行业很少能够提供一个毫无瑕疵的故事。
一个系统可能能够完成三个任务，却无法完成十个任务。一个仿真系统可能能够很好地复现某些动力学，却在其他方面表现不佳。一个策略可能在一组条件下具有良好的泛化能力，但环境发生变化后就会失败。
机器人可能大多数时候都能成功完成任务，但仍然存在需要理解和解决的失败情况。
人们的本能反应可能是隐藏这些局限性，但我认为，对于技术型客户而言，这可能是一个错误。
工程师、研究人员、CTO 和 Autonomy 负责人都清楚机器人技术有多么困难。他们未必期待一个完美的系统。
他们真正想判断的是：能否信任这项技术、开发这项技术的团队，以及对方提供的技术证据。
此外，技术型客户在与供应商交流之前，通常已经花费大量时间独立研究产品。
他们希望看到 Demo、技术文档、Benchmark、架构细节，以及来自真正理解技术的人员所做的解释。
有时，你能够传达的最有说服力的信息其实是：
“这是我们目前已经验证的部分，而这些则是尚未验证的部分。”
这听起来可能不如宏大的营销宣传令人印象深刻，但它能够让客户更清楚地理解自己究竟在评估什么。
同时，这也为将真实的工程进展转化为有价值的内容创造了机会。
Content 是 GTM 体系的一部分
机器人行业让我特别感兴趣的一点，是技术内容与商业活动之间存在非常紧密的联系。
一个好的 Demo 可以在潜在客户提出问题之前，就提前回答这个问题。
一篇技术文章可以在销售人员发送 Outbound 信息之前，先建立公司的技术可信度。
创始人对某个工程难题的解释，可能吸引那些正在面临相同问题的人；而一个 Benchmark、部署视频或失败案例分析，也可以成为未来客户交流中非常有用的材料。
因此，我不认为在早期机器人公司中，Content 和 Sales 应该作为两个完全独立的体系运行。两者实际上可以相互促进。
技术型客户越来越倾向于在与销售团队交流之前，先自行研究产品。视频、技术 Demo、文档和工程解释，都会影响他们如何评估一项陌生技术。
机器人行业在视觉内容方面还有天然优势，因为很多工作本身就非常适合通过视频展示。
人们想看到机器人如何运动、如何与物体交互、如何在真实环境中工作，以及环境发生变化时系统会如何响应。他们也想看到任务失败时会发生什么，以及系统能否从失败中恢复。
有时，一段简短的视频就能传达需要好几段文字才能解释清楚的信息。
但这里存在一个重要区别：仅仅看起来令人惊艳的内容，与真正帮助人们理解技术的内容，并不是一回事。
最好的机器人技术内容，不只是展示机器人完成了某项操作，还应该解释为什么这个动作有意义、它解决了什么问题，以及实验结果究竟证明了什么。
当内容被用于建立潜在客户的信任时，这种区别就更加重要。
Demo 和技术证据不是一回事
机器人成功完成一次任务，可以构成一个非常吸引人的 Demo，但这并不意味着它提供了足够的信息，让别人能够评估背后的技术。
一份有价值的技术验证材料，应该能够回答一个具体的技术问题。
例如，它可以展示：
- 某项任务能否稳定、重复地完成？
- 当物体或环境发生变化时，系统会有什么表现？
- 成功是如何定义和衡量的？
- 系统接收了哪些输入？
- 执行过程中是否有人类参与？
它还可以记录失败案例、恢复行为，以及实验结果是在什么条件下实现的。
具体需要提供哪些信息，取决于产品本身，以及客户需要评估什么。
正是这种具体程度，才能让技术进展真正转化为商业证据。
这也给 GTM 团队带来了一项有意思的责任。
如果多个潜在客户独立提出了相同的技术问题，这不一定只是一个销售异议，也可能意味着工程团队应该制作一个 Demo、Benchmark、实验或技术说明，专门回答这个问题。
当这些交流信息被反馈给工程团队时，GTM 就能帮助识别市场最需要哪些技术验证材料。
工程团队随后提供经过验证的结果，而 GTM 团队则负责将这些结果传递给真正需要了解它们的人。
当公司开始与 Design Partners 和早期客户合作时，这种反馈闭环会变得尤其有价值。
Design Partner、POC 和 Pilot 解决的是不同问题
Design Partnership、Proof of Concept（POC）和 Pilot 经常被当作可以互换的概念，但我认为有必要将它们区分开来，因为三者承担着不同的任务。
Design Partner 帮助你理解客户的问题，并围绕有实际意义的应用场景调整产品。
POC 通常聚焦于解决某个具体的技术不确定性。
Pilot 则是在相关客户环境或工作流程中测试一个已经具备一定成熟度的产品，理想情况下，还应该有一条通向商业决策的路径。
对于早期机器人创业公司而言，Design Partner 提供的高质量反馈和学习机会，可能比它能够立即带来的收入更加重要。
最好的早期合作伙伴，不一定是规模最大的公司，也不一定是 Logo 最知名的公司。
它可能是一家规模较小的组织，但确实面临着你试图解决的问题，拥有足够强烈的合作意愿，有愿意投入时间的技术负责人，而且它的应用场景与你最终希望服务的市场足够接近。
Pilot 则需要更加严格的规划，因为它可能消耗大量工程资源。
在启动之前，必须明确：
- 具体评估什么？
- 双方分别承担哪些责任？
- 合作持续多长时间？
- 如何衡量成功？
- 如果 Pilot 成功，接下来会发生什么？
如果缺乏这些预期，一家早期机器人公司很容易花费数月时间进行定制化工程开发，却始终无法建立可重复的商业模式。
一个没有明确后续路径的 Pilot，可能最终变成披着 GTM 外衣的咨询项目。
因此，客户筛选和成功标准，与技术工作本身同样重要。
产品使用者不一定是购买者
机器人 GTM 面临的另一个挑战是，产品使用者、技术评估者、内部推动者和经济决策者，可能是完全不同的人。
假设你正在向一个 Robot Learning 组织销售基础设施产品。
真正使用产品的可能是一名 Machine Learning Engineer，而在组织内部推动采购的可能是 Head of Robot Learning。
预算可能由 VP of Engineering 控制，CTO 可能影响最终决策，最后还可能涉及采购部门。
每个人都在通过不同的视角评估同一项技术。
工程师想知道产品能否改善自己的工作流程，以及能否与现有系统集成。
技术负责人想了解产品能否帮助团队解决重要问题，或者提高工作效率。
高层管理者则可能更加关注战略价值、资源分配、成本，以及这项投资对整个组织而言是否合理。
优秀的 GTM 必须理解这些不同的视角，同时在传达产品价值时，不歪曲底层技术本身。
这与对所有人重复同一套销售话术，是完全不同的能力。
这也是为什么技术素养对于希望进入机器人行业的人如此重要。
从事机器人 GTM，不需要拥有机器人学博士学位
这是我希望更多人理解的一件事，尤其是那些拥有销售、增长、营销或商业背景，希望进入机器人行业的人。
你不一定需要成为机器人研究人员，才能在机器人行业工作。
我自己并不是机器人研究人员。我不设计执行器，不训练 Foundation Models，也不编写运动规划算法。
但如果你希望在这个行业从事商业化工作，也不能一直停留在缺乏技术理解的状态。
你需要理解行业术语，并对整个技术栈具备足够的认识，从而能够跟上工程师和研究人员的讨论。
这意味着你需要逐步理解：
- 为什么需要 Simulation？
- Teleoperation 是如何使用的？
- 为什么 Data Quality 如此重要？
- Evaluation 究竟应该测量什么？
- 为什么 Generalization 仍然是机器人领域如此困难的问题？
你还需要理解，为什么一项技术在仿真中能够工作，并不意味着它在真实机器人上也一定有效。
为什么更换一个物体、环境、机器人本体或任务，就可能引入全新的挑战。
你不需要理解研究论文中的每一个数学公式，但应该愿意阅读论文，并努力理解自己能够理解的部分。
你不需要知道如何实现听到的每一个模型，但应该尝试理解它试图解决什么问题，以及为什么有人会关心这个问题。
批判性地观看 Demo、阅读技术文档、跟进研究进展，以及向工程师提问，都是逐渐建立这种理解的有效方式。
我逐渐养成的一个非常有用的习惯，是坦然承认自己不理解某些东西，并主动请别人解释。
假装理解技术概念，比提出一个经过思考的问题更容易造成伤害，尤其是当你面对的是在某个领域积累了多年专业经验的人时。
一种新的机器人 GTM 职业正在形成
我想写这篇文章的原因之一，是我不断看到一些对机器人和 Physical AI 感兴趣的人，认为进入这个行业唯一的方式就是从事工程或研究工作。
我不认为这是事实。
随着机器人公司从研究逐渐走向商业部署，它们需要能够在工程、客户、产品、商业、内容、社区和部署之间协同工作的人。
这类人的职业画像，可能与传统软件销售或营销人员完全不同。
他们可能特别擅长研究，理解技术内容，并且能够与工程师顺畅交流。
他们可能亲自制作内容、参与客户需求探索、与研究人员和创业者建立联系、管理 Outbound、理解开发者社区，或者帮助公司设计早期 Pilot。
他们也可能经常访问实验室、参加机器人会议、与创业者交流、观察实际部署过程，或者了解不同团队如何解决相同的技术问题。
这些活动背后真正连接它们的，是一种在技术与市场之间进行转换的能力。
我认为，随着 Physical AI 公司逐渐成熟，技术好奇心、沟通能力、研究能力、关系建立能力和商业思维的结合，将变得越来越有价值。
对于今天希望进入机器人 GTM 的人来说，这也是一个令人鼓舞的机会，因为其中许多能力并不需要传统的机器人工程背景就可以逐步培养。
如果今天让我从零开始进入机器人 GTM
如果让我从头开始，我不会首先去背诵各种销售框架，也不会试图一下子成为机器人所有领域的专家。
我会先了解整个行业如何运作，然后逐渐深入自己感兴趣的方向。
我会关注机器人公司的创始人、工程师和研究人员，观看技术 Demo，阅读公司博客，并花时间研究论文，即使最初只能理解其中一部分内容。
我还会尝试理解机器人技术栈不同层次之间的联系，从 Hardware、Perception，到 Robot Learning、Simulation、Data、Evaluation 和 Deployment。
在此基础上，我会选择几个方向进行深入探索。
例如 Manipulation、Humanoids、Autonomy、Teleoperation、Industrial Robotics、Robot Data、Simulation 或 Developer Infrastructure。
当我对基础技术和相关公司有了一定理解之后，就会开始从商业角度思考这些领域。
我会问：
谁真正面临这些公司试图解决的问题？
他们现在是如何处理这些问题的？
问题究竟有多严重？
什么因素会促使他们考虑采用新的解决方案？
我还会尝试理解客户需要看到什么证据，才会真正信任产品；谁掌握预算；以及一家组织在采用新技术之前，需要完成哪些内部流程。
这些都是 GTM 问题。
即使没有人正式给你一个 GTM 职位，你也可以提前开始培养这种思考方式。
随着时间推移，技术理解与商业好奇心的结合，就会成为你与早期机器人公司合作的重要基础。
我一直在思考的 GTM 框架
在参与机器人行业不同领域的工作之后，我逐渐发现，即使产品和客户完全不同，GTM 流程通常也会遵循一个相似的学习循环。
我反复思考的框架是：
Signal → Hypothesis → Conversation → Proof → Pilot → Evidence → Distribution → Expansion
整个过程始于一个 Signal，即某种表明特定组织可能确实面临目标问题的信号。
这个信号可能来自招聘信息、技术论文、产品公告、部署进展，或者此前客户交流中获得的信息。
随后，你根据这些信号形成一个 Hypothesis，判断自己的技术可能在哪些方面提供帮助，再通过 Conversation 验证这个假设是否正确。
这里的目标不是强行让客户接受你已经准备好的产品话术，而是真正理解他们的问题，判断其中是否存在有意义的商业机会。
如果问题确实存在，而且你的技术与之相关，下一步就是建立客户真正需要的 Proof。
根据产品的成熟程度，这可能进一步发展为范围明确的 POC、Pilot，或者其他形式的技术评估。
当这些活动产生有意义的结果时，就会形成可以用来建立可信度的 Evidence。
这些证据可以转化为技术内容、案例研究、Demo、文档，或者其他帮助潜在客户理解产品价值的材料。
随着可信度不断提高，公司就有机会向更多用户、任务、环境、团队或客户扩展，也就是 Expansion。
这个框架让我觉得有意思的地方在于，它实际上并不会在 Expansion 阶段结束。
因为每个阶段都会产生新的信息，并将这些信息反馈到流程的起点。
一次 Pilot 可能揭示一个新的技术问题；一次客户交流可能暴露出不同的应用场景；一篇技术文章可能吸引来自此前从未考虑过的市场细分领域的客户；工程团队也可能从实际部署中学到一些东西，从而改变产品定位。
随着时间推移，ICP 会变得更加精准，沟通方式会更加清晰，技术证据会更加充分，产品本身也能够得到改进。
并不是所有公司都会按照完全相同的顺序经历这些阶段。早期 Design Partnership 或技术评估，也可能发生在产品具备传统 Pilot 所需的成熟度之前。
但整体原则依然适用。
我越来越倾向于将机器人 GTM 理解为一个持续学习的系统，而不是传统的线性销售漏斗。
商业化过程不仅应该帮助公司了解市场，也应该帮助市场了解产品。
对技术型创始人来说，GTM 可以比想象中更早开始
当技术型创始人听到 Go-to-Market 这个词时，有时会想到组建销售团队、制定营销活动、参加行业会议、搭建 CRM，以及追逐收入目标。
这些事情未来可能都很重要，但早期 GTM 可以简单得多。
它可能只是从与 20 个可能面临你所解决问题的人交流开始，了解他们目前如何处理这个问题。
你可以了解他们已经尝试过什么、哪些方案不起作用，以及这个问题是否重要到值得他们投入时间或资金解决。
通过这些交流，你可能会找到几位真正关心这个问题、愿意与你合作的人。
他们可以成为早期 Design Partners，帮助明确技术需求，或者告诉你什么样的技术证据才能让产品真正对他们的团队有用。
你也可能发现，客户真正看重的是技术中与你最初预想完全不同的某个部分，或者你正在开发的产品实际上与他们已经在内部构建的系统有所重叠。
这些都是非常有价值的发现，而且完全可以在产品仍处于演进阶段时获得。
在很多情况下，我认为这恰恰应该发生在这个阶段。
真正的风险不一定是你开始销售得太早，而是你花了太长时间闭门开发，最终才发现市场真正关心的东西与你最初设想的完全不同。
物理世界让信任变得昂贵
软件产品本身已经存在很多采用障碍，但机器人又增加了一层挑战，因为它运行在真实的物理环境中，错误可能带来实际的运营后果。
机器人会与人、设备、商品和基础设施发生交互。
它们可能损坏物体、中断生产、遭遇意外情况，或者需要专业人员进行维护和部署。
硬件可能发生故障，系统集成可能变得非常昂贵，而那些在受控环境中运行良好的系统，在面对真实世界的变化时，表现可能完全不同。
对于考虑采用机器人技术的企业而言，技术性能只是决策的一部分。
它们还需要考虑投资回报率、投资回收周期、总拥有成本、可靠性、集成要求，以及引入这项技术对现有运营产生的影响。
这就是为什么仅仅展示令人惊艳的 Demo，通常不足以说服客户采用产品。
客户需要弄清楚：
系统是否真正有效？是否适用于自己的具体场景？能否与现有环境集成？它带来的收益是否足以证明这笔投资是合理的？
对于机器人基础设施公司，同样的原则也适用于另一个层面。
评估 Simulation、Data Infrastructure 或 Robot Learning 工具的团队，需要确信产品能够改善其技术工作流程中的某个重要环节，并且这种改善值得投入相应的资源。
GTM 的每一个阶段，都应该帮助客户减少一层不确定性。
客户会逐渐从了解技术能力，转向评估技术与自身需求的相关性、测试实际性能、评估系统集成，最终决定是否值得采用或扩大使用规模。
这也是为什么我始终认为，机器人 GTM 的本质是通过理解和证据建立信任。
我们仍处于早期阶段
机器人和 Physical AI 如此吸引我的原因之一，是这个行业仍在以极快的速度变化。
Foundation Models 正在不断进步，Robot Data 正在成为独立的基础设施类别，Simulation 也在持续发展。
World Models 和 Robot Learning 领域的新方法，正在为机器人系统的训练、评估和部署提供不同的技术路径。
硬件公司也在开发新的机器人平台，同时围绕数据采集、评估、部署和监控，正在形成全新的工作流程。
甚至连商业化这些技术所需要的岗位，都还没有形成标准化的职位名称或成熟的职业发展路径。
我们并不存在一套已经沿用了二十年的销售方法论，能够直接用于销售今天的许多机器人产品，因为其中很多产品二十年前根本不存在。
有些产品甚至在五年前都还不存在。
这带来了不确定性，但也为今天进入这个行业的人创造了一个不同寻常的机会。
创始人仍在学习如何为自己的技术寻找合适的市场。
工程师仍在学习如何将研究进展转化为其他组织能够使用的产品。
GTM 从业者则正在学习如何传达技术价值、与专业买家建立关系，以及围绕仍在不断演进的产品建立商业化流程。
今天参与这些工作的人，有机会共同定义下一代机器人和 Physical AI 公司的 GTM 方式。
我认为，真正擅长这项工作的人，会理解一件根本性的事情：
你卖出的不只是一台机器人、一个模型，或者一套机器人软件。
你真正要做的，是建立足够的理解、证据和信任，让另一个人或组织愿意投资一项必须在物理世界中真正发挥作用的技术。
这需要好奇心、技术素养、审慎的研究、良好的沟通能力，以及提出正确问题的能力。
它还要求你诚实地面对哪些东西有效、哪些东西无效，同时花时间与工程师和客户交流，并且愿意随着认知的变化不断修正自己的假设。
我自己也仍然在学习，而这正是这个领域让我觉得有意思的地方。
机器人行业的 GTM 方法论仍在书写之中，而现在，我们每个人都有机会参与其中。
来源：human five
