好久没有认真总结最近的产品心得了。积累了很多主题，都在高强度的任务节拍中磨没了。连书都不看的懒人，如果再不养成总结的习惯，就TMD的完蛋了，就变成垃圾产品的产品经理了。

完蛋问题1：慎用设计手段处理需求问题。

发现产品中出现的问题之后，产品经理的作用，最最少应该是把这些问题背后的需求发掘清楚，翻译给大家和本人。交互设计师的作用，则应该是依据需求层面对该问题的解释和衡量，提出对应的处理方案。但真实情况是什么样？有时候，项目紧张，没有条件和时间做完整的用户调研或测试，几团体一同拍脑袋决定，几个拍脑袋的人却都不靠谱。有时候，需求模棱两可，竞品分析一下其他几个产品的做法，然后东施效颦，几个被拿来分析的产品却都不靠谱。

这些都不可取。可取的是，要么，最终以百分之百的理由说服本人；要么以低成本、低耦合的方式进行快速试错。要清楚的跟进，不能糊里糊涂的上线。

这里有一种误区，千万别被看上去还行的设计方案蒙蔽了本人。若需求都没想清楚，再贴切的设计方案，也是一种圈套，形成功用越做越做的圈套之一。

完蛋问题2：别为少数用户浪费太多精力。

听到的用户声音，基本都是那部分很喜欢自动反馈问题的少数派。大致听一听就行了。让不可替代的技术资源，去处理大部分用户需求的功用。至于如何判断某些反馈能否是大需求，产品经理的能力问题。

完蛋问题3：别由于华而不实的功用而忘记核心体验。

如果是一个邮箱，再NB的容量和网盘功用，也比不上邮箱收发速度。如果是一个相册，再NB的相册模板，也比不上图片上传速度。先把核心体验做到极致再说，别被竞品花里胡哨的辅助功用吓到。

完蛋问题4：数据有时候不是那么重要。

如果不是电商或千万级用户量的产品，就不能拿数据来左右本人和团队的产品动作。一个深谙需求的合格的产品经理，对一个发展初期、绝对简单的产品，应该拥有基本的判断力，来自产品经验和对该领域的直观感觉。数据应该发挥应有的合适的作用。

完蛋问题5：别忽视技术骨干的产品建议。

虽然技术男看上去基本上都窝在本人的电脑前，浑浑噩噩的拍着代码。但靠谱的技术，最解产品背后的数据结构和实现逻辑。产品经理将需求翻译成功用、提交给开发之后，最有可能节省时间成本、降低实现风险的环节，是跟技术之间的讨论。讨论新功用如何融入现有逻辑、当前能否拓展新需求进去。经常有眼前一亮的技术建议，让功用愈加富有逻辑美感、愈加节省实现成本。

换句话说，懂更多的技术、培养技术思维，产品经理就更容易NB和靠谱。我特别享用这一过程，跟工程师讨论技术实现方式的过程。

完蛋问题6：运营驱动产品的本质

真正靠谱的产品动作，来自于最前线的用户需求。用户需求不是靠用户本人喊出来的，是要有人泡在用户里面去发现才行。产品经理就得干这活儿，去运营。一个脱离运营，只做功用的人，基本是还只是交互设计师。

恬不知耻的说，这活儿也只能由产品经理来干，纯粹的编辑、运营，也没办法从运营中抽取和翻译出靠谱的需求，乱七八糟的1.0媒体、门户类产品就是典型反例。

总的来说，产品经理又不是超人，不可能躲过这么多圈套、克服这么多问题。所以一个产品组，几个默契的产品人一同把关，比较稳妥。