产品经理60%时间用于协作,我们找到了破局方法

1 评论 3332 浏览 7 收藏 13 分钟

编辑导语:产品经理在日常工作中很多时候都需要跟各方面进行沟通,所以沟通协作对于产品经理来说是非常重要的一个能力,在很多时候可以带来更高的效率;本文作者分享了关于产品经理协作的破局方法,我们一起来了解一下。

据不完全统计,产品经理在工作中60%以上的时间用于沟通协调。

当团队中理应提供洞察,为产品指明道路的经理们深陷沟通泥潭,长线价值的思考资源完全被无止境的会议和碎片化的沟通占据,导致产品经理的个人成长空间与产品价值一起内卷,陷入恶性循环。

一、PM的场景&问题

产品经理每天面临大量的沟通协调,那么,我们在沟通、协调些什么呢?

  • 场景1:接到一个需求,需要理清方案为什么采用现在的设计、历史版本什么样、谁是设计者?
  • 场景2:跟进一个跨多条业务线的项目,希望知道各线业务的运作方式
  • 场景3:工作相关、未直接参与的项目,但需要了解项目细节、及内部的依赖关系
  • 场景4:上评审会的那天,往往是团队成员看到问题/方案的第一天,没有任何缓冲余地,团队需要在没有明确问题的情况下去评审一个产品解决方案,方案死亡率高、评审讨论没有重点。

分析场景下的问题:

场景1-3:

不论是接到需求、还是需要跨线跟进、希望了解的项目,为了完成工作,经理们一般做两件事:

1)找人:

找人的最终目的是获取完成工作所需要的背景信息,问下熟悉业务的同事,让同事将整理过的业务材料同步下,开个简短的碰头会了解情况。(虽然并不是每次都可以约到忙碌的同事)

2)挖掘背景信息:

  • 有效信息往往分散在相关工作交付物的生产者头脑之中;
  • 即使我们得到一些交付物(比如文档、设计稿、代码),但在我们不清楚交付物的上下文背景(为什么这么写方案/设计)之前,交付物对我们的工作没有帮助;
  • 存在我们知道自己不知道的、我们不知道自己不知道的信息,背景往往需要主动挖掘。

总结:

找人、挖信息、整合信息的成本很高,而且无法与外部交互来验证信息质量,短促的工作周期也没有留给我们太多时间,缺乏高效率的获取背景信息的渠道。

场景4:

作为产品,大家都知道在每一个看似简约的方案背后,我们付出了多少幕后工作。

但导致方案死亡率高的原因是多种多样的,刨除职场政治、个人产品能力等非标准因素后,导致这个问题的原因指向:没有前置的有效共识。

为了规避这种情况,我们付出了一些努力,但收效甚微:

1)需求调研阶段,约相关人员了解项目背景信息。

在两周一个迭代的环境下,这种非正式沟通的时间非常难约,即使约到了,因为背景信息不同步,沟通质量往往不高。

2)在评审前,把方案提前发给相关人员。

当前阶段的沟通是单点沟通,但我们需要的是项目关键人物就同一问题/方案达成意思一致。

总结:

导致方案见光死的原因是,缺乏前置公共讨论问题/方案、在会前达成初步共识的渠道。

二、需求分析

我们认为满足以下需求,可以让经理们的日常工作更加有效率:

  1. 便利的获取项目、人、物料的完整背景信息,高质量的完成产品方案。
  2. 在正式评审前,我们希望方案在非正式的场景下被大家公开讨论,达成初步共识,避免见光死。

三、历史上的协作解决方案

1. 协作问题定义

在完成工作目标的过程中,获取相关生产背景信息困难的问题。

2. 生产力协作工具:

1)定位:

重点解决某一职业、场景下的标准化问题

如:Teambition、worktile、jira、蓝湖、协作文档。

2)优势:

在特定的场景和人群内部,通过高度标准化,提高信息处理、同步的效率。

如:项目管理,设计管理、代码托管、文档同步等。

3)局限:

有效信息协作只存在于特定职业人群、场景内部,范围狭窄。

4)结论:

可以有效解决特定人群、场景下的标准化问题,对非标问题拓展性较差。

  • 比如代码托管工具,在研发同学内部效率很高;
  • 但涉及研发外的岗位,内部研发信息并不具有对外解释性;
  • 这些未经解释的信息对外部的用户是无效的,仍然需要靠人(研发同学)来解释说明。

