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