逻辑能力是产品经理的必修课，本文将探讨如何通过结构化思考和高效表达来提升这一能力，帮助你在面试、需求评审和项目复盘等场景中脱颖而出。

结构化思考+高效表达，逻辑能力是产品经理必修第一课。

一、引子

不管你是即将毕业正在实习的应届生，还是初入职场的新人，或是工作三五年的小年轻，亦或是具备了五年以上经验丰富的老将。结构化思考、高效表达的能力都是你在工作中的第一要素能力。

有这么几个场景让我觉得要优先做关于这个主题的分享：

• 过去其实也面试过上百个产品候选人，在公司也担任过晋升述职的评委，我们在面试候选人的时候，第一点看的是候选人的逻辑能力如何，他是否具备结构化思维，他的表达是否足够清晰有条理；
• 在做需求的时候，会发现有的时候我们过早陷入需求方提出需求的方案中，一下子就到了怎么实现环节。但是做这件事情对于目标的提升是有正向的帮助吗？还是风马牛不相及？
• 在团队内部做需求评审的时候，我们经常会在意这个需求是否闭环，是否有遗漏等。映射回大家日常在出需求、梳理PRD文档的时候，是用什么样的思路去写需求的呢？如果是想到哪里写哪里，就很容易且大概率会产生遗漏，导致需求不闭环，在评审环节被频频追问而导致整体效率低下。

以上种种，都会回归到我们的逻辑思维能力上。即我们是怎么去思l考的，以及我们是如何去表达的。

而我认为：逻辑能力 = 思考能力 * 表达能力。

要提高逻辑能力，则需要提高思考的效率和表达的效率；而结构化思考+高效表达则是这个公式的最优解。

二、结构化思考

所谓结构化思考，我们可以再往下拆解为：明确目标–归类拆解–验证漏洞–优先级思维。

1、明确目标：

所有的思考都要以终为始，从“最终要解决什么问题”开始，而非“我要做什么功能”。

例如错误的思考是：我要做一个海外节日灵动岛。

而正确的思考应该是：我要提升海外用户的留存，我希望通过灵动岛这个高留存的玩法结合海外用户的喜好开发一个新的样式来提升。

2、归类拆解：

归类拆解有两种方式，一是闭合性的方法，二是发散性的方法。

–闭合性的情况下，主要通过归类分组+MECE原则（相互独立，完全穷尽），在确保内容的归类具备自主独立性同时，也要保证内容的全集是完整的。

–发散性的情况下，主要通过“顺藤摸瓜”的主干道思维去思考。即我们需要去梳理问题的核心脉络，再在主路径上去进行各个分支节点的思路拓展，只要抓住了核心脉络，就能顺利形成结构化的思考。就像顺藤摸瓜一样，主要你摸对了藤干，顺着这个思路下去就能摸到瓜。

例如错误的思考是：我想给水族箱加个音乐、灯光。

而正确的思考拆解应该是：水族箱：分为组成、玩法、其他。组成元素又可以分为①动物主体、②鱼缸、③造景、④气温环境；玩法又可分为①成长体系、②交互。而玩法所面向的对象又是组成元素部分，相互独立又产生交叉。

这里我们就是通过归类分组的方式把水族箱拆解为组成和玩法，再对组成的元素进行细拆、玩法进行细拆。

而像发散性的案例则类似用户生命周期流程——我给大家同步过的产品用户体验旅程。这里就不展开了。

3、验证漏洞：

常见的验证漏洞方式有这么几点需要去思考的：

① 安全合规：安全合规是内容产品的底线。一旦触及红线或是被国家队盯上，都是致命的打击。

–合规备案：曾经有段时间，国家对 AI 能力备案监管非常严厉，国内有一大批没有备案但是在网站上打着 AI 功能的产品几乎在一夜之间被关站封停。

–敏感内容：之前我在的一家公司，由于平台涉及用户内容上传及可以公开传播，但是没有做强制的敏感内容审核，导致被三令五申强调整改限制；后面也是终于接了易盾黄暴政自动审核才得以喘息。

② 极限/边界情况：例如在鱼缸中鱼最多能加几条、文本输入最大长度是多少、是否允许为空以及为空的情况要怎么处理。

③ 异常情况：过程中遇到网络中断怎么办？是否有逻辑漏洞被用户恶意刷、薅羊毛？

