To B项目中，你需要一支游骑兵

 

前几天我收到一位读者的留言，他提出一个问题：

 

在To B客户的售前谈判中，是不是只要销售就够了？

这个问号刚落下，他又自我否定，那客户想了解产品和技术细节怎么办？

不成，还是得派产品研发同学护航。

那产品研发忙着出差，谁来负责产品需求迭代呢？……

 

多次的假设和推翻假设，最终他迷茫了，试探性地问了句：

 

难不成在售前阶段要配备专门对接客户的人员，这个人懂客户、懂销售、懂产品、懂技术？

 

Bingo！

 

诚然，一个项目的胜败，会受到诸多因素的影响，但究其本质，项目背后的组织才是关键点。

 

不妨试着复盘下，在你过去曾经做过的或成功或失败的项目里，人员的组成结构如何？能力模型是否匹配要求？这些项目成员是否有统一的目标？做事的套路是否自成一体，还是彼此冲突？但凡有一个条件不满足，是否都会成为项目延期或停滞的潜在风险？

 

我们来缩小讨论范围，在售前阶段，甚至是商机线索刚开始引入的时候，你的人员结构该如何布局？

 

不妨试着回想下，你的团队里：

 

• 产品同学是不是成日忙着应对客户需求，不是在飞机上就是在去往机场的路上？
• 技术同学时不时被拉到咨询群里当着一流的客服人员，微信群里的消息呈指数级增长？
• 项目经理面对一揽子需求埋头琢磨如何转换成产品能力，烦恼越来越多、头顶越来越凉？

 

问他们，累吗？超累的。

 

为什么？

 

除了传统的销售之外，你要补给什么人力，自然要根据具体项目的需要。但是有些通用的弹药是要提前准备的，比如我们今天要谈到的售前架构师。

 

一、架构师=游骑兵

 

很庆幸，我在团队里遇到一支很优秀的架构师队伍，总教头曾经公开谈过他对架构师的定位——游骑兵。

 

何出此言？

 

先来看下，游骑兵究竟背负着什么使命？

 

• 侦察，盘活地形的利害，探察敌军的要害；
• 独立战斗、防守、生存下去；
• 呼叫支援，为大部队指明方向；
• 参与关键的地面战斗。

 

而对应到架构师呢？

 

• 项目商机评估分析，摸底竞品深浅；
• 编写、评审、交流方案，协助客户完成沟通汇报；
• 对接项目管理办公室，保障项目交付进程；
• 项目交付和运维保障支持。

 

看出二者相同点了没？

 

我在公司这几年，作为项目管理办公室的一员，算是团队中最直接和架构师接洽的角色，也确实被这只游骑兵队伍的专业素质所折服。

 

• 深入的业务理解，是这个行业领域的专家；
• 扎实的技术功底，能跟客户的IT技术团队无缝交流；
• 深谙销售套路，媲美商务的谈判和说服能力；
• 项目管理小能手，具备完整的立项、方案编制、项目控标能力；
• 连接产品和项目需求，具备关键项目交付控盘能力。

 

这是什么四通八达的神仙人设？

 

我也曾一度质疑过，但事实证明，这支队伍众望所归，他是产品对外圈地盘的主力军，是项目对接支持的核心区。

 

为什么？

 

先来看架构师的日常。

 

一天伊始，他要去拜访客户。昨天销售拉了一个单过来，客户期望听到一个详尽的方案。

 

于是架构师连夜规划产品方案，给客户进行汇报后，了解到客户目前的整体预算和痛点，再根据客户要求调整方案，尽快推动项目立项审批。

 

而这时候销售敲起了警钟：隔壁老王家也出手了，客户蠢蠢欲动。

 

于是架构师一边要跟对手PK产品技术，持续改善客户方案，牢牢抓住客户的心；一边要从技术层面为项目找到立足点，与项目里的其他产品形成联合方案，共同把项目金额做大。

 

与此同时，另一个已经谈妥的项目准备启动交付，架构师要跟前方项目经理沟通项目整体规划，协助把控产品交付节奏，并着手配合项目经理引导合作伙伴入场交付。

 

