神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：我们总是听闻，要做好产品经理，真的是太难了。有时候，我们甚至还会听说设计师或工程师吐槽产品经理的故事。实际上，做好产品管理，除了人际沟通能力之外，效率也很重要。这篇文章，原标题是6 diagrams I use to explain Product Management concepts，作者Curtis Stanier是一名资深产品经理。Curtis在文中分享了他在产品管理过程中经常使用的用来提高工作效率的6个图表，希望对你有用。

• 推荐阅读：巴菲特认为，掌握这项技能可以让你的财富增加50%

图片来自：Pexels.com

在人际沟通中，我们可能都有一个共识：能用图表达清楚的，尽量就不打字。老实说，我认为图的重要性远不止于此。图片不但可以增进你的共识，而且还可以为你减少书面语言所带来的复杂和一些不明显差别。

在这篇文章中，我希望给大家伙儿一起来分享我在日常工作中，讨论有关产品管理想法所常用的6个图表。这些由我自己手绘而成的图表，不仅广受欢迎，而且更重要的是，它们能让人快速便捷地了解有关思想。

这6个图表分别是：

• “产品经理瓶颈”图

• “大小任务流量”图

• 经典“瀑布与敏捷”图

• “方案大小、风险及领导参与”图

• “知识柱状”图？

• “分段价值”图

如果你觉得它们对你的工作有帮助的话，那就尽情享用吧。

图表1：“产品经理瓶颈”图

我发现，许多产品经理最常犯的错误之一，就是自我感觉良好，认为自己不能漏过任一工作环节的讨论。能够理解的是，有这样的想法，的确存在工作态度积极的成分。毕竟，你是产品经理，为了做到产品开发过程中的面面俱到，你也需要尽量地全面了解各方面情况。

遗憾的是，这样的做法，也存在许多明显的弊端。

首先，这种做法有点不太切合实际。你很快就会发现，自己有一大堆事情做不完。这不仅会对团队效率产生负面影响，而且还对给自己的带来一定的压力。相信我，我在这方面是过来人。

其次，这种做法也是在破坏团队成员的自主工作。

优秀的产品经理，他们知道该何时介入相关工作之中，也知道何时又该“全身而退”。他们清楚自己不必参加哪方面的讨论。让团队成员自主工作的目的，也就是在于尽可能地减少他们在各方面的依赖。

在下列图表所示的案例中，你可以试想一下左图中的工作场景。

网页端开发工程师向产品经理提出一个需要开发的概念，于是产品经理就去跟产品分析师沟通有关事宜。产品分析师称，这个开发必须做到与iOS系统同步匹配。随后，产品经理又去跟iOS系统开发工程师沟通，收集相关细节信息，再反馈至网页端工程师那边，跟他们解释探讨。

这样的工作方式，不仅给产品经理造成了许多不必要的工作，同时就网页端工程师所提出的问题，在解决速度和效率方面也出现了怠慢。

相比之下，在图表右侧的工作场景示例中，如果网页端开发工程师能够直接跟产品分析师沟通，从他那里了解有关需求，然后他们再直接跟iOS系统开发工程师保持同步沟通，这样也能完成这项工作。

你也会发现，这样的沟通方式，相比于左图少了许多不必要的沟通交流（见上图红色箭头）。

此外，如果我们在前述图表案例的基础上，再增加其它几个需要同事讨论的其它内容（见上图绿色和蓝色箭头），这样的模拟也更符合真实工作场景中所遇到的真实的情况，那你就会看到，如果产品经理需要介入每一项工作的话，那需要他去沟通处理的事情数量，会大幅度地增加，而且每一项事情的沟通进展，都必须通过产品经理来沟通完成。

如何使用“产品经理瓶颈”图？

如果你在工作中总是在各项任务中忙得不可开交，那你就得停下来，思考团队成员之前的沟通交流是不是真的存在问题。

试问自己：自己是否需要参与每一项沟通交流？如果你在休假期间，团队成员的工作进展是否仍然可以稳步向前推进，还是会全方位停止？如果是后者的话，那你能做的，就是去思考，在没有你的情况下，到底怎样才能促进团队成员之间的沟通交流。

