产品经理的团队合作与跨部门合作

孙志威(Nili)

腾讯产品经理,2年移动互联网产品经验。毕业后做过2年后台开发,后来转做产品。以产品的身份,参与过5个不同的项目,到目前为止还没有一个拿得出手的产品,失败的产品案例倒是有不少。由于经常“坑卖队友,只好自称为死产品”,以降低各个开发、测试、运营、设计大佬们的仇恨值。

我是Nili,一个正在路上的失败与错误中不断反思总结前进的产品人。

【精彩观点】

“共生关系中的各个行为不必对称或对等。事实上,生物学家发现自然界几乎所有的共栖同盟在相互依存的过程中都必然有一方受惠更多——这实际上暗示了某种寄生状态。尽管一方所得就意味着另一方所失,但是从总体上来说双方都是受益者,因此契约继续生效。”

在分工日益明确的团体合作时代,一个团队、一个部门就好比一个互利共生的生物群体、一个和谐的生态系统。每个不同的角色发挥各自的优势、相互配合,朝着共同的业务目标奋力前进。

而在这个互利共生的生态系统中,产品经理充当着连接各个角色的桥梁。产品经理的日常工作中离不开合作。小至日常工作中与各个角色的相互配合,大至跨部门、跨产品间的相互拉动与促进,在这个过程中,产品经理一直和不同的人与部门合作。正如《失控》中提到的那样,合作是一种相互双生双赢的一种关系,即使双方获取到的利益不对等,但是从结果上来看,1+1的结果总是会大于2。 然而在合作的过程中,往往由于双方信息不对等或者不了解对方的需求,而导致合作受阻甚至破裂。那么应该如何做,才能尽可能地避免这种合作失败的情况呢?首先要让对方知道你要干什么;其次,了解对方的需求;再次,做好预估;最后,定期检查并同步结果给大家。

【实践案例】

1.团队内合作

在一个比较成熟的团队中,除了产品经理以外,往往还有开发、测试、设计、运营、市场等不同的角色存在。不同的角色组成一个团队,为了共同的产品发展而努力。在这个团队中,产品经理无疑是整个团队中与各个角色打交道最多的人物,充当连接各个角色的桥梁以及信息分析处理中心。因此在与各个团队角色合作的过程中,产品经理最重要的是让大家知道你要干什么,这样做的目的是什么。

下面先来看看以下两个在日常工作中常见的场景。

场景一:

产品经理:“这个功能非常重要,我们需要马上上线这个功能!”

开发1:“这个功能实现成本大,建议不做!”

开发2:“开发周期只剩下几天,匆忙变更这个需求将有延期风险,建议放到下个版本再做。”

很多时候,这些情况的潜台词便是:“我为什么要做这个需求?”

似乎是合作破裂了?那么如何打破这个僵局呢?

首先在增加/变更一个需求时,必须非常清楚为什么要这么做。或是数据上得出的结论,或是根据用户反馈,或是用户的行为分析。总之,需求是否有意义,这个问题产品经理必须想得非常清楚。只有产品经理自己想清楚了,才可能传达给开发更清晰的前因后果,告知他们这样做的重要性,而不是让开发被动接受一个个需求。让团队成员清晰地认识到某个需求解决了用户的痛点,或者是提升功能的使用率对整个团队的重要性。只有当双方目标达成一致,达成需求该做,且优先级非常高的共识时,即使实现上有困难,万能的开发兄弟也会积极地与产品一起讨论解决方案,最终达到双方满意的效果。

场景二:

产品经理:“我需要在这个页面上有突破性的体验!”

设计师:“不懂。”

在和设计师打交道时,我们往往会将我们想要的结果告诉设计师,让他们去脑补我们的需求。但是很多时候,设计师在不清楚产品详细逻辑与具体场景的基础上,设计出来的页面与我们想要的结果大相径庭。经过大量的返工与沟通之后才知道,噢,原来只是将背景颜色变浅,然后突出某个button的颜色,吸引用户使用这个功能而已。

在与设计师合作时,一方面要尊重设计师的专业技能,让他们自由地去发挥他们的设计长处。另一方面,则需要告知完整的产品逻辑以及相关的使用背景,例如明确告知突出某个区域的背景颜色,调整某些wording的大小及位置,以便更吸引用户等。至于如何去搭配,就交给专业的设计师考虑吧。

两个简单的场景告诉我们,在与团队成员合作过程中需先求同,产品经理需要与团队伙伴一起明确大目标和小目标。在此基础上再求异,通过在细节点上的坚持或者妥协退让以期更好地实现最终的目的。

2.跨部门合作

在手机软件日益丰富的移动互联网时代,经常可以看到同一公司旗下的不同App相互跳转的场景。例如,微信游戏引导下载应用宝,以便对游戏的统一下载;QQ空间分享动态时触发实时拍照的场景,将引导开启水印相机的功能……在适合的场景下,跨产品的合作将带来额外的新增、活跃、回流用户,为产品的发展争取了更多的发展空间。因此跨部门的产品合作带来的效益绝对是互惠双赢的。

