最近要开始春招了，想要投入到产品经理这个岗位中，除了日常的实习工作经验，还要经常阅读一些经典书籍，结合运用到实际工作中，所以就把自己读到的一些书籍总结一下，顺带总结一下自己的工作经验。
《金字塔原理》作为产品必读书目之一，全书分为四个部分，每个部分我都尽量总结一下自己相应的工作体会。
第一部分：表达
1.通过自己的思维结构把相似或者关联较为紧密的概念进行归类、概括、分层级，方便你的观点被受众理解记忆
我思考问题的时候经常会以自下而上的结构，去形成思维逻辑，这没什么问题，但是到了去把自己的想法去告诉别人的时候，如果自下而上的表达，别人往往会摸不着头脑，例如需求评审的时候，可以一开始就去说出自己的需求（主体要做什么）用一种自上而下 的方式去表述，（因为我做的是金融后台产品）然后细分到各个系统中会有什么样的变化，因为各个系统的变化都是响应了需求主体而需要作出的改变。而在同一层级的表述中，往往各个部分不是独立的，可以用某个维度去串讲，例如APP接入了一家新的支付渠道，在各个系统这一层级，那么从订单的生命周期去串讲（不考虑异常流程）：1.首先，用户的订单会进入风控系统去进行审核，这个过程中基本不涉及支付渠道，2。那么接下来进入信审系统，新的支付渠道意味着新的放款和还款方式，那么他们会在用户的相关支付方式模块中显示，模块的详细改动又可以详细深挖，这个地方如果不太复杂那么直接讲述细节改动就好，没有必要直接跳到其他系统，3.接下来订单进入了订单系统（放款阶段），这个时候意味着给用户放款的时候多了一条支付路由的途径，这个时候相关的改动无非就是路由的选择增加和相关筛选项字段 的取值增加，，4.然后到了用户还款的时候，用户的相应还款方式多了一种，渠道还款流程中的相关改动不做赘述，用户如果按时还款，订单就进入了终结，5.用户假设到期前没有结清，那么到时候又涉及到催收系统，相关用户的放款，还款记录中的渠道可能会涉及这部分，还有相关还款方式信息可能涉及。
我的理解是表述的过程中，随着层级的越来越深入, 同级节点之间的联系是越来越偏向差异化和孤立性的，所以从上往下第二、三级的时候，可能之间有关系，但是整体比较复杂的逻辑结构时，在往下深入就可以先沿着一条路径深挖细讲了，没必要再强行关联了。另外不是所有的需求都适合用金字塔的结构讲述，例如一些的独立场景导致的的单一性强需求（场景少但是必须做，例如合规需求），就需要点对点的简洁明了的推出结论，这类需求很少有层级概念。
2.向RD，QA讲述需求以及方案的时候，大致是：背景、痛点（需求点）、目标、解决方案流程
书中讲述的是叙事模式是：背景、冲突、疑问、回答，将这个模式应用到实际的需求评审时，我采用的是背景、痛点、目标、解决方案的方式。
背景：具体业务过程中发生了什么事情（谁，怎么发生的，因为什么，在何种情况下发生 的）
痛点：剖析整个背景中事件发生的根本原因（这个我自己一开始也不好，全靠我的好师傅指导），原因的剖析正确决定着需求的整体方向，以及方案的解决效果，所以这一步我认为是最重要的
目标：剖析完原因之后，和叙事模式中不一样的是这部分换成了目标，因为评审的时候其实你已经对于解决了整个过程中的疑问点，所以这个时候一般是讲述要大体做什么，做成什么样（什么效果），然后进入下一步
解决方案：这个时候也是很重要的一步，首先自己要对自己解决方案的整体逻辑清楚，并且能够使用一定的技巧和沟通表达能力去说明自己的解决方法，（尽量结构化，流程化的去讲述方案）
我有一个深刻的体会就是，我刚开始擅长的是解决问题而不是发掘核心问题（后来在另一本书人人都是产品经理中发现，这就是典型的学生思维哈哈）
3.把自己的想法结构化组织有两种，自上而下，自下而上
自上而下：先说结论，然后整理表述论证过程，我自己一般用在说解决方案的时候，先要做个没事功能，然后具体怎么做blabla~
自下而上：一般和自己的思维过程一样，先列举出发点，然后说明结论，有点像需求澄清的过程，先说业务发生了写什么，然后得出结论（痛点，问题核心）
所以我评审的时候一般是两种方式结合~
4.演绎推理和归纳推理比较简单，
归纳一般是陈列多个点来得出更高一级的点，例如平时经常会有评审的时候开发或者QA觉得这个需求没什么必要，但是站在自己的角度和产品业务的角度来说有必要，你就要利用一大堆数据和相关实例来说明这个需求有必要推下去。
演绎有点像数学里的等量代换，一层叠一层，1.产生什么问题；2，问题的原因；3，所以应该这么做。
对应着需求的发掘过程，背景是有什么问题，痛点是问题产生的恩本原因，目标是该这么做，方案是对目标具体实现形式的细化（个人理解）
网友评论