永远没有最好的产品管理的流程，适合实际需要的产品管理流程才是最好的流程。

　　回首在创业公司担任产品经理这几年，火山在流程图、原型图、PRD等技术流的硬技能磨练得还算扎实，因为这些硬技能是只要自己肯花心思去学习和研究，假以时日是可以达到一定的高度的。而对于如何管理需求、如何推动项目、如何进行产品决策等意识流的软技能，就是很难通过理论的学习得到的。但恰恰也是这些意识流上的环节，是最容易让产品经理走弯路的地方，这些弯路总结起来就是几条：

　　第一、完美主义

　　这是初级产品经理最容易走的弯路。典型的表现就是想太多，臆想用户需求，各种边边角角的应用场景考虑得细致入微，投入巨大的人力，最后花了大力气做出来一大堆用户很少用，甚至根本用不到的功能。

　　第二、一蹴而就

　　简单了解需求之后，没有需求分析，不跟开发做可行性分析，在设计过程中也不跟业务方作需求评审，流程图、原型图、prd整个项目一蹴而就，最后PRD出来之后才进行需求评审，才发现一开始方向就错了，整个产品方案需要推翻重做。

　　第三、脱离用户

　　这一点，toB类产品经理是重灾区。从销售、客服、老板、开发等等各方获取需求，却鲜有直接问用户获取需求，这直接导致产品经理对于伪需求的辨别能力直接下降，最终导致做出来的产品如同隔靴搔痒，无法触及用户心中最大痛点。

　　第四、决策缺跟弦

　　资源紧张，先做哪个后做哪个，产品的取舍与决策永远都是跟着自己的感觉走，缺跟弦，或则索性被业务部门牵着鼻子走，缺少对于项目价值的考虑，最终导致花了很多的时间，做了很多的项目，产品却没有本质的提示。

　　第五、毫无章法

　　无论是管理需求、产品设计，还是资源协调、项目推动，基本都是跟着感觉走，想先做什么就做什么，想到哪儿就做到哪儿。缺乏有效而必要的管理规范，做项目也缺乏套路，毫无章法，进而导致需求管理一团乱，项目推进效率低。

　　以上这些弯路是我在创业公司这几年感触比较深的，正所谓吃一堑长一智，在我发现自己走过一条弯路之后，我就会总结一些改进或修正的方法，以避免在以后的工作中再犯同样的错误，走同样的弯路。尽管实践证明，大多数心得都是行之有效的方法，大都能解决实际的问题，但它们主要还是针对每一条可能犯的错误制定的单点突破的攻略。团队人员规模在扩大，项目越来越多。换一个项目、换一个产品经理、换一个对接人，这些错误就会继续重演。因此，我就一直在琢磨，有没有一种方法，可以：

　　最大限度地避免产品经理犯一些低级错误？最大限度地让不同风格、不同背景的产品团队成员保持相同的步调？让产品经理制定的优先级计划与业务部门的需求尽可能地一致？尽可能地避免产品经理的项目方案犯方向性的在错误？最大限度地降低产品、开发与测试之间的沟通不畅？……

　　要回答这些问题，我首先想到的就是——去学，去看看那些比较成熟的大公司它们都是怎么做的。

　　作为一名名不见经传的创业公司的产品新人，显然，我很难接触到BAT这样的一些大公司的产品前辈，更没有机会到大公司进行学习。但我知道，有很多的前辈，都已经把他们在大公司里面的积累通过文字和书籍的形式分享出来了。因此，我了解这些大公司的途径就是，看这些大公司的产品前辈写的书。从刚入行做产品时，我就看过很多产品方面的大牛前辈的书，比如《人人都是产品经理》、《谷歌亚马逊如何做产品》、《yes，产品经理！》等等，他们无一例外都提到了产品管理流程对于一家互联网公司的重要性。因此，我在上任伊始就有意识地去建立一些必要的产品管理的流程。比如：

　　在我担任我们公司产品经理之前，由于公司刚成立没多久，总共也就七八个开发，没有产品经理，更别提什么产品管理规范。要说有什么原则，那就是——怎么快怎么来。所以，我们能看到的几乎所有需求都是从需求方（老板、销售、市场、客服、开发）以最短路劲直接提给开发。比如销售接到一个客户需求，回来跟某个开发简单一说，开发gg以他们的高智商在脑回路里一转——没问题，可以做！于是立马就着手开始干了。再问他们要多久呢？脑回路再一转，掐指一算——3天吧。最后，开发gg没有食言，还果真用3天就把功能做完了，由于当时也没有测试，于是开发gg自己测一下没啥问题，当天下午就直接就发布上线了……