最近读了网易云音乐的产品负责人王诗沐的《幕后产品 - 打造突破式产品思维》，这是一本来自互联网一线产品经理背景的书，很接地气。书中既有框架性的方法论，也有实际的案例。而且各种案例都直接是网易云音乐或者市场上的相关产品，让人很有实际上手的感觉。
不过我并不打算把诗沐的内容都复述一遍，分享一些我自己的感悟吧。
程序员视角 vs 产品经理视角
《幕后产品》书中提到大众点评的外卖入口，有两个入口，一个是首页的一级入口，另一个是首页的美食下面的二级入口。从逻辑上说，一个一级入口同时又是另一个一级入口的二级入口，显然是有点逻辑矛盾的。但是作者认为：这可以照顾两类用户的习惯，在产品慢慢影响用户习惯的过程中，我们不需要为产品做出完美的逻辑（第 7 章 第 1 节）。
我非常赞同诗沐的观点，这个观点在产品经理圈可能是常识，但在技术圈可能是异类。
曾经有一个技术同事私下向我抱怨：我们的产品稿，一些逻辑都不完备，这不应该是最开始就应该考虑的吗？这代表的就是典型的程序员视角。
程序员总觉得这个世界有很强的「硬规则」，所有事情都应该是「确定的」，不存在模糊或者不清楚的情况。遇到产品稿在某种特殊情况下没有定义清楚就会很生气，觉得产品经理考虑问题不严谨。
比如，一些 App 可能有断网显示缓存的功能，这个功能就很多异常情况，比如缓存了一半怎么显示？缓存过期了怎么办？显示缓存中突然又连上网上怎么办？连上网好好的突然又断网了怎么办？缓存中的各种操作（比如点赞），是显示失败，还是显示成功？如果显示成功，是假成功，还是待连上网后再发送真实操作？如果是后者，如果发送失败怎么办，如果发送时帐号需要登录怎么办？
好家伙，这么多特殊情况！这个时候，牛逼的产品经理可能会扔一个文档：这些都定义好了。但大多数情况下，产品经理需要和程序员一起把这些异常细节补充完善。
其实，产品经理在思考产品稿的时候，从来都不是把逻辑完备当成第一优先级。第一优先级的还是对产品影响最大的那些因素。从大的角度考虑，这些因素是竞争策略和产品定位。从小的角度考虑，这些因素是用户的需求，场景，流程。
所以，程序员同学应该要理解和体谅产品经理，他们在考虑用户的时候，更多的是考虑需求的强弱。他们在设计流程的时候，考虑最多的也是 99% 情况下的主流程的体验。那 1% 的异常分类下面的各种异常情况，是需要最后定义清楚的，但是并不是对产品本身影响最大的。
有意思的是，这 1% 的异常却是对程序员工作影响最大的。有些产品功能，主流程写起来很容易，但是各种异常情况处理起来烦死人，而且还很难测试到位。最终大家的精力都消耗到了这 1% 的异常定义中。
所以，牛逼的产品经理会做减法，不止是减功能，而且还减异常。不需要缓存的地方就不会加缓存功能。各种异常情况，怎么方便怎么来。最终让开发和测试的力量都可以集中到最核心的用户体验和功能上去。
先有定位，再有功能
音乐播放类的 App，在网易云音乐诞生的第一天起，就不缺少竞争。思考如何定位，做出差异化产品，是王诗沐需要考虑的第一件事情。
最终，诗沐选择主打个性化推荐、歌评、歌单、发展 UGC 社区的方式来做网易云音乐。
有了这样的战略定位，之后的很多产品决策都在配合这个定位。诗沐在介绍网易云音乐要不要做，怎么做一个具体功能的时候，都会思考与自己的定位是否冲突。例如：当做下载功能的时候，产品设计让用户一定要选择歌单。做收藏歌曲功能的时候，产品也让用户一定要选择歌单。
在考虑场景电台功能的时候，因为考虑到会对 UGC 社区带来分流影响，所以选择不做场景电台，只针对某些特别场景（比如跑步）做一些专门的支持。
这种先战略，再战术，让战术配合战略的做法，处处着眼整体，不至于让产品细节一处的得失影响全盘，是非常有章法的。
文档化你的重要判断
诗沐把还原用户场景拆解成 3 个纬度：角色、场景、流程。然后在判断一个功能做与不做的时候，先问自己，为什么要做这个功能。在列出一系列做的理由之后，再一一看这些理由是否足够强。再看看做这个功能有什么风险。
书中拿了很多案例来举例，有些功能不做是与定位有冲突（例如场景电台），有些功能不做是价值不高（例如勋章）。
我个人感受最深的是把这些东西文档化。因为我有些时候发现，一些思考了很久的东西，有结论了。过了几个月，别人问起这个事情怎么决策的，我并不能一下子完全回忆起来。
重要的决策过程，通常可能同时有着收益与风险的权衡，有一些重要的理由支撑着这些决策，有一些被忽略的理由当时可能觉得不重要，这些决策细节都挺重要的。事后回顾，可能发现一些被忽略的理由变化了，或者市场环境变化了，决策就应该有所改变。
而文档化，是这一切的基础。
我想诗沐也是记录了大量网易云音乐的大量决策过程，才可以将网易云音乐从 12 年到现在的发展历程娓娓道来。
小结
- 程序员背景的同学要注意自己的思考角度。
- 产品功能应该服务于产品定位。
- 文档化自己的重要决策，便于事后回顾调整和复盘。