图表2：“大小任务流量”图

这个图表我个人非常喜欢，它可拿来理解和分析团队的工作量以及各项正在执行的任务大小等问题。针对产品上市问题，无论是业务合伙方，还是产品团队的成员，他们都提到了整一个完整的过程太慢，同时也让人非常沮丧。

造成这样的一个问题的原因，通常都是因为只关注更重要的工作而造成的（见上图中左侧漏斗案例）。

因此，团队一次只能完成一项任务。如果我们的工作目标非常明确，而且也无需任何调整，那可能这种方法还可以接受。然而，这样的一种情况在实际工作中也非常罕见。等到事情从漏洞孔掉出来后，你才发现，这个事情是行不通的，那你可能就需要花更多的时间和经历来吸取这个错误教训。

敏捷方法之所以提倡小任务工作法，是因为价值可以更快地体现，同时风险也相对较低。

右图中的漏斗就可以体现相对更大的灵活性。小任务（蓝色圆点）可以快速通过漏斗并得以验证。如果验证成功，我们就可以投入更多精力（粉色圆点）。否则，我们就只需要在相对投入较少的情况下再次迭代。

每一次验证，都可以让我们进一步投入。这样做，就可以完成一系列小任务、一些中型任务及部分大任务，既降低了一定的风险，同时又提高了投入回报。

如何使用“大小任务流量”图？

回顾过去一个月以来自己所参与的任务。就规模和复杂程度而言，这些任务属于大任务，还是包括了各种类型的任务？对这些任务进行标码，比如小中大，然后思考你自己的漏斗会是怎样的。

图表3：经典“瀑布与敏捷”图

实际上，网络上有很多关于这方面的案例。所谓“瀑布”，其实就能够理解从产品概念、启动、分析、设计、开发建造、测试、发布的自上而下“瀑布式”的连贯工作方式，前一项任务没完结之前，不开启后一项任务。

相比之下，“敏捷”则能够理解为基于时间线的快速交付产品的方法，它可以根据核心框架在完成主要功能后，再通过不断地迭代，完善细节方面的功能。

但在这里，我想强调的是付出的这样的一个过程。对许多产品开发团队而言，他们都没有让成员明确地 意识到，团队所耗费的时间，实际上也是一种投资。

如果所有的产品经理都有独立的产品开发利润表的话，他们通常都会看到，人员开支是整个团队开支中最大的一笔费用。所以，无论如何，都要寻找一切有利机会，提高利润（或回报）。

当团队推出重大更新过后，你肯定希望立即就看到价值的提升。或者你甚至在更新过程中，就开始设想，这一次的更新，肯定是最完美的解决方案，不会有任何技术故障（但现实是不可能的）。

左图为重大更新，横轴为时间，黄色箭头代表的是付出，蓝色箭头为价值；右图为小型迭代更新。

左图中，团队成员为了一个重大更新，可能会在投入大量时间的前提下，看不到任何价值的体现。

如果提高更新频率，每次都推出小型更新，那你就是在渐进式地完成产品开发更新工作。这种方式，你的投入很快就会看到回报，毕竟你可以更快地从错误中吸取教训，也可以更快地实现价值提升。很快，产品的价值提升就会超过团队的付出，这也是每个团队都应该努力奋斗的目标之一。

如何使用经典“瀑布与敏捷”图？

通常，我会借助这个图表，来解释为什么“只多加一项任务”可能就不符合团队的最大利益了。此外，这也是一种有效的方法，让你提醒自己和你的团队，思考自己的团队角色将对业务方面产生什么影响。

图表4：“方案大小、风险及领导参与”图

就这个图表而言，主要有两方面内容。

左图中，是一个方案金字塔。金字塔的宽度，代表着一次性可能需要解决的方案数量。底部最宽，证明需要讨论决策的方案数量最多，相应方案的风险就相对较低。而金字塔顶部最窄，证明需要讨论的方案数量最少，风险自然而然地就最高。

