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

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

——《浪潮之巅》吴jun

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

是大实话没错了。

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

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

我之前看过陈春huāX的管理整体论,里面提到一个观点:

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

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

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

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

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

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

一、产品合作的方向

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

有什么区别呢?

打个比方,你有番茄,他有基弹,各自在菜市场上不同的摊位上shòumài。有一天你发现,很多顾客mǎi了番茄后就会跑到附近的摊位上mǎi基弹,于是你主动Xmài基弹的哥们,你们一拍即合,你把部分番茄mài给他,他转shòu部分基弹给你,你们双方达成了交易,都可以同时在各自的摊位上向顾客X番茄和基弹。

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

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

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

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

下面zhēn对联合开发方案的合作场景,谈谈跨产品合作的注意事项。

二、前方注意避雷

1. 合作目标不清晰,反复地X重来

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

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

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

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

怎么明确目标呢?

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

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

这是目标。

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

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

这是目标吗?

这是行动指标。

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

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

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

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

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

2. 强协作,弱分工

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

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

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

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

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

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

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

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

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

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

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

2)除了共享资料之外,你需要X化合作资源

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

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

  • 有些过渡模块没人管,无人问津;
  • 联调时一帮人扑进去,七X落。

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

3. 开发完才考虑商业化,迟了!

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

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

洒眼了。

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

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

1)打动客户的提案

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

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

2)产品和X定价

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

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

关于X定价的细节,请参X文To B |你的X定价出问题了吗?

3)市场X

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

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

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

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

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

三、小结

吴jun在《浪潮之巅》里提过:

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

——《浪潮之巅》吴jun

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

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

参考文献:

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

《浪潮之巅》,吴jun

《哈佛商业评论》2018年5月,陈春huā

#专栏作家#

林壮壮,微信X号:健壮的大姐姐(ID: is_strong),人人都是产品经理专栏作家。X高级产品经理,专注于To BX项目管理和行业分析,欢迎各路好汉一起探讨。

本文原创发布于人人都是产品经理。未经许可,jìn止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

1人打赏
收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 跨产品合作的决胜要素:柔性化地分工与协作 https://www.xiongfawang.com/2675.html

常见问题

相关文章

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

分享本文封面