To B项目中，你需要一支游骑兵
前几天我收到一位读者的留言，他提出一个问题：
在To B客户的售前谈判中，是不是只要销售就够了？
这个问号刚落下，他又自我否定，那客户想了解产品和技术细节怎么办？
不成，还是得派产品研发同学护航。
那产品研发忙着出差，谁来负责产品需求迭代呢？……
多次的假设和推翻假设，最终他迷茫了，试探性地问了句：
难不成在售前阶段要配备专门对接客户的人员，这个人懂客户、懂销售、懂产品、懂技术？
Bingo！
诚然，一个项目的胜败，会受到诸多因素的影响，但究其本质，项目背后的组织才是关键点。
不妨试着复盘下，在你过去曾经做过的或成功或失败的项目里，人员的组成结构如何？能力模型是否匹配要求？这些项目成员是否有统一的目标？做事的套路是否自成一体，还是彼此冲突？但凡有一个条件不满足，是否都会成为项目延期或停滞的潜在风险？
我们来缩小讨论范围，在售前阶段，甚至是商机线索刚开始引入的时候，你的人员结构该如何布局？
不妨试着回想下，你的团队里：
- 产品同学是不是成日忙着应对客户需求，不是在飞机上就是在去往机场的路上？
- 技术同学时不时被拉到咨询群里当着一流的客服人员，微信群里的消息呈指数级增长？
- 项目经理面对一揽子需求埋头琢磨如何转换成产品能力，烦恼越来越多、头顶越来越凉？
问他们，累吗？超累的。
为什么？
除了传统的销售之外，你要补给什么人力，自然要根据具体项目的需要。但是有些通用的弹药是要提前准备的，比如我们今天要谈到的售前架构师。
一、架构师=游骑兵
很庆幸，我在团队里遇到一支很优秀的架构师队伍，总教头曾经公开谈过他对架构师的定位——游骑兵。
何出此言？
先来看下，游骑兵究竟背负着什么使命？
- 侦察，盘活地形的利害，探察敌军的要害；
- 独立战斗、防守、生存下去；
- 呼叫支援，为大部队指明方向；
- 参与关键的地面战斗。
而对应到架构师呢？
- 项目商机评估分析，摸底竞品深浅；
- 编写、评审、交流方案，协助客户完成沟通汇报；
- 对接项目管理办公室，保障项目交付进程；
- 项目交付和运维保障支持。
看出二者相同点了没？
我在公司这几年，作为项目管理办公室的一员，算是团队中最直接和架构师接洽的角色，也确实被这只游骑兵队伍的专业素质所折服。
- 深入的业务理解，是这个行业领域的专家；
- 扎实的技术功底，能跟客户的IT技术团队无缝交流；
- 深谙销售套路，媲美商务的谈判和说服能力；
- 项目管理小能手，具备完整的立项、方案编制、项目控标能力；
- 连接产品和项目需求，具备关键项目交付控盘能力。
这是什么四通八达的神仙人设？
我也曾一度质疑过，但事实证明，这支队伍众望所归，他是产品对外圈地盘的主力军，是项目对接支持的核心区。
为什么？
先来看架构师的日常。
一天伊始，他要去拜访客户。昨天销售拉了一个单过来，客户期望听到一个详尽的方案。
于是架构师连夜规划产品方案，给客户进行汇报后，了解到客户目前的整体预算和痛点，再根据客户要求调整方案，尽快推动项目立项审批。
而这时候销售敲起了警钟：隔壁老王家也出手了，客户蠢蠢欲动。
于是架构师一边要跟对手PK产品技术，持续改善客户方案，牢牢抓住客户的心；一边要从技术层面为项目找到立足点，与项目里的其他产品形成联合方案，共同把项目金额做大。
与此同时，另一个已经谈妥的项目准备启动交付，架构师要跟前方项目经理沟通项目整体规划，协助把控产品交付节奏，并着手配合项目经理引导合作伙伴入场交付。
这期间架构师需要持续保持与产品团队的沟通，确保准确传递市场和客户的反馈，明确产品研发的优先级。
而同样的，还有一些已经上线的项目，正准备拉开二期项目的立项，架构师要配合销售保障二次销售机会，进一步打开产品的销售和市场份额。
二、架构师的求存之道
基于架构师的职责要求，我们来一一解读下，对架构师来说，最难的是什么？
1. 项目机会的评估
分析商机，实质上是在分析客户内部的决策链。在这条决策链上，究竟存在哪些关键人员？
不妨先对客户进行分层。
怎样才算是一类用户？
有共同需求的群体才是同一个层级的用户。
举个生活场景，奶爸独自推车去超市买奶粉，究竟要挑哪个品牌的奶粉？
首先，推荐奶粉的是商超的导购员，影响购买的奶粉品牌的可能是妈妈，或是其他有经验的朋友，真正掏钱购买的人是爸爸，而最终买回去满不满意喝不喝的人是宝宝。
从上述例子不难看出，客户层级至少有5重：
当选择太多时，顾客会被决策过程所困扰，因为要区别出众多选择的不同实在麻烦。而人们又不想放下手头的事情来思考该选哪个，因此导致对产品失去兴趣。——罗伯特·西奥迪尼《说服力》
罗伯特·西奥迪尼在《说服力》一书里提到过客户在决策过程中的思考，为减少客户选择的顾虑，我们需要对症下药，见人说人话。
- 针对决策者，很多时候不是卖产品，而是要向他传递价值，重点是产品的未来，而不是产品的本身；
- 面对推荐者和影响者，更多时候你要谈的是技术大方向和产品特性；
- 面对购买者，你要了解他对预算的心理预期，再给出合时宜的报价；
- 而面对使用者，你可能要深入到具体产品和实施细节，了解他的痛点和偏好。
此外，换个行业可能又不一样。
面对金融行业客户，你需要储备并分享更多技术、安全、风险相关的知识；面对政府客户，更多时候会更侧重于业务上云、统一办事平台、数据共享等方案。
针对不同行业的客户进行分层，了解他们的需求，逐一攻破，方能做到四两拨千斤，争取在客户面前赢得更多的票数。
了解客户内部关键人员的影响力分布之后，我们再来看下如何判断该项目靠不靠谱。
下面以政企客户为例。
1）判断客户
- 了解领导：客户领导级别（科、处、CIO级别）的人员，是否具有实质性的决策权；
- 回顾过去：政府和大企业客户通常都是在前一年规划预算，了解下客户去年是否做过预算，有助于我们判断是否要在今年投入资源；
- 环顾周边：客户的对手是谁，去年做过什么成绩；客户是否有政绩压力，是否急于出成绩。
2）判断销售
以我们公司为例，销售和售前架构师划分在不同的团队，架构师在评估项目机会时，需要掂量下销售对这个项目的决心。
- 商机来源：是销售直接引入的机会，还是通过代理商牵线来的；
- 销售观察：在商机引入时是否有其他竞争对手，对手在客户侧的评价反馈如何；
- 销售领导：公司内部负责这单项目的销售领导级别，领导对这单客户的重视程度；比对下竞争对手负责销售的领导级别。
在售前初期阶段，架构师通过对客户和销售的判断，不仅能辅助产品团队评估商机的靠谱程度，权衡投入该项目的资源占比，还能及时发掘项目风险，提前做好规避防范。
2. 客户沟通与汇报
在前期和客户沟通的过程中，伴随着一系列的汇报工作。不要小看这些汇报工作，在你帮助了客户决策人在他的领导面前体现更多的成绩，你和客户之间开始有了更加紧密的关系。
以政府客户为例，每一次国家新政策的颁发、重大会议的开展、评比的举行、领导的视察等，都需要项目团队协助支持编制方案，帮助领导完成政绩汇报。
下面以某政府客户的某次领导视察为例，架构师在这整个过程中需要做些什么？
1）汇报前
2）汇报过程中
3）汇报后
简言之，通过每一次协助客户的沟通和汇报中，建立与客户的关系。而良好的关系建立在彼此互利的基础上，主要体现在：
3. 产品和项目的衔接
前面两点我们主要在谈架构师与客户之间的“情感纠葛”，接下来不得不提到架构师与产品内部团队之间的磨合。
从项目需求到产品规划，在To B产品中需要有一个转换器，将项目上的业务需要“翻译”成产品行话，同时又能将产品的能力结合项目的需要形成解决方案。
架构师就是这样的一个角色，作为既懂业务，又懂产品的人员，他需要将项目和产品双向联动起来。
具体体现为：
- 挖掘客户需求背后所关联的产品能力，判断该需求的合理性，为产品需求规划提供原始数据支持；
- 通过分析行业市场、比对竞争对手，为产品研发团队提供更开阔的视界；
- 评估客户所提的定制化功能，是否是这个行业内的通用诉求。项目中的定制功能转化成产品标准功能的比例越高，说明产品路线是越健康的。
三、小结
在To B竞争格局愈演愈烈的情形下，产品同学忙着为客户提供贴身服务、逐渐偏离产品初心，技术同学混迹在各大客户群里既当客服又当测试，项目经理捧着满怀需求两眼泪千行……
这种人员结构是否是错位的？是否要开始调整下？
此时正是跑马圈地的时候，你需要配备这样的一支游骑兵队伍。
他在开拓地盘摸索战况的同时，深谙待客之道；他在上阵战斗攻防求存的同时，懂得适时引入内外援，构筑有力的防线。
因为有架构师，我们可以打理好客厅，也同样顾得上后院，产品和项目之间的Gap被填上了。
——所有项目和产品的相关人员终于可以串联起来，共同朝着同一个目标前进。
相关文章：