那些年，我掉过的产品坑（二）

　　点击查看第一篇：产品经理5点工作经验总结
　　做产品掉过很多坑，但重要的是一个坑不能掉两次。
　　思考问题的全面性
　　如果要对一个功能进行改动，一定要把功能前后的流程想清楚，要留意这些改动会不会影响到别的部门或团队（利益）。比如有个功能叫意见反馈，基本每个App都会有这个功能，如果把这个功能入口放的层级浅一点，那么用户反馈量会增加，增大了处理这些反馈的同事的工作量；如果把入口放的层级深一点，那么用户反馈量会减少，降低了处理这些反馈的同事的工作量。与之对应的，如果把意见反馈功能的体验优化得很好，则降低了用户反馈问题的门槛，反馈量将增加；如果体验不做优化，用户提交问题的门槛较高，反馈量减少。
　　说的再简单一点，一个功能的改进也许我们觉得对用户的体验会非常好，但是可能会遭到其他部门的反对。所以思考问题一定要全面：用户输入的信息最后会输出到哪里？输出完后谁去对这些信息进行处理？他们是怎么处理这些信息的？这些都要考虑清楚。
　　产出物的一致性
　　版本迭代，首先产品经理产出PRD，接着交互设计师产出交互稿，然后视觉设计师产出视觉稿、标注、切图。PRD里要写清楚每个功能点，包括文案、标点符号等细节，然后要保证交互稿的内容是和功能点保持一致的，视觉稿的内容要和交互稿保持一致。我们都知道一个很古老的游戏叫COPY不走样，要求一个一个人往下传的时候尽量不要出现走样，这个游戏规则比较难，看了一两遍就不能回头继续让对方做动作了，但是产品不是，产出物就在那边，沉下心来去比对、去思考。
　　产出物的不一致，出现的问题就是在技术评审完开始进行开发时，工程师不知道该以哪个为标准，然后又要返工。当然出现的问题不仅仅是这一个方面，还有很多其他问题，不多展开。产品经理要对整个流程负责，交互稿的问题，视觉稿的问题，都是产品经理的问题，是产品经理的工作没做到位。产出物是否一致是衡量一个产品经理有没有入门或者说基本功是否扎实的重要因素之一。
　　需求PK的逻辑性
　　需求评审会上，经常会出现各种PK，一个人认为这样好，另一个人认为那样好，然后互不退让，争得面红耳赤，这其实是不明智的。评审这个功能到底行不行，把你的道理摆出来，把你的方案拿出来，别人凭嘴撕逼，我们凭行动。
　　回答一个功能需求到底如何，只要思考以下三个问题：做什么？为什么做？怎么做？三个问题分别对应着产品方向，用户场景，解决方案。把这三个问题想透彻了，PK时可以多自信一点了。
　　需求评审会中需要保持独立思考，不被带到沟里去。因为难免会碰到一类人他们喜好使用强盗逻辑去说服别人，这个时候要能快速分辨出来，然后进行制止。比如二分式思维，认为不是A就是B；使用了什么类型的论据，是否有来源；有没有在句子中使用带有观点倾向性的形容词这些都要千万注意。