最近做了一些需求，做需求的过程中遇到了一些问题，而最主要的问题在于产品逻辑，于是乎被老大安排推荐一本书《简单逻辑学》，目前有时间就会抽空看一些内容，今天只是想总结一下最近的一些内容，产品经理最重要的核心竞争力其实是产品的思维逻辑，而思维逻辑的培养在于深度思考，比如接到一个需求应该怎么分析，分析哪些内容等等，这些都需要思考，深度思考的能力对于每个人而言都是十分重要的，无论你的工作岗位是什么。
最初接触需求的时候，我往往会忽略思考或者分析，作为执行者，拿到需求就做，不考虑任何因素，慢慢地我感觉自己变成了一个执行的机器人，没有思想和灵魂，一段时间后，我发现这种状态毫无意思，没有什么意义，而且最关键的是在需求评审过程中，因为自己没有深度思考或者说事前剖析很多场景，很多方面压根没考虑清楚，在开会过程中，被技术疯狂DISS，最终导致整个需求进度延后。
后来我进行复盘总结，分析导致这种结果的根本原因-缺乏深度思考的主动性，
当我们手头上有好几个功能，需要判断优先级时，我们首先要做的第一件事就是思考：
该功能给用户带来了哪些价值？
功能的背后要解决的真实问题是什么？
用户期望是怎样的？符合产品的战略目标吗？
有没有其他紧急重要的问题亟待解决？
只有符合用户期望和产品目标的需求才是值得做的，才是当前需要做的。
当我们确定好了某个功能时，我们其次要做的就是事前剖析，分析思考很多种可能性：
这个功能成功后的场景是什么？出错的场景有哪些？有没有对应出错情景的解决办法？
有没有其他风险？是否会影响其他功能？
当影响其他功能时能否迅速响应立即处理？
有哪些人会用到这个功能？是否要区分不同用户属性显示不同内容？
是否要专门设置后台进行管理？等等尽可能延申一些场景进行分析，并且在写好需求文档之后进行逻辑梳理，自己要完全在脑海里演练一遍实际场景，尽可能站在用户角度模拟场景，必要的时候，可以通过思维导图和流程图辅助梳理整体逻辑，以便及时发现不足之处从而改进。
当我们确定好最终内容之后（需要仔细检查自身文档有无逻辑问题或者描述不够精简）才开始召开需求评审会:
在会议上向技术人员介绍时，我们首先应该阐述此次需求目的以及解决的问题或者说想要带来的价值，其次才是我们的文档内容，我们在做每个功能时，必须要明确功能的价值，在开会过程中，尽可能表达流畅，思维严谨，争取第一次开完需求会之后就可以让技术人员给开发周期，保证功能尽快落地。
当我们将某功能上线之后，我们需要对某功能进行结果验证:
通过用户反馈或者埋点的相关数据去分析此功能带来的价值，若该功能未能到达预期，则需要针对性分析出问题的是哪个环节，从而进一步优化迭代。
无法量化的工作是无意义的，凭感觉行事是不长久的。优秀的产品经理对于自己要做的功能，有着明确的结果预期。做产品的过程就是不断的验证自身想法的过程，而对结果的预估就是很重要的能力。
今日复盘结束，我们下期再会，嘻嘻，欢迎大家在下方留言提建议~~~
网友评论