跨产品合作的决胜要素：柔性化地分工与协作

健壮的大姐姐 2023-07-22 22:15:32

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

是大实话没错了。

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

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

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

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

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

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

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

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

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

一、产品合作的方向

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

有什么区别呢？

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

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

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

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

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

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

二、前方注意避雷

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

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

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

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

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

怎么明确目标呢？

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

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

这是目标。

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

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

这是目标吗？

这是行动指标。

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

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

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

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

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

2. 强协作，弱分工

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

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

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

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

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

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

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

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

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

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

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

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

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

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