作为产品经理，核心素养之一是具有逻辑思维和结构化思维能力。逻辑思维和结构化思维可以帮助我们输出高效、高严谨性、场景覆盖面更广的需求。这种思维方式是能够被刻意练习并获得正反馈的，能够在工作中广泛应用。具备逻辑思维和结构化思维能力有利于提高个人影响力以及在工作中的沟通表达效率，而缺少这种能力将导致信息传递不畅、浪费他人时间、影响说服力等问题。因此，作者认为应该养成早期意识，刻意培养自己，形成核心竞争力。
作为产品经理，我们经常会面临逻辑思维的探讨。
产品经理输出的每个需求，需要站得住脚的前提就是逻辑是否能站得住脚，能否符合产品思维，商业逻辑闭环，这对于任何一个产品经理来讲都是很基本的素养。
而我们本章节，是给大家介绍，我们怎么用结构化的思维让我们输出的需求更高效，更严谨，考虑的场景覆盖面更多。
逻辑思维和结构化思维核心影响你与他人的关系，影响信息传递效率，影响你的个人影响力，是非常显性化的两种思维方式，是其他思维方式的基础。
显性化是你只要刻意练习，你便能习得这项能力，并且很快在工作中应用得到正反馈，提高你的工作效率、加强你的沟通表达能力。
思考和表达没有逻辑与结构，是种灾难。核心不是让自己怎样，而是非常浪费别人的时间。
大家的时间都很宝贵，你浪费了别人的时间，别人怎么还会有耐心信任你。尤其是对领导，你应该常常想几分钟内还没把事情讲清楚，他就没了耐心。同事之间沟通也如此，你讲了几分钟，对方还听不懂，那么他下次就不再想跟你沟通。
同样一件事情，能有逻辑地结构化思考和表达，可以节省双方更多时间，提高效率。
逻辑与结构化思维可以让接受信息的人快速明白你要讲什么，也可以把你想表达的重点传递给到对方，它让我们在沟通交流中提高自身说服力。
产品经理首要学习这两种思维方式，逻辑思维提高自身说服力，结构化思维提高信息传递效率。
越早期越有这种意识，刻意培养自己，越能较早形成自己的核心竞争力。
对于产品经理来讲，一个新入职的产品经理留下第一印象的方式就在于对需求的管理和编写，是否一针见血至于能够让需求罗列井井有条。
而一个产品经理的等级往往也是通过需求池的管理可以体现出来，本人认为需求池的管理是有下限的，但天花板并没有。
如果让你的需求清晰易懂，一目了然，追踪溯源，通过需求池管理完成版本记录，用户故事的编写等等，都是给业务方和开发人员大大提升信任度的手段。
通过结构化思维可以对产品的工作流进行科学的梳理，提高需求池的协同效率之余，也方便查找和记录每个需求的版本，方便新老交接。
分享本人在手机维修行业的一个利用SWOT分析法进行产品需求模型打造的一个案例。具体得出的结论和策略就不方便和各位透露，只是通过方法简单罗列一下各维度的关键点，至于如何使用方法其实都是很灵活的，仅供参考。
以下是给读者参考的手机维修行业需求模型案例：
四象限法则是时间管理理论的一个重要观念是应有重点地把主要的精力和时间集中地放在处理那些重要但不紧急的工作上，这样可以做到未雨绸缪，防患于未然。
往往大家都过于局限在所谓的重要，不重要，紧急，不紧急当中。
SWOT分析法已经提到过，方法是给人用的，一定是相对灵活才有实用性。四象限法则更是如此，接下来我给大家分享一下我是如何使用的。
以下是提供给读者参考的四象限方法的使用方式：
优先解决大用户量的高频问题，特别是在产品早期，一定要先解决用户量大且经常发生的，提升基础体验，增加产品的稳定性。最后解决少量用户的低频问题。
此处我定义的四象限为用户频率高，低；功能满足度高，低。
通过第一点得出的需求，又可以结合通过开发时间和四象限中最重要且紧急的为优先开发见效快且开发难度不大的，这就是迭代，最后做很费劲而且见效慢的，这可能是未来的机会。
此处我定义的四象限为见效快，慢，开发量大，小。
同理可得，通过这样的方式，我们就可以很好的完成对优先级的排序。
需求池遵循DEEP规范，通过敏捷管理的方式对需求池管理，能够有效的保证项目通过最小版本增量迭代的方式进行产品设计；有利于快速迭代、快速响应以及快速调整，通过DEEP规范编写每个需求的用户故事即通过一段话体现出该需求的商业价值。
以下是提供给读者参考的敏捷管理的使用方法：
1）敏捷管理的核心是尽早且频繁地交付小批量的可工作的产品；根据（一）得到的新变化和信息，对产品进行恰当的调整。
我们使用敏捷管理的方式最直接就是摒弃人天和周期的概念，以工时去管理团队人员的人效。
也因为要用工时计算，就自然而然的会把一个功能模块拆解多个版本的需求进行快速的增量迭代。
许多自称敏捷的组织，他们提前计划了大量功能列表——通常提前一整年，并告诉团队要以小批量的方式交付。
这不是敏捷，这是增量瀑布。
2）敏捷开发的核心特征是小批量地交付可工作的产品，从早期迭代中获得洞察力，并在后续迭代中进一步完善和优化相同的功能。
其中的关键在于我们无法预知和确定什么是可行的，什么是行不通的，这需要洞察和跟踪数据。
打造一款优秀的产品，我们要一边走，一边制定计划。这与一年长的甘特图完全不同。
「Now-Next-Later」只有与团队自主权相结合时才有意义。这样才能使团队发现计划的调整空间，及时做出应对。
想要灵活地工作，在做计划时要注意建立高度灵活的路线图、留出充足的弹性空间用于响应调整，以及获得领导层的积极支持。
利用好这三点，就可以持续地引导项目，而不是在前期就将它固定下来。这就是敏捷真正的意义所在。
而我们在每个需求都需要进行一个简单的用户故事描述，即：谁要用一个怎么样的功能达到怎么样的目的或价值。
3.1.1 通过用户反馈关注什么？
3.1.2 通过哪些渠道来收集用户反馈？
公开渠道：App store 、新浪微博、百度贴吧、七麦、酷传网、雪球等。
半公开渠道：朋友圈、微信公众号的文章、微信群、用户评价。ps:如果想获取竞品的可以成为种子用户或者是付费用户。大家可以结合自己的产品性质，去不同的地方搜集哈。
内部渠道：用户投诉、电话录音、客服咨询。别人家的咱们获取不到的哈，如果能获取到那也是犯法的，这种事儿咱不能干。
3.1.３ 用户反馈不同渠道的处理策略？
总之，去用户量最集中的地方, 定期的去收集用户反馈，会让你的工作事半功倍。
3.2.1 用户角度
俞军老师的用户价值理论很适用于 C 端产品：
用户体验 = 新体验 – 旧体验 – 替换成本
用户价值理论只是提供了决策的思路，提升个人预测的准确性和决策的质量。
在 B 端战略性需求的规划，大方向上还需要考虑：
这三条可以作为 B 端产品设计的原则。
大多数产品不是死于需求做的太少，而是做的太多，超出了产品的边界越做越臃肿，迭代困难。
需求的规划需要从产品的定位着手，打造自己的核心卖点，服务于业务的北极星指标。也需要通过标准化设计摊平研发成本，低成本服务更多的用户。
3.2.2 产品角度
这些问题是在进行需求评估和规划时需要考虑的重要方面。通过综合考虑这些因素，可以确保需求的合理性、可行性和符合平台的要求。
当我们在做真伪需求的判断的时候，要围绕以下三点进行考虑
通过结构化思维进行团队管理，知人善用，让大家都参与进来。
我认为需求池管理从来都不是master一个人的责任。
需求池的目的是让团队的产品经理能够高效的完成协同工作，信息透明，清楚各自的工作以及相互穿插的工作对应的关联关系，同步清楚组内成员各自项目的迭代计划，产品生命周期等。有利于团队互相借鉴，沟通交流，形成良性的竞争关系。
而在我的团队，一般都会给团队成员各自负责一个板块进行主导，培养各自产品owner的意识之余还可以让团队成员都有机会熟悉其他项目，方便接手。
需求池的拆解 – master
需求估时合理性评估 – 高级产品经理
需求池的需求是否具备产品迭代计划 – 成员1
需求池的需求评审记录 – 产品助理/产品专员
需求评审会后意见反馈文档编写以及收集 – 初级产品经理
需求池需求梳理 – 成员2
项目迭代进度跟进 – 成员1
BUG池管理 – 成员1
合理的时间能够提高评审会的效率。每日站会汇总，周会复盘，周一内审会，周四技术评审会。
以下是一种可以结构化报告进展的方式，涵盖了研发、测试、产品、设计和个人任务的进展情况：
研发任务进展：
测试任务进展：
产品任务进展：
设计任务进展：
个人任务进展：
请注意，这只是一种报告进展的结构示例，具体的内容和格式可以根据团队或组织的需要进行调整和定制。
确保报告中的信息简明扼要、准确清晰，并提供必要的上下文和关键指标。这样可以使读者更好地了解各项任务的进展情况，并采取适当的行动。
细心的朋友可能会发现，我们团队针对这四会，都会有5个重点要求，无论做什么都会有目的，都需要有结果。作为产品经理更是如此，对于需求池的管理从来都不会只是纸上谈兵，更重要的是注重效果。
通过5个工作要点来保证每个会议的质量，减少沟通成本之余也能让我们在会议的时候有方向和充足的准备。
产品经理需要具备两个能力，我们以往都在听行外行内的人在讲逻辑思维，但是我们要清楚，能力是需要用在正确的地方。逻辑思维放在需求池管理里面，往往就会搞得很臃肿。
逻辑思维的用处就是在产品设计周密度以及需求文档编写的条理性体现出来，而本章节更注重产品的结构化思维能力。
结构化思维是一种从整体到局部、从框架到细节的思维方式。它要求思考者不先入为主，不会过快地陷入细节，而要经常留意事物的整体框架，在框架的基础上去拓展细节。
因为人和人之间信息差，结构的越上层，彼此之间信息差越小；结构的越下层，彼此之间信息差越大。
如果一上来陷入到最下层的细节之中，对于需求池的管理是非常麻烦的，而且大家的信息获取成本就会很大。
因此，产品经理需要不断锻炼结构化思维，不断的进行归纳和总结，养成做任何事都进行阶段性总结和复盘的习惯是训练结构化思维的核心。
思维如果懒惰任何种方法技能也无济于事。
本文由@乐少有话说 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。