在一个商业环境里优化得非常适应环境的公司基因，很难在另一个生态环境里重新适应和发展。这就如同习惯了暖湿气候的恐龙，很难适应没有了植被覆盖的冰河时期一样。

——《浪潮之巅》吴军

上周我在和另一个to B产品团队的负责人聊，提到产品规划时，对方像模像样地展示了2020年的BSC，最后无奈地笑了下，你就看看，不用太较真，产品实际迭代时还是客户需求驱动为主。

是大实话没错了。

这话要搁在以前，我大概会产品正义之魂附身，觉得不对，想抬杠：怎么会是客户驱动产品需求呢？产品人有自己的思想，产品价值是我们来创造的，客户是重要，但他也只是在合适的时机和你的产品对上眼了。

沿着这个思路继续推进的话，产品的价值创造过程就是在自己封闭的体系内完成的，整个过程与市场是分离的，这能持续赢得客户的青睐吗？

我之前看过陈春花老师的管理整体论，里面提到一个观点：

经营者的信仰就是创造顾客价值。新的经营假设的核心是：价值是由顾客和企业共同创造的，顾客更关注自己的体验，更关注消费过程中的价值创造，而不再只是关注拥有产品。

——《哈佛商业评论》2018年5月

同样的，一个能够创造价值的产品，它的价值是由客户和产品共同创造的，二者是一体的。对规划产品的人来说，你需要一个与客户之间的连接点，以客户开始，为客户创造价值，由客户的偏好决定产品的技术和服务所付出的努力，由技术和服务的价值引导资源的投入。如此才能被确认是拥有市场能力并能实现持续成长的产品。

而我们也不得不承认，客户的成长性是根本特征，产品如果不能与客户一起成长，就失去了成长的可能性。

因此，在实际产品发展的过程中，客户在哪里，你的产品边界就在哪里。提供这个边界的能力可能不是你自己，可能是合作伙伴，可能是价值链上甚至价值链外的合作者，你要跨界，要跟别人合作，打开你的产品边界，拥有客户所需要的新能力。

这就不得不提到跨产品合作的问题了。

一、产品合作的方向

跨团队的产品合作，在to b的场景里，更多时候是不同产品方案的整合。而方案整合一般有两种：联合开发和联合方案。

有什么区别呢？

打个比方，你有番茄，他有鸡蛋，各自在菜市场上不同的摊位上售卖。有一天你发现，很多顾客买了番茄后就会跑到附近的摊位上买鸡蛋，于是你主动联系卖鸡蛋的哥们，你们一拍即合，你把部分番茄卖给他，他转售部分鸡蛋给你，你们双方达成了交易，都可以同时在各自的摊位上向顾客销售番茄和鸡蛋。

这是联合方案。双方无需任何改造，只需要互相销售产品，互相带来商机，促进各自产品的销售。

同样还是番茄和鸡蛋，你察觉到不少人在摊位上买了这两样后又拐到附近的餐馆，餐馆收了加工费，顾客尝到了一盘新鲜出炉的番茄炒蛋。这时候你和卖鸡蛋的哥们一商量，打算合作推出番茄炒鸡蛋这道热菜，推给对速食热菜有需要的群体。

这就是联合开发了。你们不仅各自都提供了原材料，还进行了材料的二次加工，最后提供给顾客的是经过研制融合的方案，而不是简单的1+1=2。

对于联合方案而言，产品合作的门槛不高，只要双方互利，谈妥收费分成模式即可；对于联合开发而言，涉及到整个方案的规划、开发和商业化，其中的坑就多了。

下面针对联合开发方案的合作场景，谈谈跨产品合作的注意事项。

二、前方注意避雷

1. 合作目标不清晰，反复地推倒重来

打出这行字的时候我忍不住在心里嘁了一声，老生重谈了不是？

但这点实在是太重要也太容易被忽视了。即便你很清醒，你们双方在思想层面非常地重视，但行动上也时常忘却合作的初衷，于是在方案规划上偏离航道也就不足为奇了。

你也发现了吧，任何一次产品合作，几乎都是一鼓作气、再而衰、三而竭的状态。一开始啥都好说，双方的接口人抱着“联姻”的心态互相谦让，推杯换盏好不和谐；然后正式推进合作的时候发现，不是甩锅就是顶雷；最后不得不收尾了，即便方案有点不及预期，还不是得硬着头皮向领导开展花式汇报。