这期间架构师需要持续保持与产品团队的沟通，确保准确传递市场和客户的反馈，明确产品研发的优先级。

 

而同样的，还有一些已经上线的项目，正准备拉开二期项目的立项，架构师要配合销售保障二次销售机会，进一步打开产品的销售和市场份额。

 

二、架构师的求存之道

 

基于架构师的职责要求，我们来一一解读下，对架构师来说，最难的是什么？

 

1. 项目机会的评估

 

分析商机，实质上是在分析客户内部的决策链。在这条决策链上，究竟存在哪些关键人员？

 

不妨先对客户进行分层。

 

怎样才算是一类用户？

 

有共同需求的群体才是同一个层级的用户。

 

举个生活场景，奶爸独自推车去超市买奶粉，究竟要挑哪个品牌的奶粉？

 

首先，推荐奶粉的是商超的导购员，影响购买的奶粉品牌的可能是妈妈，或是其他有经验的朋友，真正掏钱购买的人是爸爸，而最终买回去满不满意喝不喝的人是宝宝。

 

从上述例子不难看出，客户层级至少有5重：

 

1. 关注功能体验的“使用者”
2. 社交因素影响较大的“影响者”
3. 关注情感因素的“推荐者”
4. 关注预算的“购买者”
5. 关注风险的“决策者”

 

当选择太多时，顾客会被决策过程所困扰，因为要区别出众多选择的不同实在麻烦。而人们又不想放下手头的事情来思考该选哪个，因此导致对产品失去兴趣。——罗伯特·西奥迪尼《说服力》

 

罗伯特·西奥迪尼在《说服力》一书里提到过客户在决策过程中的思考，为减少客户选择的顾虑，我们需要对症下药，见人说人话。

 

• 针对决策者，很多时候不是卖产品，而是要向他传递价值，重点是产品的未来，而不是产品的本身；
• 面对推荐者和影响者，更多时候你要谈的是技术大方向和产品特性；
• 面对购买者，你要了解他对预算的心理预期，再给出合时宜的报价；
• 而面对使用者，你可能要深入到具体产品和实施细节，了解他的痛点和偏好。

 

此外，换个行业可能又不一样。

 

面对金融行业客户，你需要储备并分享更多技术、安全、风险相关的知识；面对政府客户，更多时候会更侧重于业务上云、统一办事平台、数据共享等方案。

 

针对不同行业的客户进行分层，了解他们的需求，逐一攻破，方能做到四两拨千斤，争取在客户面前赢得更多的票数。

 

了解客户内部关键人员的影响力分布之后，我们再来看下如何判断该项目靠不靠谱。

 

下面以政企客户为例。

 

1）判断客户

 

• 了解领导：客户领导级别（科、处、CIO级别）的人员，是否具有实质性的决策权；
• 回顾过去：政府和大企业客户通常都是在前一年规划预算，了解下客户去年是否做过预算，有助于我们判断是否要在今年投入资源；
• 环顾周边：客户的对手是谁，去年做过什么成绩；客户是否有政绩压力，是否急于出成绩。

 

2）判断销售

 

以我们公司为例，销售和售前架构师划分在不同的团队，架构师在评估项目机会时，需要掂量下销售对这个项目的决心。

 

• 商机来源：是销售直接引入的机会，还是通过代理商牵线来的；
• 销售观察：在商机引入时是否有其他竞争对手，对手在客户侧的评价反馈如何；
• 销售领导：公司内部负责这单项目的销售领导级别，领导对这单客户的重视程度；比对下竞争对手负责销售的领导级别。

 

在售前初期阶段，架构师通过对客户和销售的判断，不仅能辅助产品团队评估商机的靠谱程度，权衡投入该项目的资源占比，还能及时发掘项目风险，提前做好规避防范。

 

2. 客户沟通与汇报

 

