重新学习，持续成长：市场工作的实践与思考

这篇文章整理自我最近在公司 All Hands 上的一次分享。

前言

今年，为了适应公司的发展需要，我成为了市场部的一员，开始更多地通过文章、白皮书和方案等等，向外界介绍我们的产品，同时身上还兼着一些海外售后和海外售前的活。从我毕业到迄今为止，我一直是一名技术人员，从事 PG 和 GP 相关的工作，所以对我来说，也是一次挺大的转变。今天想借这个机会，分享一下我在这个过程中的心得体会。

技术视角

过去做技术类的工作，目标是清晰明确的：把原理弄清楚，把性能提上去，把问题解决好。

进入市场以后，我发现，对技术的理解依然是根基，但自己的思考方式也需要有所调整。技术出身的人，包括我自己，容易有一种惯性：觉得我们的技术这么好，解决了这么难的问题，产品有竞争力，客户应该能够看到，也应该愿意选择我们。

这可以说是一种”技术本位”的思维，说白了就是酒香不怕巷子深：认为只要技术足够先进、产品足够好，客户自然会认可，市场自然会买单。我们自己对产品很熟悉，知道每一项能力背后花了多少精力，也知道一个技术改进有多不容易。但客户未必了解这些背景，也未必能够直接把我们的技术优势，与他们的场景和问题联系起来。所以，从市场角度思考，就得让客户理解，这项技术为什么与他有关，能够为他解决什么问题，又能带来哪些实际收益。

比如 Domino，从技术角度看，PostgreSQL 经过三十多年的发展，到目前的正式版本，仍然没有原生内置增量物化视图的能力。围绕这个方向，虽然生态中出现了 pg_ivm、pg_trickle 等扩展，各有自己的实现方式，但也有相应的适用条件和限制。作为一名 PG 老油条，我能够理解，在数据库内部实现持续的增量计算，需要解决多少问题，包括双流、三流 JOIN 这些复杂实现。所以，当我看到 Domino 库内流批一体的能力，我清楚它的价值，也能体会到研发在背后的投入。

但站到客户的角度，他并不关心你这项能力背后的艰辛，他关心的是：这项能力能够给我带来什么？对我的架构意味着什么？在同样的场景下，能减少多少 TCO？能节省多少资源和人力？能给业务带来什么改善？

这些，就需要有人帮助客户建立起来这些认知，需要在产品与外界之间做好连接，像一座桥梁：理解技术，理解公司希望传达的产品理念，也帮助客户去理解。

市场视角

刚进入这样的角色，有很多地方需要调整，第一点就是心态的调整。

有技术底蕴在，能帮助我判断一项能力有没有实际应用场景，能解决什么问题，但面对写作、视觉和传播，这些就比较头疼了，毕竟隔行如隔山，所以对我来说，第一点就得调整心态：到了新的领域，允许自己重新学习，再不断打磨精进。我现在还记得，之前写一篇文章，愣是憋了两天还没有想出来，该怎么写，该怎样组织，才能让目标读者愿意看、看得懂。

其次就是文章。

以前写技术内容，我比较习惯顺着自己的理解来写：先交代背景，再介绍原理，接着展开实现细节，有需要就把源码也放上去，巴不得抠到一个宏、一个变量是什么意思，乐此不疲。

现在写面向市场的技术文章，如果还是按部就班，用之前的老一套打法再来写的话，我作为一名读者，看到洋洋洒洒几千字，也会望而却步，一大堆代码，我连看下去的勇气都没有。所以动笔之前，我们得先想清楚：这篇文章写给谁？他为什么会点进来看？看完以后，我希望他记住什么？

在此期间，我也学习了一些营销和传播方面的方法：

1. 《跨越鸿沟》书里讨论了早期采用者和主流客户之间的差异。早期用户更容易被创新和愿景吸引，被你的故事吸引，而主流客户、大客户则更看重确定性。他会关心，有没有同行用过，实际效果怎么样，实施和使用的风险有多大。

   所以案例非常关键：主流客户不喜欢做第一个吃螃蟹的人。案例的宣传重中之重，这也是市场部后面的重点。大家平时也能看到，一些厂商会宣称 xxx 第一，有人开玩笑说，”只要前缀够长，人人都是第一”。这个玩笑背后，其实也反映了客户的一个需求：他希望找到在自己所在领域有经验、能够让自己放心的供应商。

   对我们来说，明确细分场景，再用真实案例和可验证的结果支撑，才能让客户的信心有依据，所以我现在写文章，都会避免全篇一大堆文字，显得空洞无物，还会搭配一些实测数据，案例场景结果等等，再辅以一些图片、表格数据等，在表达力上，图片 > 表格 > 文字，毕竟一图胜千言。