因此，在刚开始合作的时候，一定要明确好合作的目标。

怎么明确目标呢？

联合开发的方案一般要求产品复制性强，代码共享。双方互为引入商机，通过方案销售的费用获得盈利。因此这些目标需要合作团队一起去定义，互惠共赢，才会有更大的动力推进整个合作的计划。

• 比如商业目标，你们打算今年联合方案在政府行业、泛企业、泛互联网行业等分别实现多少营收，为达成这些营收目标需要拿下多少单，卖出多少体量的产品；
• 比如竞争性目标，你期望这个方案在业内已有的市场格局里占据多大的份额，相比于友商往年的收入增幅多少；
• 再比如口碑目标，联合开发的方案推向市场后，你期望在业内树立一个什么样的口碑，在多大的覆盖面上打造什么样的影响力……

这是目标。

我看过有些人写的项目汇报邮件，在提到目标时往往说的都是行动计划，而非期望实现的目标。之前有伙伴写到发展服务生态时，是这么去定义目标的：

储备至少5家服务商，包括30位一线实施人员和10位运维人员，覆盖架构师、开发、交付和运维资源。

这是目标吗？

这是行动指标。

想想你要跟谁分享你的合作目标？合作方是一方面，但同时，团队内还有两个角色需要了解你的目标：老板和团队成员。

一方面你要向老板汇报这次合作，说服老板你为什么和产品a而不是产品b合作，以及为什么这次合作需要投入这些资源。老板关心什么？他关心的是你发展了多少一线服务商人员么？

不，他要看到的是你发展这么多服务商背后的最终收益，能给团队带来什么价值，创造多少营收。价值和利益，总要有一个在路上。

另一方面，你要周知到同在一条船上的团队成员，比起给出行动指标，从行动的意义层面加以指导更为重要。指标只是一个靶子，重要的是打中靶子后你能收获什么。

定好目标后，所有后续的动作都只能围绕这个目标去展开，任何与目标方向成反作用力的行为，都不能轻易被准允，都需要启动相应的变更审批机制。

2. 强协作，弱分工

有点奇怪哦，合作目标明确后，肯定要定好合作边界和责任分工。这没错，分工界面是很重要，这点每个管理过项目的都很清楚。

明确目标后，注意先把丑话说在前头，确定合作的边界。

我们太倾向于对合作方，尤其是公司外的合作方鼓吹产品能力了，但记住，你们是合作关系，除了秀肌肉之外，你还要撩开伤口，让对方清楚你能做什么、做不了什么。互揭老底，开诚布公地来定义整个方案能实现到什么程度，有哪些是可以保底的，哪些是可以争取的，哪些是需要引入外援的。

明确合作边界和责任方后，这就够了吗？

值得注意的是，除了分工以外，团队成员间的协作也非常重要，甚至比起分工更为重要。

坦白说，我们都太习惯组织内的协作了，跨组织间的合作一搬上台面，似乎就要顶着锅盖、抛出盾牌、紧盯战况，如有风吹草动随时准备防御、后撤。

在当下这个互联的技术系统下，所有组织本质上都是生存在一个无限链接的空间中。我们常常看到的是，组织内部之间是开放的、互通的；组织之外表现为以顾客为核心的相互链接的价值共同体。我们也承认，分工使得劳动效率最大化，但我们要解决是合作团队的整体效率，既有你方团队成员，又有我方成员，跨组织的合作更需要依靠协同，依靠信息交换和共享。

那么落实到实际行动上，怎样才算是协同合作呢？

1）互揭老底的同时，把合作需要的所有标准化的资料共享出去

这有个前提：你的团队已经储备了足够多的标准化的文档，从售前方案、到产品介绍、开发指南、部署运维等，每个维度都配备对应的材料，供合作方不同的角色翻阅。

比如我所在的团队负责的是中台框架，我们会根据产品迭代的节奏定期刷新配套的所有材料，面向不同的群体开放不同的权限。如果有各行业的产品找过来一起合作行业解决方案，我们会针对合作目标共享对应的文档支持，反之同理。

2）除了共享资料之外，你需要透明化合作资源

