| 文章描述：听到的用户声音，基本都是那部分很喜欢主动反馈问题的少数派。大致听一听就行了。让不可替代的技术资源，去解决大部分用户需要的功能。至于如何判断某些反馈是否是大需求，产品经理的能力问题。 |
好久没有认真总结最近的产品心得了。积累了很多主题，都在高强度的工作节奏中磨没了。连书都不看的懒人，如果再不养成总结的习惯，就TMD的完蛋了，就变成垃圾产品的产品经理了。
完蛋问题1：慎用设计手段解决需求问题。
发现产品中出现的问题之后，产品经理的作用，最起码应该是把这些问题背后的需求发掘清楚，翻译给大家和自己。交互设计师的作用，则应该是根据需求层面对该问题的解释和衡量，提出对应的解决方案。但真实情况是什么样？有时候，项目紧张，没有条件和时间做完整的用户调研或测试，几个人一起拍脑袋决定，几个拍脑袋的人却都不靠谱。有时候，需求模棱两可，竞品分析一下其他几个产品的做法，然后东施效颦，几个被拿来分析的产品却都不靠谱。
这些都不可取。可取的是，要么，最终以百分之百的理由说服自己；要么以低成本、低耦合的方式进行快速试错。要清楚的跟进，不能糊里糊涂的上线。
这里有一种误区，千万别被看上去还行的设计方案蒙蔽了自己。若需求都没想清楚，再贴切的设计方案，也是一种陷阱，造成功能越做越做的陷阱之一。
完蛋问题2：别为少数用户浪费太多精力。
听到的用户声音，基本都是那部分很喜欢主动反馈问题的少数派。大致听一听就行了。让不可替代的技术资源，去解决大部分用户需要的功能。至于如何判断某些反馈是否是大需求，产品经理的能力问题。
完蛋问题3：别因为华而不实的功能而忘记核心体验。
如果是一个邮箱，再NB的容量和网盘功能，也比不上邮箱收发速度。如果是一个相册，再NB的相册模板，也比不上图片上传速度。先把核心体验做到极致再说，别被竞品花里胡哨的辅助功能吓到。
完蛋问题4：数据有时候不是那么重要。
如果不是电商或千万级用户量的产品，就不能拿数据来左右自己和团队的产品动作。一个深谙需求的合格的产品经理，对一个发展初期、相对简单的产品，应该拥有基本的判断力，来自产品经验和对该领域的直观感觉。数据应该发挥应有的合适的作用。
完蛋问题5：别忽视技术骨干的产品建议。
虽然技术男看上去基本上都窝在自己的电脑前，浑浑噩噩的拍着代码。但靠谱的技术，最解产品背后的数据结构和实现逻辑。产品经理将需求翻译成功能、提交给开发之后，最有可能节省时间成本、降低实现风险的环节，是跟技术之间的讨论。讨论新功能如何融入现有逻辑、以后是否拓展新需求进去。经常有眼前一亮的技术建议，让功能更加富有逻辑美感、更加节省实现成本。
换句话说，懂更多的技术、培养技术思维，产品经理就更容易NB和靠谱。我特别享受这一过程，跟工程师讨论技术实现方式的过程。
完蛋问题6：运营驱动产品的本质
真正靠谱的产品动作，来自于最前线的用户需求。用户需求不是靠用户自己喊出来的，是要有人泡在用户里面去发现才行。产品经理就得干这活儿，去运营。一个脱离运营，只做功能的人，基本是还只是交互设计师。
恬不知耻的说，这活儿也只能由产品经理来干，纯粹的编辑、运营，也没办法从运营中抽取和翻译出靠谱的需求，乱七八糟的1.0媒体、门户类产品就是典型反例。
总的来说，产品经理又不是超人，不可能躲过这么多陷阱、克服这么多问题。所以一个产品组，几个默契的产品人一起把关，比较稳妥。