做产品的这几年遇到很多个大大小小的麻烦，有些麻烦让我一度深陷其中无法自拔，有些麻烦彼此之间又有所关联，此消彼长，最后形成了「麻烦地图」。


需求的来源


曾经的我以为，我的需求就是产品的需求；


曾经的我以为，老板的需求就是产品的需求；


曾经的我以为，用户的需求就是产品的需求；


后来我发现，我不过是一个小小的产品经理，我代表不了用户，我只能站在自己的角度试探性的去了解用户当时可能的心理活动，这个技能后来我称它为「一秒钟变小白」。而我们不难发现，那些被大家精精乐道的产品细节背后都是有一个看透用户心理活动的「产品经理」。


后来我发现，老板的需求不一定就代表了用户的需求，只是老板提出的观点或许更有前瞻性，而产品经理和老板之间看似不可调和的问题，也正是他们之间的高度落差所决定。


后来我发现，用户需求有可能还要再次加工才能得到答案。比如我想要一匹马，这样可以快点去公司，后来给我一辆车，是不是可以让我更快一点？所以这里表面上是「需要一匹马」，实质上是需要更「快」。


方法与结果


曾经的我以为，只要用对了方法，就可以得出一个正确的结果。


后来我发现，其实并不是这样。需求文档按照模板去写、需求评审按照流程去做，产品原型用正确的工具去画，这些看似正确方法能得到正确的结果吗?


很抱歉，得不到。一个产品最后的成与败，与太多的因素有着密切的关系，比如团队、比如资源、比如你看待产品的目光。


多与少的权衡


曾经的我以为，能加一点功能对用户来讲都是极好的；


曾经的我以为，产品需要不停的疯狂喂养；


后来我发现，就是我多增加的一点功能，哪怕是多一次点击都会让用户觉得这个功能真TM画蛇添足。


后来我发现，就是因为我没有对需求去排列优先级，上了很多低优先级的功能，让用户觉得这个产品真TM臃肿。


用户问：「这个产品经理是不是没脑子？」


用户问：「没脑子的产品经理能做出好产品吗？」


……


文档写写写，脑袋空空空


曾经的我以为，我要把文档写的像科技论文一样细致，需要不断的细致细致再细致；


后来我发现，就算文档写的再细致，开发同学一个电话打来，还是要屁颠屁颠的跑去手舞足蹈的讲需求、讲逻辑。


后来我发现，执行层面的事情做多了之后的后果就是缺少自主思考的过程，很难发现产品的一些问题，更不要说创造出一些什么伟大的产品体验。


需求文档要写好，但是要有度，多思考，多总结。


乱中取静


曾经的我以为，产品经理需要不断的游走在各个团队中，不断的去沟通，不断的去协调；


后来我发现，过度沟通只能说明事前工作没有做好，所以在过程中才需要不断的去跟进，所以为了避免这种问题，需要做足事前准备工作。沟通和协调只是起到一个保障作用，而非最后救命的稻草。


产品经理需要不断的在混乱中找到做事的方法，尽量不要去体验深夜独自一人加班写文档的痛楚。


这些年经常被这些麻烦困扰，从源头到下游。现在已经发现了这些问题，需要做的就是去解决它们，总结出来与大家分享，希望能对你有帮助。