为达成方案的联合开发，双方各自需要投入多少人力，这些资源是一体化的，并不是割裂的。我之前负责的一个合作案例就栽过这个跟头，前端、webapi和底层api三层分别安置不同的开发资源，同时这些模块里又去区分哪些部分是合作方的开发实现，哪些是我方支持。

最后联调的时候发现两个突出的问题：

• 有些过渡模块没人管，无人问津；
• 联调时一帮人扑进去，七零八落。

你不得不承认，如果方案合作前你一开始定的基调就是强分工的话，一旦遇到边界模糊的地带，就容易滋生两不管的现象。而我们都知道，合作并非是一个线性、明确的过程，它总会在外界环境的刺激下演变为一个网状、不确定的状态。强协作，或许能帮助你更为柔性化地去考虑你与合作方之间的关系。

3. 开发完才考虑商业化，迟了！

之前我们团队有过一个case，整个方案的研发比较顺利，甚至在deadline 前超预期地完成封版。团队上下洋溢着一股过年的气息，这时候销售团队找上来了，说有个客户正缺这样的方案，想推进去看看能不能拿下这个单子。

有方案介绍吗？相比于竞争对手优势在哪？客户怎么体验？谁来交付？能给合作伙伴交付吗？服务实施的成本多高？产品怎么收费？有官方的口径宣传过该方案吗……

傻眼了。

做什么方案，怎么做方案，方案做出后怎么对外推广，以及发展生态在更大的范围内推广，这些都需要你在前期规划合作内容的时候考虑进去。这时候你恍然大悟，其实你只是定义好了一个方案并实现了而已，你远没有深思过产品商业化的事。

研制方案和产品商业化，完全可以并行去考虑。

1）打动客户的提案

在你初步规划好方案后，你大概就清楚整个方案面向的对象以及能给客户带来的价值。这时候不妨站在销售或售前的角度思忖，怎么给出一份能打动客户的提案？客户想看到什么样的方案？

关于梳理提案方面的技巧，请参考前文从《奇葩说》谈打动客户的“奇葩套路”

2）产品和服务定价

产品定价上，不妨根据你方案的定位和市场的供需，再结合双方团队的业绩目标，综合去把握产品收费的标准，同时注意明确好收入分配：联合开发的方案是分成售卖、营收复算还是一次性底价售卖？

而服务报价，大可以在合作团队开展研发工作的时候，试着记录下整个项目团队投入的人力和时间资源，这些都将成为你评估服务成本的参考。后续若是计划将该方案标准化地交给合作伙伴去实施，也可以结合实际方案实施的成本，加上公司整体的利润率要求综合去考虑。

关于服务定价的细节，请参考前文To B |你的服务定价出问题了吗？

3）市场宣传

虽说酒香不怕巷子深，但是这壶好酒也得趁早把牌子亮出来。也许你会说，方案都还没研发出来，这时候在市场上曝光是不是为时过早？不，等你方案出来了才开始包装方案、铺开市场就有点迟了。

《闪电式扩张》一书里提到：

面对市场的不确定，优先考虑的是速度，而不是效率。

——《闪电式扩张》德·霍夫曼

没有不透风的墙，如果不确定自己是否踩中了风口，不妨就化成一股穿堂风，随时准备拉起速度，强势灌入。

三、小结

吴军在《浪潮之巅》里提过：

在一个商业环境里优化得非常适应环境的公司基因，很难在另一个生态环境里重新适应和发展。这就如同习惯了暖湿气候的恐龙，很难适应没有了植被覆盖的冰河时期一样。

——《浪潮之巅》吴军

一个公司如此，不同的团队之间也是如此。我们对于团队的协作模式太熟悉了，而跨团队的产品合作总会遇到各种各样的坎儿，它是网状的、不确定的，需要更多柔性化的分工和协作。即便你反复确认、再三验证、多次复盘，也仍然不能放松警惕。

我们能做到的是，心中始终要有一张底牌，虽不能风雨无阻，但至少也力求乘风破浪。

参考文献：

《闪电式扩张》，德·霍夫曼

《浪潮之巅》，吴军

《哈佛商业评论》2018年5月，陈春花

#专栏作家#

林壮壮，微信公众号：健壮的大姐姐（ID: is_strong），人人都是产品经理专栏作家。腾讯高级产品经理，专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议