3. 即时通讯工具

1)定位

重点解决找人问题

如:钉钉、微信/企业微信、飞书

2)优势

人的组织架构明确,单点沟通效率高,底线是一定能联系上目标人物,为获取信息提供可能性。

3)局限

  • 信息无法沉淀、迭代、复用,信息分散,无法被组织;
  • 无法就长线、非正式但重要的问题展开讨论(第1点导致的结果);
  • 重复的问题被不停的提出、重复解决(第1点导致的结果)。

4)结论

单点沟通、面状确认效率较高,但因为信息分散在各个单点,使得组织信息十分困难。

  • 单点沟通的目的是发出邀约、收发物料、简单同步;
  • 面状的一对多沟通,多用来确认事项;
  • 信息无法沉淀、组织,意味着公共讨论同一问题的信息背景天然不存在,有效讨论和共识不可能发生。

四、协作问题分析

总结场景、历史方案中的问题,我们发现:

  1. 找人、挖掘背景、整合信息的成本很高,而且无法与外部交互来验证信息质量;
  2. 工作节奏快,缺乏高效率的获取背景信息的渠道;
  3. 缺乏前置公共讨论问题/方案、在会前达成初步共识的渠道;
  4. 缺乏解决非标问题的渠道;
  5. 信息分散在各个单点,使得组织信息不可能,也意味着不可能公开讨论、迭代长线问题及认知。

基于此,我们认为一个能补充现有协作方案的解法具有如下特点:

  1. 人、物料、项目、需求的背景信息可获取;
  2. 可以公共讨论长线问题,问答可沉淀、迭代;
  3. 非标问题可以被提出、解决(可能在你所在的公司此时此刻只有你面临这个问题);
  4. 信息可组织,找人、挖信息、整合信息的成本较低。

五、新的解决方案

梳理场景下的需求和问题,我们发现:

1)我们需要可公共讨论长线问题的渠道

问题具有完整的信息背景,相关人员都可以公开参与讨论

2)这个渠道可以提出/解决非标准问题

任何职能的用户,都可以抛出任何工作相关的疑问,得到多元视角的答案

问题和答案持续沉淀、迭代

3)信息挖掘、整合的成本应该被摊销,不再只依赖个人

  • 问题只要被公开讨论一次,就可以无限复用迭代,降低边际成本;
  • 问题提出、回答的迭代过程就是信息整合的过程,个人的整合成本分摊给团队。

1. 方案定位

以问答的形式,来解决职场协作问题的信息连通器。

职场人是信息连通器中最重要的组成部分。

创造的新体验:

  1. 在非正式场景下请教同事,在降低社交压力的同时,获取你需要的工作信息;
  2. 在会议开始前与大家达成初步共识,评审上会一次过;
  3. 所有的信息记录在一处,不再丢三落四;
  4. 自我表达的新方式,将有价值的幕后工作输出为价值,从幕后走到台前。

旧体验:

  1. 钉钉、飞书、微信已读不回,石沉大海;
  2. 评审会上众人懵,方案见光死;
  3. “咦,我记得评审记录丢在石墨里了,还是记在notion里了?好像是上周五开的会?”;
  4. “你的思考在哪里?”

2. 用户流程

3. 方案简介

1)速记

所有的工作信息记在一处,在浏览同事的回答/问题时,摘录启发思考的信息。

step1 记录信息:

step2 整理信息(复制或去提问):

2)提问

向同事提问,详细描述问题的背景和目的,展示对问题的认知深度。

3)回答

展示你的专业度和业务熟练度,向同事重新介绍自己。

4)摘抄问答至速记页

无缝摘录你感兴趣的信息,取百家之长,启发工作灵感。

换用成本:

  • 将最近3天的随手记录,复制到速记本;
  • 不再用微信/钉钉Q人提问,只需描述问题然后转发给同事。

价值核心:

使得工作场景下的非正式公开讨论成为可能

六、最后

我们所处的时代,是人类史上生产力工具迭代速度最快的时期,但协作问题真的只是一个生产力工具范畴的问题吗?

职场政治、专业化的分工、企业的架构、组织的形态,不可控的变量数不胜数,也让协作问题变得更有魅力,让人沉迷,登山不需要理由,只因为山在那里。

 

本文由 @ 大北 原创首发于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 一个来自未来邀约:
    是的,“蜂巢问答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版本)

    回复