在前期和客户沟通的过程中，伴随着一系列的汇报工作。不要小看这些汇报工作，在你帮助了客户决策人在他的领导面前体现更多的成绩，你和客户之间开始有了更加紧密的关系。

 

以政府客户为例，每一次国家新政策的颁发、重大会议的开展、评比的举行、领导的视察等，都需要项目团队协助支持编制方案，帮助领导完成政绩汇报。

 

下面以某政府客户的某次领导视察为例，架构师在这整个过程中需要做些什么？

 

1）汇报前

 

1. 架构师需要提前摸清楚客户决策链里的客户参会情况，包括参会领导级别、关注点、痛点——参会情况可以更好地协助架构师评估本次汇报的投入度；
2. 在产品给出的标准化材料之余，通过销售提前了解客户的关注点，针对客户的关注点着重展开专项说明——从编写的方案中体现对客户的重视；
3. 摸清楚竞争对手前期跟客户交流的情况，客户对竞争对手的态度如何——尽量搞清楚客户的意向，同时要明确跟竞争对手有一些不一样的点，确定“打击策略”；
4. 通过给出清晰完整的案例、实际数据、图表来做展示，直接切入主题——给客户更为直观的体验。

 

2）汇报过程中

 

1. 当面再口头确认一次客户这次交流所关注的重点，再有针对性的介绍；
2. 在不清楚客户倾向性意见的情况下，不对竞争对手做主观性的评价，尽量用一些事实案例、具体数据来体现优势，引导客户自己做出判断；
3. 察言观色，根据客户对内容的反馈临场进行调整。

 

3）汇报后

 

1. 完成清晰的会议纪要，并跟客户关键人员确认；
2. 针对本次交流的未完全明确的问题，通过补充材料的方式，再提交给客户；
3. 通过销售或内部人员了解客户决策人对于本次汇报的评价，评估是否对采购意向有推动效果。

 

简言之，通过每一次协助客户的沟通和汇报中，建立与客户的关系。而良好的关系建立在彼此互利的基础上，主要体现在：

 

1. 你能很好地解决客户的核心诉求。帮助客户完成关键的本职工作，在领导面前引起关注，把成绩单贴在客户名下，支撑他的晋升通道；
2. 你是专业的。从规划方案、招投标、交付落地、验收，让客户省心、放心、安心；
3. 你和别人不一样。在这过程中树立自己与众不同的专家形象，争取进入到关键客户的核心智囊团。

 

3. 产品和项目的衔接

 

前面两点我们主要在谈架构师与客户之间的“情感纠葛”，接下来不得不提到架构师与产品内部团队之间的磨合。

 

从项目需求到产品规划，在To B产品中需要有一个转换器，将项目上的业务需要“翻译”成产品行话，同时又能将产品的能力结合项目的需要形成解决方案。

 

架构师就是这样的一个角色，作为既懂业务，又懂产品的人员，他需要将项目和产品双向联动起来。

 

具体体现为：

 

• 挖掘客户需求背后所关联的产品能力，判断该需求的合理性，为产品需求规划提供原始数据支持；
• 通过分析行业市场、比对竞争对手，为产品研发团队提供更开阔的视界；
• 评估客户所提的定制化功能，是否是这个行业内的通用诉求。项目中的定制功能转化成产品标准功能的比例越高，说明产品路线是越健康的。

 

三、小结

 

在To B竞争格局愈演愈烈的情形下，产品同学忙着为客户提供贴身服务、逐渐偏离产品初心，技术同学混迹在各大客户群里既当客服又当测试，项目经理捧着满怀需求两眼泪千行……

 

这种人员结构是否是错位的？是否要开始调整下？

 

此时正是跑马圈地的时候，你需要配备这样的一支游骑兵队伍。

 

他在开拓地盘摸索战况的同时，深谙待客之道；他在上阵战斗攻防求存的同时，懂得适时引入内外援，构筑有力的防线。

 

因为有架构师，我们可以打理好客厅，也同样顾得上后院，产品和项目之间的Gap被填上了。

 

——所有项目和产品的相关人员终于可以串联起来，共同朝着同一个目标前进。