产品经理60%时间用于协作,我们找到了破局方法
编辑导语:产品经理在日常工作中很多时候都需要跟各方面进行沟通,所以沟通协作对于产品经理来说是非常重要的一个能力,在很多时候可以带来更高的效率;本文作者分享了关于产品经理协作的破局方法,我们一起来了解一下。
据不完全统计,产品经理在工作中60%以上的时间用于沟通协调。
当团队中理应提供洞察,为产品指明道路的经理们深陷沟通泥潭,长线价值的思考资源完全被无止境的会议和碎片化的沟通占据,导致产品经理的个人成长空间与产品价值一起内卷,陷入恶性循环。
一、PM的场景&问题
产品经理每天面临大量的沟通协调,那么,我们在沟通、协调些什么呢?
- 场景1:接到一个需求,需要理清方案为什么采用现在的设计、历史版本什么样、谁是设计者?
- 场景2:跟进一个跨多条业务线的项目,希望知道各线业务的运作方式
- 场景3:工作相关、未直接参与的项目,但需要了解项目细节、及内部的依赖关系
- 场景4:上评审会的那天,往往是团队成员看到问题/方案的第一天,没有任何缓冲余地,团队需要在没有明确问题的情况下去评审一个产品解决方案,方案死亡率高、评审讨论没有重点。
分析场景下的问题:
场景1-3:
不论是接到需求、还是需要跨线跟进、希望了解的项目,为了完成工作,经理们一般做两件事:
1)找人:
找人的最终目的是获取完成工作所需要的背景信息,问下熟悉业务的同事,让同事将整理过的业务材料同步下,开个简短的碰头会了解情况。(虽然并不是每次都可以约到忙碌的同事)
2)挖掘背景信息:
- 有效信息往往分散在相关工作交付物的生产者头脑之中;
- 即使我们得到一些交付物(比如文档、设计稿、代码),但在我们不清楚交付物的上下文背景(为什么这么写方案/设计)之前,交付物对我们的工作没有帮助;
- 存在我们知道自己不知道的、我们不知道自己不知道的信息,背景往往需要主动挖掘。
总结:
找人、挖信息、整合信息的成本很高,而且无法与外部交互来验证信息质量,短促的工作周期也没有留给我们太多时间,缺乏高效率的获取背景信息的渠道。
场景4:
作为产品,大家都知道在每一个看似简约的方案背后,我们付出了多少幕后工作。
但导致方案死亡率高的原因是多种多样的,刨除职场政治、个人产品能力等非标准因素后,导致这个问题的原因指向:没有前置的有效共识。
为了规避这种情况,我们付出了一些努力,但收效甚微:
1)需求调研阶段,约相关人员了解项目背景信息。
在两周一个迭代的环境下,这种非正式沟通的时间非常难约,即使约到了,因为背景信息不同步,沟通质量往往不高。
2)在评审前,把方案提前发给相关人员。
当前阶段的沟通是单点沟通,但我们需要的是项目关键人物就同一问题/方案达成意思一致。
总结:
导致方案见光死的原因是,缺乏前置公共讨论问题/方案、在会前达成初步共识的渠道。
二、需求分析
我们认为满足以下需求,可以让经理们的日常工作更加有效率:
- 便利的获取项目、人、物料的完整背景信息,高质量的完成产品方案。
- 在正式评审前,我们希望方案在非正式的场景下被大家公开讨论,达成初步共识,避免见光死。
三、历史上的协作解决方案
1. 协作问题定义
在完成工作目标的过程中,获取相关生产背景信息困难的问题。
2. 生产力协作工具:
1)定位:
重点解决某一职业、场景下的标准化问题
如:Teambition、worktile、jira、蓝湖、协作文档。
2)优势:
在特定的场景和人群内部,通过高度标准化,提高信息处理、同步的效率。
如:项目管理,设计管理、代码托管、文档同步等。
3)局限:
有效信息协作只存在于特定职业人群、场景内部,范围狭窄。
4)结论:
可以有效解决特定人群、场景下的标准化问题,对非标问题拓展性较差。
- 比如代码托管工具,在研发同学内部效率很高;
- 但涉及研发外的岗位,内部研发信息并不具有对外解释性;
- 这些未经解释的信息对外部的用户是无效的,仍然需要靠人(研发同学)来解释说明。
3. 即时通讯工具
1)定位
重点解决找人问题
如:钉钉、微信/企业微信、飞书
2)优势
人的组织架构明确,单点沟通效率高,底线是一定能联系上目标人物,为获取信息提供可能性。
3)局限
- 信息无法沉淀、迭代、复用,信息分散,无法被组织;
- 无法就长线、非正式但重要的问题展开讨论(第1点导致的结果);
- 重复的问题被不停的提出、重复解决(第1点导致的结果)。
4)结论
单点沟通、面状确认效率较高,但因为信息分散在各个单点,使得组织信息十分困难。
- 单点沟通的目的是发出邀约、收发物料、简单同步;
- 面状的一对多沟通,多用来确认事项;
- 信息无法沉淀、组织,意味着公共讨论同一问题的信息背景天然不存在,有效讨论和共识不可能发生。
四、协作问题分析
总结场景、历史方案中的问题,我们发现:
- 找人、挖掘背景、整合信息的成本很高,而且无法与外部交互来验证信息质量;
- 工作节奏快,缺乏高效率的获取背景信息的渠道;
- 缺乏前置公共讨论问题/方案、在会前达成初步共识的渠道;
- 缺乏解决非标问题的渠道;
- 信息分散在各个单点,使得组织信息不可能,也意味着不可能公开讨论、迭代长线问题及认知。
基于此,我们认为一个能补充现有协作方案的解法具有如下特点:
- 人、物料、项目、需求的背景信息可获取;
- 可以公共讨论长线问题,问答可沉淀、迭代;
- 非标问题可以被提出、解决(可能在你所在的公司此时此刻只有你面临这个问题);
- 信息可组织,找人、挖信息、整合信息的成本较低。
五、新的解决方案
梳理场景下的需求和问题,我们发现:
1)我们需要可公共讨论长线问题的渠道
问题具有完整的信息背景,相关人员都可以公开参与讨论
2)这个渠道可以提出/解决非标准问题
任何职能的用户,都可以抛出任何工作相关的疑问,得到多元视角的答案
问题和答案持续沉淀、迭代
3)信息挖掘、整合的成本应该被摊销,不再只依赖个人
- 问题只要被公开讨论一次,就可以无限复用迭代,降低边际成本;
- 问题提出、回答的迭代过程就是信息整合的过程,个人的整合成本分摊给团队。
1. 方案定位
以问答的形式,来解决职场协作问题的信息连通器。
职场人是信息连通器中最重要的组成部分。
创造的新体验:
- 在非正式场景下请教同事,在降低社交压力的同时,获取你需要的工作信息;
- 在会议开始前与大家达成初步共识,评审上会一次过;
- 所有的信息记录在一处,不再丢三落四;
- 自我表达的新方式,将有价值的幕后工作输出为价值,从幕后走到台前。
旧体验:
- 钉钉、飞书、微信已读不回,石沉大海;
- 评审会上众人懵,方案见光死;
- “咦,我记得评审记录丢在石墨里了,还是记在notion里了?好像是上周五开的会?”;
- “你的思考在哪里?”
2. 用户流程
3. 方案简介
1)速记
所有的工作信息记在一处,在浏览同事的回答/问题时,摘录启发思考的信息。
step1 记录信息:
step2 整理信息(复制或去提问):
2)提问
向同事提问,详细描述问题的背景和目的,展示对问题的认知深度。
3)回答
展示你的专业度和业务熟练度,向同事重新介绍自己。
4)摘抄问答至速记页
无缝摘录你感兴趣的信息,取百家之长,启发工作灵感。
换用成本:
- 将最近3天的随手记录,复制到速记本;
- 不再用微信/钉钉Q人提问,只需描述问题然后转发给同事。
价值核心:
使得工作场景下的非正式公开讨论成为可能
六、最后
我们所处的时代,是人类史上生产力工具迭代速度最快的时期,但协作问题真的只是一个生产力工具范畴的问题吗?
职场政治、专业化的分工、企业的架构、组织的形态,不可控的变量数不胜数,也让协作问题变得更有魅力,让人沉迷,登山不需要理由,只因为山在那里。
本文由 @ 大北 原创首发于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
一个来自未来邀约:
是的,“蜂巢问答2.0”(文中提到的产品,正在研发中)即将面世,所以这是一封写给我们未来用户的邀请函
蜂巢问答的用户具有怎样的特征?
1. 认为开放、客观、言论自由是一个富激情和创意的团队必备的品质
2. 曾经被协作问题困扰,愿意尝试破坏性创新的解决方案
3. 认为好的团队应该多一些专业,少一些职场政治
4. 喜欢猫咪(好吧,这句是开玩笑的 :)
内测用户招募的申请小贴士:
1. 总计招募20个内测团队(可能依据情况调整数量)
2. 首先,希望以(≥2)的人数,作为团队来使用蜂巢问答(不然你会发现特别无聊,这是teamwork不是单机哦)
3. 希望参加内测的你,请在人人的评论区备注以下信息:(请人人的小编同学手下留情哦)
• 你的称呼(可以是昵称)
• 你的常用邮箱账号
• 使用人数(方便我们前置配置资源)
• eg:大北 XXXX123@喵猫.com 7人
确认流程:
1. 开启内测前,我将发送邮件邀请函给留言的申请人(暂定7月中旬)
2. 收到邀请的邮件确认反馈后,我将发送邀请码给申请团队,开启内测
关于产品的预期:
1. 首先要向未来的内测用户说声抱歉
2. 因为能力和资源限制,可能无法让产品以最卓越的状态与你见面(mvp版本)
3. 但能保证的是,这是一个经过蜂巢问答团队内测的、可用的稳定版本
4. 还可以保证,这是蜂巢团队当前能拿出来的最好版本,也是一个可以骄傲的推荐给朋友的版本
5. 这是一个建立在失败的基础上的、经得住考验的新版本(大家会发现这是2.0版本)