但是,在跨部门产品合作对接时,相信许多产品经理都会有种错觉——我明明为兄弟产品付出了那么多,为什么对方的产品还是不爱我?不给我带等同量的用户也就算了,但缺的量为“神马”这么离谱啊!!

还是来看看以下两个具体的合作场景。

场景一:

部门A产品经理:“这个月我给你们产品带来了200万的新增用户!”

部门B产品经理:“额……非常感谢,但是这个月的留存率连30%都不到,请问你有什么方案可以提升从你那个场景带来的新增用户的留存率吗?”

部门A产品经理:“哈?贵部门不是一直希望能提高这个场景的新增用户吗?”

部门B产品经理:“是的,但是我们部门更加关注留存率!”

发生这种场景的根本原因在于——不懂兄弟产品需要的是什么?同样是拉用户,但是却依然可以分为拉动新增用户、拉动活跃用户、拉动回流用户。同样是带动流量与使用渗透率,但依然可以分为点击跳转流量、付费流量等。由于不同的最终目的,将导致引导跳转的场景各不相同,进而导致整个产品的使用场景以及跳转逻辑各不相同。因此需要在双发开始合作之初就先了解清楚各自部门的KPI!

例如自己部门的主要KPI是活跃用户达到千万级,而兄弟部门的主要KPI是每月新增用户达到百万级。如果一开始就没有了解清楚各自的主KPI是什么,以自己部门的KPI去“脑补”对方的KPI与自己一致,那么就会出现一开始所说的情况——明明为兄弟产品付出那么多的成本,可效果却不是太好!只有确定好双方的目标与共同努力合作的方向之后,方能清晰地知道能为对方做什么,对方能为我做什么,进而找到双赢的合作场景。

场景二:

部门A产品经理:“我希望能在贵方产品的主功能页面加入跳转到我方产品的功能。”

部门B产品经理:“非常抱歉,我方的主功能如果插入了这个场景的跳转,将对用户体验影响较大,即使做了相应的引导与提示,也无法化解这个冲突。顺便问下,贵方有估算过这个功能能给贵产品带来多少量吗?”

部门A产品经理:“额……这个量的问题我们还真没有预估过……”

每个产品都有它的主要功能与路径,在两个产品合作时,尽量在不损害双方主功能路径体验的基础上寻找不涉及主功能的边界场景进行相互合作。找到合作的边界场景后,努力弱化两个产品之间的差异性,尽可能地优化两个不同的产品在跳转过程中的一致体验——恰当地引导wording,让用户有跳转的心理预期,边界场景相似的UI/UE体验——前后标题,页面的风格布局一致,让用户体验不到已跳出App的压力。

接下来便是预估合作场景能给对方带来多少的量。例如,以微信游戏弹出引导应用宝下载的合作场景为例。从页面的游戏列表的曝光展示→用户点击下载按钮→弹出应用宝引导下载的对话框→用户点击下载按钮→下载应用→安装完毕→打开应用的合作流程中,计算出大致的转换漏斗,预估好各个步骤的进入率、与当前上一个步骤对比后的用户流失率。

明确好各自的目标与边界合作场景以及能给对方带来的好处之后,接下来的合作无疑会轻松愉快很多。因为一个产品总有它的瓶颈所在,当一个盘子做得足够大时,如果需要有更大的发展,无疑要借助其他产品所覆盖的用户以便进一步增加自己的覆盖用户。

最后则是对数据进行监控,定期以邮件的方式向合作双发输出产品结果。定期show出自己的肌肉是非常有必要的,因为产品结果导向型部门间的合作关注的是自己为对方做了什么,对方又为自己做了什么。我需要对方的什么资源,接下来怎样通过资源互换的形式来获取己方产品的进一步发展。在基于双方利益双赢的基础上,何乐而不为。

【总结分析】

“小孩分对错,大人分利弊。”合作的根本目的是增强各自的能力,以达到双赢的目的。

在移动互联网盛行的今天,早已不是一个技术牛人就可以搞定一切,拼个人能力的英雄时代。而是团队成员相互配合,资源相互交换整合拼整体实力的合作时代。

在团队合作的过程中,需要明确好目标,告知每个需求的相关背景以及出发点,同时做好每个功能点的价值预估。一切的一切都是为了与大家达成共识——这样做对大家、对整个团队都是重要且有意义的!

在跨部门合作中,需要了解对方的关键KPI是什么,找准双方合作的场景,做好各个环节的数据预估,同时定期检查对齐各自的成果。所有的合作都是基于彼此部门的KPI能被满足——合作双方在合作的过程中都是相互促进共赢的结果!

合作共生共赢是这个时代的主题。正如凯文·凯利在《失控》中描述的那样“在进化的过程中,生物的社会性与日俱增,共同进化的实例也愈来愈多。生物的社会行为越丰富,就越有可能形成互惠互利的关系。同样,我们构建的经济和物质世界越是相影响,共同努力,就越能见证到更多共同进化的实例。”