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

产品经理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）结论 单点沟通、面状确认效率较高，但因为信息分散在各个单点，使得组织信息十分困难。 单点沟通的目的是发出邀约、收发物料、简单同步； 面状的一对多沟通，多用来确认事项； 信息无法沉淀、组织，意味着公共讨论同一问题的信息背景天然不存在，有效讨论和共识不可能发生。 四、协作问题分析 总结场景、历史方案中的问题，我们发现： 找人、挖掘背景、整合信息的成本很高，而且无法与外部交互来验证信息质量； 工作节奏快，缺乏高效率的获取背景信息的渠道； 缺乏前置公共讨论问题/方案、在会前达成初步共识的渠道； 缺乏解决非标问题的渠道； 信息分散在各个单点，使得组织信息不可能，也意味着不可能公开讨论、迭代