时间: 2021-07-30 11:30:27 人气: 10 评论: 0
为什么一些领导的决策**如此愚蠢？为什么面对问题**一脸懵逼？为什么我们总能避开正确的答案？为什么一手好牌能打成烂牌……如果你也有相同的困惑，这篇文章或许能给你一些解答。
今天这篇文章是一篇译文，作者特蕾莎(Teresa)是一名富有经验的产品发现教练，这篇文章源自于她在2017年伦敦产品思维大**的演讲——产品团队的批判性思维。
因为觉得它很有价值，很认真地做了不严格（根据个人理解有所有调整）的翻译。
读了这篇文章以后，我突然明白，一切决策都和心理表征有关系。心理表征源自于过往的经历并长期存储于头脑之中。如果领导在做决策的时候心理表征是“面子”，那么解决方案可能就是“维稳”。
但不可否认，每个人的心理表征都**有一定局限性。我们在做决策的时候，倘若缺乏开放民主的态度，缺乏客观的流程和方法，不能让不同背景的专业人士贡献出自己的心理表征，那最终决策必然存在极大的风险。
作者也提出了自己的解决方案——“机**解决方案树”。它通过可视化方式共享团队成员的心理表征，达到合理决策的目的。
最后，祝大家2020新年快乐，阖家安康。
早在2008年，我在一家初创公司担任产品经理，我们主要的产品是为大学生校友**服务的在线社区。和许多产品团队一样，我们也面临诸多的挑战。
每当我们推出一个新的在线社区的时候，校友们都**争先恐后地去看看他们的新网站。但随着时间的推移，访问量却变成了涓涓细流。
通过用户研究，我们知道校友们喜欢给其他社区成员发送邮件来征求建议，例如，“如何找到下一份工作？”“住在新城市的哪个地方合适？”，这些也正是我们希望用户做的。
我们的产品允许用户向整个校友社区发送邮件，但问题在于没有人愿意收到垃圾邮件。例如，住在达拉斯的校友收到电子邮件有“在芝加哥出售的物品”“在波士顿出租的房屋”以及“在旧金山的实习机**”。
如果我们想提升校友的参与度，我们就必须减少社区中不必要的垃圾邮件。
你是否和我一样，已经开始思考如何解决这个问题了？
当我求助于我的团队，开始头脑风暴的时候，我们的工程师赛斯提出：“让我们集成谷歌地图！做一个能展示全球校友居住位置的地图。”
我很震惊，居然有如此的突发奇想。我实在想不出其中的道理，很好奇地问：“谷歌地图**如何为我们解决垃圾邮件的问题？”但赛斯回答：“哦，不**的，但这**提升参与度，因为这很酷。”我开始向其他小伙伴寻求帮助，可悲的是，他们同意赛斯的观点：地图**很酷。
当时，我无法用言语来表达我的沮丧，但直觉上我知道做一个酷的东西是不够的，知道人们住在哪里并不是一个很大的需求，添加谷歌地图感觉就像是个噱头。
其实，这个故事并不是关于“我和赛斯，到底谁对谁错”而是一个更复杂的故事：一名产品经理应怎样让团队做正确决策，而不是怎样让团队做得更快。
如今，作为一名产品发现教练，我看到了这一幕在一个又一个团队中一次次地上演：我们不知道，一个既定的目标（如提升参与度）如何有效地转变为相关的具有可行性的解决方案。于是我试着解构拆解这个问题：
我们很容易产生一个想法。当我们听到一个需求时，就**立刻自动地在想解决办法，或许这样闭合的脑回路感觉很好。
但当我们爱上我们的想法时，我们不愿意审视它，我们也不**停下来反思，我们不**问：“这个想法到底真的好吗？”
这就是赛斯的问题，他了解了谷歌地图API并很兴奋，他迫不及待地想试试看。他和我们团队的其他成员分享了他的想法，他们很快也爱上了这个想法。
当我们爱上我们的想法时，我们就不**考虑足够多想法。
我的团队非常喜欢谷歌地图的想法，他们迫不及待地开始深挖，迫不及待地想要做些能提升参与度的事。谷歌地图的想法可能是个好主意。但是头脑风暴的研究表明：当我们产生更多的想法时，我们就**产生更好的想法。
更重要的是，当我们考虑更多想法时，我们**做出“比较和对比”的决策，而不是“非是即否”的决策。
我们很难非是即否地回答，一个决策是好还是不好。因为“好”不是绝对的，而是相对的。我们应该问一个“比较和对比”的问题：“这些想法中哪一个看起来最好？“这更容易回答。
试想一下，短跑冠军博尔特独自在一条赛道上跑步，他跑得快吗？这很难说。再想象一下，他和其他选手在一条跑道上跑。他跑得快吗？
很明显，一个“比较和对比”的决策**更容易评估。
此时，你或许觉得自己已的想法够多了，稍后**讲怎么办。
先让我们回到我的团队的问题上：我们爱上了我们的第一个想法，这也导致我们没有把想法考虑得够多。除此之外，我们团队还犯了以下的错误：
赛斯的谷歌地图想法让我抓狂的原因，不是因为我觉得这个想法不好，而是因为我觉得这无关紧要。它没有解决我想解决的问题。这说明，我们也没有围绕着一个目标机**（或我们试图解决的问题）进行思考。
在我的团队在进入创意阶段前，我没有花时间确保他们在问题上保持一致。以至于赛斯在思考如何提升参与度时候，却没有考虑到我所关注的：如何减少垃圾邮件的问题。
头脑风暴**议中，我认为减少垃圾邮件是一个正确的机**，而赛斯想的却是帮助人们与附近的校友建立联系。我们俩都只考虑了各自的一个机**点。
就像我们通过考虑更多的想法避免“非是即否”的问题一样，机**点也是如此。我们不要问“这个机**值得追求吗？”我们要问“这些机**中哪一个看起来最好？”
这也就是说，如果没有更多机**点可供选择，我们就**冒险去解决一些不重要问题。
我们应该做的是退后一步看问题：“所有可能提升校友参与度的机**还有哪些？”
安德斯·艾利克森写了《刻意练习：如何从新手到大师》一书，这本书总结了他用毕生的工作，探寻新手和专家之间的区别。
他认为专家比新手有更复杂的心理表征。他对心理表征的定义如下：
“心理表征是长期保存在记忆中的预设的信息模式，如事实、图像、规则、关系等，可以用于在某些特殊情况下快速而有效地作出反应。”
他认为：
“心理表征的重要价值在于它能帮助我们处理信息：帮助我们理解和解释信息，并将其保存在记忆中，对其进行组织和分析，并帮助我们据此做出决策。”
这不是我们所需要的答案吗？是什么使我们能够理解、解释、组织和分析我们收集的所有信息，以便我们可以据此做出更好的产品决策？
在上面的故事中，我们每个人都带着不同的信息来参加头脑风暴**议，每个人都依赖自己的心理表征来快速做出决策。我是带着对用户的深入了解来参加头脑风暴**议的，因为我刚刚完成了一轮用户调研。而赛斯带着对新技术的深入了解参加了头脑风暴**议，因为他刚刚读过谷歌地图API。
唯一的问题是，产品团队需要联合团队成员的知识，通过共享心理表征作出快速决策。
因此，我提出了“机**解决方案树”这个视觉化思考工具：通过可视化的树状图，把预期目标的拆分成不同的机**点，再把机**点拆分成多个解决方案，在通过实验验证解决方案的可行性。
产品团队需要弄清楚他们想要达到的目标是什么？
我的团队有一个明确的预期目标，那就是提升校友的参与度。但从我们的团队可以看出，光有一个清晰的目标结果是不够的。
我们需要自问一下：“什么可以提升参与度？”在我们开始寻找解决方案之前，我们应该先画出机**空间。
我们很容易将机**理解成客户的需求或痛点，但我们也需要考虑那些让人愉悦的机**和可成功复制的机**。
为了探索如何达到预期的结果，我们应该从规划机**空间开始。
为了确保我们始终以用户为中心，我喜欢将机**点的定义限制为客户可能**说的话。这些机**点应该来自生成性研究——客户访谈和客户观察 。
现在我的团队刚刚结束了一系列的校友访谈，我们获得以下的机**列表：
这个列表列出我们在校友访谈收集到的内容。接下来怎么做呢？
大多数人可能**先开始排列优先级，你可能**问：“哪些机**对我们来说是最重要的？”
但如果这些机**点的类别不相近，那我们很难对它们进行优先级排序。例如，“雇佣一个应届毕业生”或“指导一个学生”都属于“回馈社区”的方式，我们很难对他们进行优先级排序。就像我们拿“苹果”与“水果”做优先级比较，显得有点不合理。
译者点评：这里用的麦肯锡的金字塔法则更加易于理解：问题需要进行分类，做到“相互独立，完全穷尽”，苹果和水果是相互包含的关系，不同层级的事物难以进行比较。
为了简化我们的优先级排序难度，我们可以将这些机**点分组，将类似的机**整理在一起。这样**更加清楚。最后我分成了三组：
我们可以先对这三组进行优先级排序，而不是对一个很长的列表进行优先级排序。
从用研报告可知，我们用户反馈的较为普遍的机**点是“我需要帮助”。
虽然确实也有人反馈“收到了太多的电子邮件”，但这并不像“我需要帮助”那么普遍，但请注意我的“我收到太多电子邮件”的位置。
“谁住在我附近”在“我需要帮助”的机**点之下，这样看来赛斯似乎是对。
如果赛斯和我今天有这样的对话，这棵树无疑**帮助我们对话提升一个层次。与其争论“电子邮件太多”与“谁住在我附近”，不如先问问这三个机**点哪一个更重要。
我们很容易就同意“我需要帮助”的机**对校友来说是最重要的。我们应该把注意力转移到优先考虑“我需要帮助”机**的子节点上。
但现在又有些问题困扰着我，我认为“我需要帮助”与“我收到了太多电子邮件”有着内在的联系。我们需要把需要帮助的人和能提供帮助的人联系起来。如果我们用户滥发电子邮件，他们就不太可能提供帮助。
这告诉我，我们的机**结构并不完全正确。如果两个机**有内在的联系，那么我希望它们在树上彼此更接近，以反映这种联系。让我们再试试。
通常，机**的组合方式并不是只有一种。你的机**结构应该反映出你在用户调研中听到的内容，并且应该能较好地优先级排序。
首先，我将“我需要帮助”和“我想回报社社区”的机**点合并为一个名为“我想与其他校友建立联系”的机**点，在它下面再有3个子节点：
机**结构在重新调整后，把我们的视线带到了市场的两端——需要帮助的人和能够提供帮助的人。他们在同样的机**节点下更加紧密地联系在一起。当我们在给不同的联系方式（如，专业性、地理位置等）排定优先级的时候，也不**偏袒市场的某一方。
这也减少了我和赛斯之间的分歧。我们都同意应该将注意力放在左边的分支上。我们只是不同意哪个机**点**更重要。这使得通过查看数据更容易解决我们之间的分歧。我们可能**问：“有多少校友想与身边的人建立联系？有多少校友不知道该和谁联系？”
有时需要多几次尝试才能找到有效的结构。关键是要确保它能反映出你从客户那里听到和看到的信息，并能帮助你就优先考虑的事项做出正确的决定。
记住，没有绝对的答案。随着团队对客户了解的加深，您的树结构将继续发展。视觉化思维的价值在于，它能帮助您的团队解决分歧，并共享不同的视角。
一旦你们有了一个满意的机**结构，你就可以考虑解决方案了。
前面提到过，可能对于大多数人来说，不是没有想法，而是想法太多。当你有太多的想法时候怎么办？
我们可能有很多想法，但它们往往**散布在我们的树上，就像这样：
头脑风暴的价值在于，通过一个又一个新的想法，推动想法的迭代，从而找到真正具有创造性的解决方案。但很多是初步的想法，也**导致产品停留于肤浅层面。
这不仅失去了头脑风暴的创造性，而且最终也导致我们面对一堆方案不知所措。另外，我们也很难给不一样的事物排定优先顺序。
相反，我们可以通过逐行排列优先级来选择目标机**，然后再深入挖掘这个目标机**点，再产生多个解决方案，如下图：
这样可以通过锁定一个目标机**来制定“比较和对比”的决策，而不是让想法散落在不同的机**之间。最终，你**发现有许多的想法去解决一个目标机**。
现在，你已经有足够多的想法了。你可能考虑开始排定优先级了，或者迫不及待开始试验你的头号Idea。但这**导致另一个“非是即否”决策——我们觉得最好的想法到底是好是坏？我们应当建立一个“比较和对比”的决策，我期望你能回答：这些解决方案中哪一个看起来最具有可行性？
当我们有很多想法时，我推荐你先用点投票法缩减列表，再使用实验来评估这个集合。
首先使用点投票将一个大的列表缩减为3-5项。研究表明，团体比个人更善于评估想法，而点投票是一种快速的投票方式。然后用实验来确定剩下的3至5个想法中哪一个看起来最有希望。
但值得注意的是，当大多数团队进行实验时，他们希望通过实验来确定一个想法是否好，但这是另一个“非是即否”的决定。我希望你设计的实验，能够帮助你在一系列好的想法中做出选择，做到一个“比较和对比”的决策。
做到这一点最简单的方法是，确定每个想法成立所需的关键假设，然后设计实验以测试每个假设。如下图，
如我们选取“推荐收件人标准”这个想法，通过地理位置自动匹配收件人和发件人，或根据朋友的朋友来发送消息。我们可以列出这些关键问题和实验设计：
关键问题：请求帮助的人**信任我们的收件人推荐吗？实验设计：我们可以制作一个用户界面的原型，看看人们的反应。
关键问题：我们是否能够预测谁应该能够收到消息？实验设计：我们的机器学习团队可以做一个可行性实验。
关键问题：朋友的朋友更有可能提供帮助吗？实验设计：查看数据库，看看朋友的朋友是否更有可能回复之前的消息。
你可能**问：我怎么知道我的实验结果是否好？例如，15%的转化率够高吗？
这就像是我们在问：“博尔特跑得快吗？”当他独自在跑道上跑步时，很难说。但是，如果你尝试了多种想法，你可以问：“根据我收集的数据，哪种解决方案看起来最好？”这很容易回答，就像博尔特和别的运动员一起赛跑时才能显得更快。
请用做实验的方式在一组解决方案中选择，而不是评估单个解决方案。
数十个产品团队受益于“机**解决方案树”，如果你像我一样，你想让你的整个团队参与决定构建什么，但你总是被“谷歌地图”所困扰，或者你的团队陷入了意见辩论的泥潭，那么我建议你开始构建一个机**解决方案树。
花点时间直观地描绘出你的思维，将有助于你的团队抓住常见的批判性思维错误，如创建“非是即否”决策而不是“比较和对比”决策。
另外，这棵树还充当了一个发现路线图，帮助你的团队对机**空间，以及实现预期成果的潜在路径的达成一致共同理解。和传统的路线图一样，它将帮助你向你的领导和公司其他人传达你所了解的东西。
译者注：作者绘制了一张图描述了如何通过“机**解决方案树”做到持续发现的能力：产品团队按季度制定目标，通过每周进行客户访谈来发现机**点，然后针对一个机**点构思大量的解决方案，并制作原型和实验来评估解决方案的可行性，过程中不断的迭代优化。
请开始你的机**解决方案树，记住以下几个要点：
最后，首先给前线的医务工作者致敬，再给还在武汉的朋友们致敬，最后也致敬每一个宅在家中的你，正是因为宅，所以阻断了病毒传播的机**。
如果你对于“机**解决方案树”还有什么问题，也在本文末留言。
PM熊叔，微信公众号：PM熊叔，人人都是产品经理专栏作家。教育类产品产品经理出身，学过设计，做过开发，做过运营的产品经理。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