2. 其次，在《疯传》这本书里面也特别提到了社交货币、触发物、情绪、公共性、实用价值和故事。简而言之，传播不是技术成功之后自然发生的附属品，它本身就是产品能力的一部分。内容能否被传播，也需要在写作时认真考虑。读者为什么愿意转发？可能是里面有一个能拿去用的方法，有一个讲清楚问题的故事，或者有一张图，正好能够帮助他和同事沟通。我之前观察过，之前写 Ic-tunnel 的那篇文章，标题是《从 TCP/UDP 到 Tunnel：YMatrix 如何破解 MPP 大规模集群通信瓶颈》，读者一看这个标题，就会自然联想到当前传统 Greenplum 下的通信痛点，UDP 和 TCP 的各种不足，也会想一探究竟，看看我们究竟是如何解决的，这就对应到了《疯传》中的“实用价值”“情绪”和“触发物”。

3. 其次，面对不同的读者，虽然技术事实是一样的，但信息出现的顺序、例子的选择，以及细节展开的程度，都需要调整。

借鉴：带着问题读同行的文章

我自己平时还时不时喜欢去浏览一下其他友商官微发布的内容，比如 OceanBase、TiDB、TDSQL，看的时候，我就会想：

1. 为什么取这个标题？是这个标题吸引了我点进去，还是其他什么动机？

2. 为什么从这个场景开始？

3. 文章中哪些细节展开了，哪些只点到为止？

4. 产品在什么地方出现，又怎样自然地衔接前面的场景，而不是十分生硬的硬吹？

5. 读完以后，我也会问自己：我记住了什么？哪些表达方式可以借鉴到自己的工作里？

见贤思齐焉，这个过程，也是在练习怎样兼顾表达效果和技术准确性。一篇好的文章，确实有机会带来商机，帮助我们发现新的场景。

之前，我在官微发布了一篇《CittaBase vs. Neo4j：原生图性能实测与混合检索实践》。文章发布后，一家电池制造企业的客户联系了我们，随后我们组织了一次会议，进一步了解他们的业务场景。

客户关注的是生产和供应链中的追溯问题，希望了解图查询能否适用于自己的业务。

这篇文章让客户把自己的问题与我们的图能力联系了起来，也为团队带来了一个进一步交流的机会。

这件事让我更具体地感受到，文章能够成为客户认识产品、提出需求的一个入口。把技术讲清楚、把场景讲具体，确实有机会推动后续的业务交流。

海外：从客户的实际环境理解产品

今年，我本身还在兼着一些海外售后的事情，这可以让我对技术保持一个敏感度，刀还是要时常打磨一下；其次，便是海外售前，会有一些海外项目的售前沟通，也让我开始关注更多技术之外的问题。

To B 产品出海：技术是入场券，商业才是护城河，商业才是天堑，所有技术层面的问题，我觉得说到底都是工程问题。工程问题最大的特点：有解法，可预判，可控。技术是有答案可参考的，但 To B 出海的商业策略，是没有题库的实战博弈，变数很大。

1. 第一关：信任，最难跨的地缘鸿沟。海外大企业优先选本土老牌厂商。客户会反复掂量：这家来自中国的厂商，三年后还能不能提供服务？系统出问题有没有兜底？地缘风险会不会影响供应链？

2. 第二关：完全陌生的决策链路，有的地方一切按流程走，不谈人情；有的市场，本地渠道牢牢把控资源，外来公司想直接触达决策者几乎不可能。

3. 第三关：交付和售后，藏着无底洞的成本，海外人工贵、时差大、备件周转慢。国内一套轻车熟路的交付流程，搬到海外，成本可能就直接翻倍了，周期也会拉长。

4. 第四关：本地化认知，最容易被低估，国内客户要的功能，海外客户可能根本不在意（比如国产化）；国内无关紧要的细节，反而是海外客户的核心诉求。市场痛点、竞品打法，每个国家地区都可能还不一样。有些海外客户尤其关注 GDPR、数据安全、数据合规，以及稳定性。

这些海外售前和售后的沟通，也能帮助我从更全面的角度思考问题和理解产品。

技术经验、市场表达和客户沟通，就这样相互帮助，也让我有机会从更多角度理解产品。

小结

回头看，今年的变化让我对”重新学习，持续成长”有了更具体的感受。

愿意接受挑战，认真去面对、去尝试，确实能够做到一些过去觉得自己做不到的事情。现在是 AI 时代，每个人的边界都可以被无限放大。

公司正处在发展的过程中，产品和业务都在不断向前，也会出现新的任务、新的角色和新的机会。大家在熟悉自己的专业和工作以后，如果有想尝试的方向，或者看到一个自己愿意参与的问题，可以主动和自己的 leader 聊一聊。

聊聊自己的兴趣，聊聊希望发展的能力，也聊聊团队有哪些事情，可以让自己参与进来。可以从一个具体任务、一次协作开始，给自己一次尝试的机会。

重新学习，需要我们愿意迈出那一步；持续成长，就在迈出这一步之后，一件一件把事情做好的过程中。

希望我的这些经历，能给大家一点参考，也带来一点尝试新事情的信心。