④ AB思维：有时候方案存在不确定性，我们需要靠数据说话，则一定要时刻具备AB思维。提出假设–AB实验–解读实验–数据分析。有好的想法和迭代优化可以进行通过 AB test 快速验证我们的创意。

4、优先级思维：

一般我们需要通过「重要-紧急四象限」、「价值成本-ROI」标准去衡量各个事项的优先级，评估哪些事先做，哪些事后做或不做。

我们处于一个信息过载的时代，如果不做信息的过滤，不做信息的优先级排序，将有无穷无尽的无意义事项占据着你宝贵的精力

三、高效表达

高效表达分场景采用的方式不同，这里介绍几个常见的场景。

1、向上汇报、同步信息的时候：结论先行。

完整结构是结论先行–论据支撑–细节还原–适当总结。

① 结论先行：先把最重要的结论亮出来，清晰表达的核心逻辑是 “先给结果，再讲逻辑，最后补细节”。《金字塔原理》的核心原则中也提到：“受众的大脑只能逐句理解信息，提前给出结论能减少认知负荷，避免用户迷失在细节中”。清晰表达的第一步，不是铺垫背景，而是直接抛出核心观点（结论）。这里比较典型的反例就是，日常我们做一堆的数据分析，但是经常把最重要的结论藏在角落，甚至没有结论，所以开会的时候老板经常会问：“所以结论是什么？”这种表达就非常低效。

② 论据支撑：抛出结论后，我们需要 x 个论据来做支撑。事实上，在《金字塔原理》中，提到奇妙的数字“7”，就是在说人一次能理解的思想或概念的数量是有限的，大脑的短期记忆无法一次容纳约 7 个以上的记忆项目，比较容易记住的是 3 个项目。这就意味着，我们在表达的时候，要优先表达最核心的 x 个论据支撑，这个 x 建议是 3-5 个，不要超过 7 个。

③ 细节还原：有了核心论据的概括，我们再围绕这些论据做细节展开。在《清晰表达的艺术》中强调表达要“让受众轻松理解”，所以我们不仅需要逻辑上的框架、论据支撑，还需要具备鲜活血肉的细节来还原。例如讲需求的时候我们都要讲用户故事/场景，做复盘的时候都要看过程具体的动作，去谈客户的时候也都会需要有更具体历史成功案例和细节。

④ 适当总结：把关键性内容和表达过程中对方关注的点再次总结并确认，形成有效沟通和表达。

2、需求评审、方案提案的时候：SCQA 的本地版模型 SCOA。

原版是：情境（Situation）、冲突（Complication）、疑问（Question）、答案（Answer）。不够接地气，我因地制宜改成了：背景（Situation）、痛点（Complication）、目标（Objective）、方案（Answer）。

这样的模型更契合产品经理日常工作的需要，特别是在写需求的时候特别好用，能够清晰地说明我们做需求的背景、用户的痛点，以及我们要做这个需求的目标是什么，基于这个目标我们要准备什么样的方案来解决。

我们在驱动团队小伙伴做一件事情的时候，一定要把为什么要做这件事情同步到位，大家互相认可做这件事情、知道这件事情的目的的时候，才能激发团队的思考和源动力，围绕目标把事情做得更好。否则很容易出现大家按部就班，没有基于用户角度去深入思考整体的用户体验和匹配的实现方式，导致结果变形或品质一般。

3、项目复盘、问题分析的时候：STAR 模型。

即情境（Situation）、任务（Task）、行动（Action）、结果（Result）。

这也是比较常见的模型了，在做复盘、分析的时候，结果可能只是一些数字的呈现，但我们需要还原过程，回溯采取的动作。这些一定是要基于具体的某个情境下，某个任务做出的分析和回顾；才能知道哪些动作带来了正面的作用，哪些带来了负面的影响。

四、小结

总体来说，我们需要不断强化结构化思考的习惯，在不同场景下采用更合适的高效表达方式，才能逐步地去提升我们的逻辑能力。逻辑能力作为一个非常基础又极其重要的能力，希望大家在本文之后，能够有所收获，在日常生活、工作中都能有所运用和锻炼提升。

有一个词叫做“刻意练习”，很多能力都是需要通过刻意地重复才能练出来。“无他，惟手熟尔！”加油！