由于最近的分享，对自己对产品思维的认知做了一个梳理，虽然未见得是最正确的，但是对自己而言却是让自己的产品世界更加体系化。常常在看某本书时，激情澎湃、思如泉涌，当合上书没有及时记录下来后，就会慢慢的淡忘。有人说最好的的学习就是教别人学习，我深以为然，想教导别人必定需要比别人更了解这个体系的内容，梳理-补充-再梳理的过程，不断的加深对于知识的印象。毕竟是要给别人讲课，不够深入和有特点的内容，不好意思拿出来见人。
我的职场生涯中遇到过各类的产品经理，总结下来大概有三种：
第一类是坚持一个产品领域多年的，这类人精通某一个业务场景的模式，能够深入了解业务和市场，他们的领域门槛相对较高，想跨入这些领域需要相当的专业知识。尤其是到了高级别，不但需要了解产品和业务，还需要见识和经历过大型成功组织的专业系统建设，深入理解公司该专业的管理思想和市场知识，并且有相当丰富的理论知识，换句话说对于此类人给一个该专业的总监职位，也能保持良好的运作。当然有了思想价值就会提升，年薪百万起步对该类人才来说并不遥远。
另一类产品则是从初出校门开始，就在各类的产品中游荡，比较形象的说法就是一颗螺丝钉，哪里需要哪里拧。此类的产品经过多年后大多是形成一套产品逻辑和方法，看似什么都能做，往往又不具备压倒性的优势。在工作的经历中，面试过很多这类的产品经理，问到如何才能做一个好的产品时，得到的回答往往是千篇一律的，了解用户核心需求、增强用户体验、梳理整体流程等等，答案基本上都是百度可以搜索到的，甚至某些应聘者连这些也说不太清。有一次面试一个产品经理，当我问到怎么才能做好一个产品时，他开始向我发问“什么类型的产品、最终用户是谁、打算实现的资源有多少……”，当这些问题问到一半时，这个应聘者已经通过了我的面试，如果没有对业务深层次积淀，那么就把产品的方法融入血液，这样的产品才是一个合格的产品。
还有一类人看似并没有特别的产品方法和套路，却能够做一款在市场中大杀四方的爆品。他们也许就是上天眷顾的宠儿，往往能在最合适的时间做出最正确的事情，而这类人不在我的讨论范围内，因为我也不懂。
除了上面提到的分类，说到产品技能，我觉得也是分层次的，以下会详细聊一聊产品技能的层次。
对于产品经理这个岗位来说，市场的区分度很大，一个刚毕业的产品人员可以被叫做产品经理，一个产品导向的CEO也能叫做产品经理，于是便有了《人人都是产品经理》这类的书。
而我认为产品岗位的跨度是有层次划分的，人人都是产品经理这类的话误导了很多想要入行的新人，同时也造成了产品经理岗位的参差不齐，面试识别难度比较高等问题。借用梁宁的话，按照宏观、中观、微观三个层次定义产品人，那么我眼中对应这三个层次的岗位则是产品设计师、产品Owner、产品总监orCEO。
很多人在说到微观、中观和宏观的时候，都是把微观比做基础的、执行层面的，但是我觉得梁宁的分层更具有科学精神，就像物理科学一样，我们认识和了解世界，首先通过眼睛、耳朵去感受和验证，这个阶段就是中观的世界，采用观察的方法就得到很多信息，经典物理学就是这样，而宏观和微观就像对应着天体物理学和量子力学一样，一个研究极大，一个研究极小，都是更加困难的，也是探索物质世界根本的学问。所以我十分赞同梁宁的观点，那些容易观测到和学习到的产品套路，都是产品的中观，而宏观和微观很难描述也很难去模仿。
1、产品的中观
在这个阶段产品的主要能力都是套路，也就是说都是可以从别人那学习过来的，借鉴也好，抄袭也罢，这个层次也就是人们普遍认为的产品经理——人人都是产品经理。这些产品往往对各种产品方法有各种了解，根据掌握的方法多少和深度不同，等级也不尽相同，以下聊一聊产品的一些套路方法：
1）MECE分析法
MECE的核心就是相互杜立、无限穷尽、不重复、不遗漏，在产品的创意阶段或初始需求阶段较为常用。
首先大量的收集用户需求，注意是收集而不是引导，这个阶段往往有表现欲的产品经理，会引导用户的思维，从而得到自己想得到的需求调研结果，往往失真的需求在交付用户之后才会表现出问题，造成时间和资源的损失；其次需要针对基础需求进行各种场景的罗列，这个时候往往采用头脑风暴的方式会取得更好的效果，最终形成很多个业务场景和功能；第三阶段，寻找目标用户进行业务场景演示，不合适或不正确的就删掉，保留下最核心的场景需求，这个阶段有些目标用户会尝试帮助产品经理设计功能，需要注意了解目标用户这样做的潜在动机和需求，而不是去接受用户的设计或跟用户进行辩论。最后在仅剩的几个核心需求上，设计出基于核心需求的业务场景。
2）溯源（第一性原理思维）
第一性原理本是量子力学计算的专有名词，因为马斯克而火遍互联网，马斯克告诉大家他成功的秘密就是使用了第一性原理思维：“打破一切知识的藩篱，回归到事物本源去思考基础性的问题，在不参照经验或其它的情况下，从物质/世界的最本源出发思考事物/系统。”其实说起并没有什么神秘的，就是产品中所谓的溯源，只不过被神话的人包装上神秘的名词，立刻变得高大上起来。
虽然说溯源并没有什么神秘的理念，但是真正能够使用这一个概念的产品经理却是不多。我见过很多产品经理在做一款产品时，首先找个标杆，然后找市场同类产品进行分析，最终的结果就是将其他的竞品拆开了再重新组装一遍而已。产品的溯源的核心就是找出最基础的核心需求，但什么才是产品的最基础的核心需求呢，如果只是从产品去寻找，最终也只是浪费时间和经历。我认为所有的产品溯源都离不开人，产品所面对的终将是人，了解人性和最终用户的群体特征是溯源的第一步，假设把产品舍去，将产品的最终结果呈现在用户面前，用户是否为之所动。利用第一性原理思维来说，就是将产品呈现给用户的结果拆成最基础单元，然后寻找用户想要什么？为什么想要？用户的基本需求和提供的最终结果之间的最短路径是什么？比如有一个用户买了打气筒，用户想用打气筒干什么？为了给自行车胎打气。用户多久会给自行车车胎打一次气？大概半个月一次。给自行车打气是用户想要的吗？不是。那么自行车怎么样才能不打气？实心胎。实心胎舒服吗？不舒服。轮胎为什么要打气？因为减震。利用其他方式可以达到减震的目的吗？可以……这就把需求逐步挖掘到基础核心需求上，然后需要考虑的问题并不是做一个更好用的打气筒，而是做一个不用打气也能减震的轮胎，继续往下就可以去想怎么做一个成本比打气轮胎更低成本的减震轮胎，从而进行一种颠覆式创新思维里，甚至会考虑可不可以不用轮胎的问题，就是利用第一性原理思维的产品推导模式。
3）用户体验设计
自从苹果手机的出现，用户体验这个词就开始风靡产品圈，让我感觉到差异的是，为什么之前我们做产品和项目都没有这么注重过用户体验？也许我们那代人不太需要用户体验（有的用就不错了，还有啥资格挑三挑四）。就事论事，乔大爷的思想确实改变了世界，甚至说改变了一个时代，当我拿到第一台苹果手机的时候，居然没有产品说明书，更新奇的是虽然没有产品说明书，但我居然会用他，已经形成的习惯这一刻轰然崩塌。像我一样在十几年前做项目或是产品的人，还清晰的记得每个产品都有一大本厚厚的说明书，甚至有的产品还要配上视频或现场培训。
而现在时代进步了，如果你的产品需要一大本说明书才能上手，那么基本离被淘汰不远了。想也正常，时代在发展，比如以前的美工不能叫美工了，需要叫设计师，不然小姐姐会生气。而产品的分工也越来越细，产品和UI之间又增加了一个UE的岗位，这个岗位就是专注用户体验设计的。
说到用户体验设计，我十分推荐梁宁老师的用户体验地图设计思路，在做一个产品时，需要找一个核心用户，将他使用产品的完整场景，需要注意的是完整的场景，而不是使用产品的场景，这是很多产品经理都会犯的错误。应该从用户的整体场景考虑，产品功能只是用户整体场景中的接触点，例如一个时间管理的产品，需要考虑用户一个时间周期内的场景，当用户早上起床收拾完成后，通过产品查看一天的事件安排，这是用户周期内第一次接触产品，产品经理需要考虑这种场景时需要为用户提供什么样的服务，到了公司进行一天工作安排，这时是第二次接触产品，需要考虑这种场景需要为用户提供什么服务，当会议要开始前15分钟，产品需要怎么提醒用户……直到一个完整周期结束。产品就要把这个周期看做一张地图，用户的行为就是地图的路径，用户使用产品就是路径的关键点，以此再结合用户此时的场景来设计产品功能，就会更加贴近或者超越用户的诉求。
4）流程分析
说到流程估计时每个产品经理的必修课，笼统的说任何一个B端业务系统本质就是新增、修改、删除和流程，各种功能都是基于这些基础上衍生出来的，所以流程对于B端系统来说是非常重要的。以前与IBM合作项目时发现他们使用的方法非常好，以下就简称为“四级流程分析法”，IBM经常承接大型的IT系统总包的角色，对于大型企业内部的系统来说，整体建设相对比较复杂，所以IBM使用四级流程分析法逐级细化，使规划与实施不会产生大的偏差。
第一级，系统级：他们把每一个系统看作一个流程节点，从企业宏观管理的角度出发，根据信息的流向进行第一级流程的规划，专注系统级信息的输入和输出，比如在一级流程中有个生产流程，会以订单系统作为一个起始点，订单系统产生订单后进入生产系统，生产系统分析订单后产生原材料信息传递给采购系统，采购系统接受原材料采购申请进行采购，然后将采购单发给物流系统，原材料进行运输后，物流系统将原材料信息发送给库存系统……根据企业业务的不同，可能会有多条一级流程，一级流程的规划是进行企业信息化蓝图规划的基础，保证每个系统都能在企业运作的链条中进行价值的传递。
第二级，模块级：并不是所有产品都能接触到企业整体的信息化战略规划，但是基本都会涉及系统的产品设计，所以第二级流程设计对于产品岗来说更加的重要。在接触到一个从0到1的系统时，首先需要考虑到业务数据的信息生命周期，这是系统模块划分最简单、最可行的方式，比如一个费控系统，从头到尾的数据生命周期就是“预算数据->费用数据->报销数据->合同数据->付款数据->账务数据”这几个数据生命周期进行大体的模块划分。在本级的产品设计中，应该着重考虑数据在周期间的流通和调转是怎么样的，每个模块数据输入和输出是什么？是否有前置因素？是否对后续数据产生影响？……在这个层级将业务、数据、模块梳理清楚，基本上系统大的架构就已经定下来了，保证后续的工作不会跑偏。
第三级，功能级：这个时候我们需要关注业务数据在一个生命周期内的变动了，例如拿报销来举个例子，一般的报销的前置流程数据是【费用申请数据】和【借款数据】，所以在报销申请时需要与这两个数据进行关联，然后再看报销的基本流程：“报销申请->报销审核->报销票据->费用支付”，基本上我们就能确定子模块和功能有哪些了，从子模块的角度考虑，由于不同的用户进行不同的操作，报销申请和报销审核应该是两个不同的模块，报销票据需要在报销审核完成后粘贴，对于一般用户来说在报销申请的单据状态变为“已审核”后，就能够在报销申请上打印报销单粘贴票据，当报销票据从线下流转到财务手中的时候，需要财务将线下票据与线上数据对应，那么需要在票据审核的子模块中增加票据核对的功能，完成票据核对后，数据就流向“费用支付”的阶段。当然这只是最简单的场景和设计，在实际情况中我们需要考虑到更多的场景和因素，比如电子发票、借款报销等等，但是这些都是基于我们之前总结的基本流程来扩展的，保证基本流程的正确性，扩展功能也不会跑偏。
第四级，状态级：这个层级一般是和功能级在一起进行考虑的，比如我们之前举的例子，在报销审核这个功能中，需要做的事情是一样的，所以提供的功能是一致的，但是根据业务规则，进行审批的用户是不一致的，对于系统来说只是报销数据的状态变更了，所以这一级就叫做状态级。但是状态级可能又不是单独的状态变更，它可能会随着状态的变化而向用户提供不同的功能，继续拿报销来举例：当报销进入到审核阶段，需要经过不同的审核人后才能完成审核，这其中包括业务用户，也包括一些专业用户，例如业务要求采用审核节点需要将报销费用划分到不同财务科目下，这时候我们就需要在“财务审核”这个状态下提供划分科目的功能。功能级与状态级联系紧密，但是对于系统设计来说，分开的展示更容易看清设计思路，功能级我们可以用树形图、逻辑图来展示，流程级我们可以用流程图、泳道图等方法来展示，总而言之就是为了让业务用户、领导和开发人员看懂你的产品设计。
5）PDCA持续改善
PDCA是一个很多场景都会套用的概念，其核心就是计划、执行、检查、校准，完成后再从计划开始，形成一个闭环。有时候面试时我就会问面试者，怎么理解项目经理和产品经理的区别？作为项目经理是为一件事负责，有清晰的开始和结束，需要保证的是在规定时间内合理的利用资源推进项目达成目标，当达成目标的那一刻项目经理的职责就完成了。而产品经理不同，同样的场景当打到了预订的目标时，对于产品经理来说真正的工作才刚开始，产品经理是对产品这个东西负责，需要不断的对产品进行优化提成，以保证产品在市场中所具有的竞争力。
PDCA就是一个简单、清晰的执行方法，是保证产品迭代优化的很重要的方法，在这之中检查和校准更为重要，很多人在完成了一个功能迭代后马上进入下一个功能迭代，不对迭代功能进行检查和校准，从而产生很多问题。我们之前说过产品经理是为产品这个物负责的，那么每一个迭代都应该达到它的目的，通过检查和校准保证迭代功能贯彻最初目标，同时也是保证产品质量的重要手段。
产品的套路方法还有很多，以上只是按照顺序从选择需求（MECE分析法）、确定需求（溯源）、产品设计（用户体验设计和流程分析）、产品迭代（PDCA持续改善）描述的一套方法论，这些套路可以单独使用也可以组合使用，当完全掌握了这些套路之后，就成为了一个合格的产品经理，但仅仅是合格，依靠产品中观的方法和套路，很难变成给一个产品高手。
-----未完待续