右图中，是一个衡量领导参与的倒金字塔。金字塔越宽，就代表期待或需要领导的参与度就越高。在这种情况下，就应该更多地咨询领导的意见。金字塔越窄，需要领导的参与度就越低。

作为团队成员或者产品经理，你应该尽可能多地执行小型方案。这些事项的风险通常都不高，而且还可以不断地优化。领导不希望在这些事项上耗费时间与功夫，否则意义也不大。

然而，如果涉及到金字塔顶端的方案，通常就代表更高的风险。比如，考虑推出全新的产品。这样一个时间段，你就需要领导的介入和支持。

如何使用“方案大小、风险及领导参与”图？

无论是涉及领导或者团队的情况，我发现这个图表都非常实用。它简单易懂，向我们解释了为什么领导在某些议题上必须出面，为什么在其它方面又不必浪费他们的时间或经历。

图表5：“知识柱状”图

这个图表来源于我的一位同事，他主要是负责对团队运营健康进行季度检查。通过柱状图的形式，来视觉化呈现部门和团队在知识分享方面的影响，是一种非常直观和便捷的做法。

毋庸置疑的是，我们不可能在方方面面都非常精通。然而，如果清楚自己在某些知识方面存在欠缺，那你就会更关注彼此间的交流。

团队组织（或个人）大小与意识的关系图。纵轴从上到下反映的是意识最高与最低，横轴中，最左是个人，随后是慢慢的变大的团体，分别是小分队、大团队、其它团队，及其它部门。

作为团队的一份子，你必须要充分意识到自己所做的工作。这种意识，当你置身于上一团体中会出现下降趋势，并且在越大的团体中，相关意识可能会降低到最弱。

如何使用“知识柱状”图？

频繁提醒自己和身边的人士，你所在的团队可能会因为没有人在方方面面都非常精通而导致效率降低。此外，如果在团队中出现观点分歧或冲突时，很可能是因为缺乏相关信息才导致的，这些分歧和冲突实际上也不存在恶意。

图表6：“分段价值”图

纵观大多数公司在针对产品方案和测试做出相关决策时，最常见的错误之一，就是对所有方案进行优化，保证平均效果，而不是择优或分段优化。

关于“平均”可能存在的扭曲观念，我通常都会用这个例子来举例：普遍而言，人们平均都略少于两条腿（由于某些人士只有一条腿，甚至没有腿，所以普遍而言，这个平均数会略小于2）。

在产品开发过程中，如果有关假设和关注范围过于广泛的话，那它必然会限制团队成员所创造的影响。这就好比，如果你想一次性安抚所有人的话，这也是不太现实的事情。

在下图中，最右列案例三的实验Z，可能是最常见的情况。

图表中的三个案例，分别对应的是三种不同的假设性实验。案例一中的实验X，反映的是效果提升；中间案例的实验Y，则体现的是实验失败，而右方案例三的实验Z，则没有特别的效果。

然而，如果你进一步挖掘这些实验结果，你可能就会发现更多的机会或者限制。

在案例一中，虽然实验成功，整体效果得到了提升，但B段实际上却效果欠佳。在这种情况下，我会去进一步了解为什么B段效果欠佳，甚至可能会考虑在最后推出产品时，直接移除B段。

同理，在案例三中，虽然整体效果并没有特别明显的变化，但B段和C段都出现了不同程度的效果提升。这两个结果也刚好和A段和D段的欠佳相抵消。你也因此可以进一步去了解背后的有关原因。

如何使用“分段价值”图？

在提出假设时，一定不能泛泛而谈，而是要尽量具体，从而针对相关结果进一步挖掘，发现其背后的机会或缺陷。我强烈推荐资深产品经理里克·希格姆（Rik Higham）关于假设和实验的模型，具体可搜索EXPERIMENTATIONHUB网站的假设包（Hypothesis Kit）。

此外，你也能够最终靠使用者真实的体验分析师妮基·安德森（Nikki Anderson）的方法，借助用户调研和人口数据来创建用户角色，从而进一步了解你的目标对象。

译者：俊一