数极客首页

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

数极客,拥有16种数据分析模型的新一代用户行为分析平台!

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

——《浪潮之巅》吴军

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

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

数极客是新一代用户行为分析与数据智能平台,支持用户数据分析运营数据分析留存分析路径分析漏斗分析用户画像SEM数据分析等16种分析模型的数据分析产品,支持网站统计网站分析APP统计APP分析等分析工具,以及会员营销系统A/B测试工具等数据智能应用,支持SAAS和私有化部署,提升用户留存和转化率,实现数据驱动增长!

发表评论

评论已关闭。

相关文章