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

1 评论 8941 浏览 11 收藏 18 分钟

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

——《浪潮之巅》吴军

上周我在和另一个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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作者一看就是老to b了 ➡ 人与人、团队与团队间的合作的确很重要。合作要互利,感觉严肃活泼是最好的氛围

    来自广东 回复