做了3年产品经理，关于如何做产品，已经开始慢慢构建起知识框架。按照《Learn How to Learn》中提到的概念，处理产品问题的方法已经在我大脑中产生了回路，当问题来临时，它会自己按照已产生的回路进行运转，最终得出解决方案。那么就写一篇文章，说明一下自己大脑中的回路。
知乎上有句名言，一切不问是不是就先问为什么的行为都是耍流氓。同样当一个需求来临时，不判断真伪，而直接提出解决方案，也是在耍流氓。工作中，这种耍流氓的行为很频繁。
我的解决方案是，多问为什么，找到核心问题。举个我实际遇到的例子，运营提出一个需求，我需要在给用户的短信里，加上客服的微信号。如果不加思考，很多人就直接去做了。可如果多问几个为什么，就能发现不一样的情况：
运营："我们要在短信里加上客服的微信号。"
产品：“为什么要加微信号？”
运营：“因为需要与用户建立联系。”
产品：“为什么要建立联系。”
运营：“因为有些用户反应，不会用XX功能，加上微信，我就能告诉他怎么操作。”
只问2个为什么，就会发现，核心问题是用户不会用这个功能。一旦找到了核心问题，那么思路就会开阔很多，能想到很多解决方案。加微信是一个方法，但这个方法很低效，而且也很浪费人力成本，肯定不能采纳。
找核心问题，适合解决由用户、老板或同事提出来的小需求、小任务，多问为什么，从而达到去伪存真，找到真实需求的效果。而当提出一个大的需求时，需要当作一个项目来对待时，则需要用另外的思考方法，我常用的思考模型是借鉴《用户体验要素》中提出的互联网产品的5个层次。
书中将产品分为5个层次：战略层、范围层、结构层、框架层、表现层。表现层主要是设计师来负责，所以我常用前4个层次来思考、分解。
1.战略层
战略层上，需要同时思考两个问题：产品目标和用户需求。即我们要通过这个产品得到什么，我们的用户要通过这个产品得到什么。
作为一家商业公司，公司做任何事情，都有其目的。当老板吩咐要做一个项目时，首先就要思考，公司需要从这个项目中获得什么收益。这个收益是一个广泛的概念，可以是直接的利润，也可以是与利润相关的因素，例如降低人工成本，增加流程转化率、提高付费率等。
与此同时，在最开始的时候，我们就需要考虑用户需求，即开发这个项目能够帮助用户解决哪些问题、疼点。
理想情况下，产品目标和用户需求是完美融合的，但现实情况是两者偶尔会发生冲突，这时候就需要去考虑如何最大程度地消除两者带来的冲突。
2.范围层
进入范围层，需要考虑，为了实现产品目标和用户需求，我们需要实现那些功能，也就是所谓的做什么与不做什么。
我一般使用思维导图，将与之相关的所有功能点、需求点都罗列出来，依据我们上一层次中分析出来的产品目标和用户需求，将各个点划分优先级，所有优先级为P1的功能集合即是这个产品的MVP模型。依据MVP模型，确定后续的开发内容。产出这张思维导图后，我会与老板沟通，确定范围是否有遗漏，以及优先级划分是否合理。
3.结构层
前两个层次，我们解决了为什么要做以及做什么的问题。在结构层，我们开始处理具体的产品策划了。在移动端，大部分功能都是为了让用户实现某一个具体的目标，例如，支付模块就是为了让用户完成支付。所以在这一层次，我使用流程图的方式来说明用户从开始到实现目标的整个流程。
这样做的好处是能够清楚得看到用户完成目标所需要的步骤，进而可以思考如何优化这些步骤。并且在最终上线时，我们可以通过监测点监测到这些步骤间的转化率，从而发现问题并进行优化。
4.框架层
这一层次也就是原型阶段，产出的内容是原型文档。在我们的团队，为了优化产品经理的产出效率，产品团队不出PRD文档，那么原型成了唯一说明页面细节地方，所以我们的原型会有大量的标注来对各个位置进行解释。
虽然做产品的最初阶段，我就在画原型，但因为不是设计的知识积累不够，所以并不太擅长这部分。我采用的原则就2点，强调重点信息，简化所有可以简化的信息。
以上就是我在处理需求时，所采用的思考模型。由于视野、经历有限，还存在大量“我不知道我不知道”的内容，再接下来的时间里，我也会在工作中继续完善我的产品知识框架。