"挺好的，我们内部再看看。"
这是客户会议结束时最常听到的一句话。
对一个刚转销售的工程师来说，杀伤力很大。
它不像拒绝，更像一个没有堆栈信息的异常。你知道哪里不对，但不知道从哪一行开始查。你甚至会开始怀疑：是不是那张架构图没讲清楚？是不是 demo 不够丝滑？是不是竞品参数没有对比完整？
我在这种茫然里待了很久，才搞清楚一件事。
问题从来不在产品。问题在视角。
工程师转销售，通常带着一个隐形假设：
懂技术、懂产品，这是天然优势。
这句话只对了一半。
懂产品是入场券，不是成交按钮。工程师最容易踩的坑，几乎全都不是能力问题，是视角问题——你一直在用解决系统问题的方式，处理人的决策问题。
这两件事表面上像，底层完全不同。
你以为销售是"把产品讲清楚"，其实销售是帮客户完成一次困难的决定。
Neil Rackham 在 1970 年代主导了一项研究，覆盖几万次真实销售拜访，最后写成了《SPIN Selling》。
他们发现了一件反直觉的事：特性说得越多，成交率越低。
尤其是技术背景的销售，越爱把产品能力讲完整，客户越容易陷入"信息量足够，但就是不往前走"的状态。
我没有核过他们的原始数据，但那个方向的结论，在我身上完美复现了。
工程师进销售之前，在技术世界里待了很久。那个世界有一套奖励机制：细节越清晰，方案越严谨，你就越可信。这套机制在工程世界里是对的，但带进客户现场之后，它会在错误的时间点火。
第一次见客户之前，我准备了十几页材料。从产品架构讲到性能指标，从部署方式讲到边界条件，从安全机制讲到未来路线图。
我以为讲得越完整，客户越有安全感。
客户听完，说："挺好的，我们内部再看看。"
然后消失了。
后来还有一次，客户其实从一开始问的就是"上线周期会不会拖垮我们团队"，我却花了整段时间讲系统能力。讲完之后，客户问了一句："所以我们大概多久能跑起来？"
那一刻有点尴尬。
因为我意识到，客户从一开始就在问交付风险，而我一直在回答产品能力。
我把自己想证明的东西，当成了客户想知道的东西。
一：把客户会议开成了技术评审会
客户会议不是技术评审会。
工程师只要感觉到客户有一点兴趣，就会自动加码：这里有个核心模块，这里有个异步队列，这里有个我们内部很骄傲的优化点。讲得很开心，客户也很礼貌，但会议结束之后推进往往很慢。
复盘才发现：我在讲"我们做了什么"，客户想听的是"这和我有什么关系"。
客户判断的不是产品有多强，而是三件事：这个问题值不值得现在解决？这家公司靠不靠谱？如果我内部推动这件事，我站不站得住脚？
工程师习惯证明方案是对的。销售要先证明问题是值得被解决的。
顺序反了，什么都白讲。
后来我调整了会议的重心：以前先讲产品，现在先问现状；以前先讲架构，现在先问业务流程；客户问"你们支持什么功能"，以前立刻列清单，现在多问一句——"你们为什么现在关注这个功能？"
这不只是话术变化，是重心变化。
二：把客户说出口的需求当成了真实问题
好，那把顺序调过来就行了？
不够。
客户说出来的需求，经常只是他对问题的自我诊断。
他说要自动报表，可能真实问题是老板每周追数太痛苦；他说要自动化，可能真实问题是团队协作混乱；他说"先看看"，可能不是没有需求，而是没有形成紧迫感。
这和排查线上故障很像：报警显示 CPU 飙高，不等于根因就是 CPU 不够。工程师都知道不能只盯表象，但到了客户现场，我一开始经常忘记这一点。
symptom 不是 root cause。
后来我给自己定了一个规则：客户提出一个需求，至少追问三层——"你们为什么现在想做这个？""现在不解决，三个月后会发生什么？""这个影响主要落在谁身上？"
一开始问起来很别扭。工程师常常怕打扰别人，怕显得自己不懂。但慢慢发现，真正有问题的客户并不讨厌好问题。问到点上时，客户会开始讲背景、讲内部矛盾、讲决策卡点。
那一刻销售才真正开始。
三：以为懂产品就等于会卖产品
那真的吗？
懂产品面对技术型客户确实是优势，能接得住细节，能讲清楚边界。但懂产品不是成交按钮。
我刚开始时，以为只要把产品讲透，客户就会买。后来才发现，销售不是把产品从复杂讲到更复杂，而是把产品翻译成客户能决策的语言。
客户买的不是"分布式架构"，他买的是高峰期不要宕机。
客户买的不是"低代码能力"，他买的是业务部门不用每次都排 IT 需求。
客户买的不是"权限体系"，他买的是出了问题能追责、敏感数据不乱飞。
产品语言回答"它是什么"，客户语言回答"它帮我变成什么"。
如果一个功能不能对应到效率、成本、风险、收入这些客户在意的结果，再漂亮的介绍也只是自我感动。
不相关，比不完整更致命。
四：把每条线索都当 bug 一样认真处理
这件事还没完。
还有一个更反直觉的坑——不是所有线索都值得认真推进。
工程师看到问题，本能是修。这在技术世界里是责任感，但到了销售里会变成另一种误判：把所有"可以聊聊"和"有机会合作"都当成真实机会。
后来我才明白，销售的专业性不只体现在推进机会，也体现在识别哪些机会不该推进。
有些客户没有预算，有些没有明确痛点，有些只是在收集资料，有些不是决策链上的关键人，有些看起来热情，实际上只是礼貌。
工程师世界里，未解决问题越少越好；销售世界里，不该解决的问题越早放弃越好。
满但虚的销售管道，会制造一种危险的安慰感。你以为自己有很多机会，其实很多只是停在表格里的幻影——不会拒绝你，也不会推进，只会安静地占据你的注意力。
忙，不等于有效。
五：低估了销售里的反馈密度
写代码时，反馈很直接。编译过不过，测试红不红，日志报不报错。系统至少会给你信号。
做销售不一样。
客户不给你报错信息。
他只是沉默。不回消息，不约下一次会议，只说"我们再看看"。你不知道是价格问题、需求问题、时机问题，还是你上一通电话里某句话让他失去了兴趣。
这让我一开始特别不适应。工程师熟悉的是显性反馈，销售里的很多反馈是隐性的、延迟的、需要主动挖出来的。
所以很多坏习惯，销售新人自己不知道。开场太长，太快进入 demo，没有确认下一步，客户说"挺好"就以为机会很热，会议结束后只发资料不推动具体行动。这些动作单独看都不大，重复十几次之后，就变成稳定的失败模式。
我以为销售靠表达，后来发现销售更靠复盘。每次客户会议结束，都要问自己几件事：我有没有搞清楚客户为什么现在要解决？我有没有确认客户的下一步动作？我有没有记录客户原话，而不只是我的理解？
这些问题看起来简单，但真正持续做，很不容易。销售的挫败感会让人想逃避复盘。一个客户没回你，会想"可能他忙"；一个机会停住了，会想"可能时机不对"。这些解释有时是真的，但如果每次都这样解释，就学不到东西。
客户原话、关键顾虑、决策角色、下一步动作——这些是销售里的日志。没有日志，就没有 debug。
查理·芒格说过：手里只有铁锤的人，看什么都是钉子。
工程师的铁锤，是"找到正确答案"。
这把锤子在技术世界里管用。进了销售现场，它会一直在错误的位置发力。客户在判断要不要做决定，你却在证明方案是对的；客户在等一个行动理由，你却在把问题分析得更清楚；客户需要你帮他降低内部推动的风险，你却在讲系统边界。
工程师转销售，不是要换掉这把锤子，是要意识到自己一直拿着它。
今晚做一件事。
把你产品里最拿得出手的三个功能写下来，然后每个功能只写一句话：它帮客户从哪里变到哪里？
不是"它能做什么"，是"它让客户从 A 变成 B"。
写不出来的，就是你接下来要想清楚的。
