记录员

PM不应该是文档写作员，流程绘制员，上级口令传递员。
PM陪伴问题二十年，不是在发现问题的路上，就是在寻找解决方案的路上。

开发跟你谈流程和逻辑，你要给他一个解决方案；测试跟你谈bug,你要给他一个解决方案。运营和商务跟你抱怨，你要给他一个解决方案，而且这个方案要是当下最优解决方案，它不一定是完美的，可能会有风险，可能有点土，可能不成熟，不是最好的，但它是当下最适合的，是考虑了投入产出比，时间等的结果。

举例：开发问你这个登录注册怎么弄，流程是怎样的

第一步：把一个模块的所有可能情况全部列出来，一般的PM就会把这个发给开发了，让他开始做。

有问题：1、没有结合现在的业务现状和用户场景分析，就不能砍掉其中一些流程吗，有必要弄这么复杂吗？这样开发和维护成本会不会很高？投入产出比怎样，值不值得这样投入？

因此有了后面的步骤。

第二步：把这些所有的情况列出来后，结合业务现状和用户场景分析，删减，砍掉一些没必要，或没多少价值，投入产出比不高，或不值得当下这个阶段来做的需求，给一个精简后的最简单的需求和流程，发给开发。

第三步：做到以上就够了吗？不是，这样下去就会变成短视之徒了，心中要有规划，要跟开发说：“先这样做，我有规划，以后版本迭代时再看看有没有更好的方案。“

这样开发才会觉得你靠谱，有大局观，对大局观其实就是对业务实际和用户场景的熟悉，两把刷子，都要精通。一些PM沉迷于分析用户体验，现在好些了，嘴边经常挂着”场景“一词，但脱离了业务实际，还是不够的。

只看场景不看业务举例：公司机器上什么功能是用的最多的，这时你通过用户分析，想改版，按照自己的理解，这个功能要把入口做深，那这就不符合业务实际了。

只看业务不看场景举例：某个功能其实就是一个低频需求，这时你跟开发说让他统计这个功能的当日活跃、三日活跃和周活跃。事实上，这个功能用的人就不多，但你要开发花费时间和精力来统计这么多活跃，没多大用。而你呢，熟悉了看用户活跃数据时，看当日、3日和周活跃，觉得工作方式就是这样的。

产品要的不是好方案，不是完美方案，是当下最优解决方案。基于此，才有了快速迭代。产品就是权衡后的解决方案。