所谓“弯路”
回首在创业公司担任产品经理这几年，火山在流程图、原型图、PRD等技术流的硬技能磨练得还算扎实，因为这些硬技能是只要自己肯花心思去学习和研究，假以时日是可以达到一定的高度的。
而对于如何管理需求、如何推动项目、如何进行产品决策等意识流的软技能，就是很难通过理论的学习得到的。但恰恰也是这些意识流上的环节，是最容易让产品经理走弯路的地方，这些弯路总结起来就是几条：
第一、完美主义
这是初级产品经理最容易走的弯路。典型的表现就是想太多，臆想用户需求，各种边边角角的应用场景考虑得细致入微，投入巨大的人力，最后花了大力气做出来一大堆用户很少用，甚至根本用不到的功能。
第二、一蹴而就
简单了解需求之后，没有需求分析，不跟开发做可行性分析，在设计过程中也不跟业务方作需求评审，流程图、原型图、prd整个项目一蹴而就，最后PRD出来之后才进行需求评审，才发现一开始方向就错了，整个产品方案需要推翻重做。
第三、脱离用户
这一点，toB类产品经理是重灾区。从销售、客服、老板、开发等等各方获取需求，却鲜有直接问用户获取需求，这直接导致产品经理对于伪需求的辨别能力直接下降，最终导致做出来的产品如同隔靴搔痒，无法触及用户心中最大痛点。
第四、决策缺跟弦
资源紧张，先做哪个后做哪个，产品的取舍与决策永远都是跟着自己的感觉走，缺跟弦，或则索性被业务部门牵着鼻子走，缺少对于项目价值的考虑，最终导致花了很多的时间，做了很多的项目，产品却没有本质的提示。
第五、毫无章法
无论是管理需求、产品设计，还是资源协调、项目推动，基本都是跟着感觉走，想先做什么就做什么，想到哪儿就做到哪儿。缺乏有效而必要的管理规范，做项目也缺乏套路，毫无章法，进而导致需求管理一团乱，项目推进效率低。
以上这些弯路是我在创业公司这几年感触比较深的。正所谓吃一堑长一智，在我发现自己走过一条弯路之后，我就会总结一些改进或修正的方法，以避免在以后的工作中再犯同样的错误，走同样的弯路。
尽管实践证明，大多数心得都是行之有效的方法，大都能解决实际的问题，但它们主要还是针对每一条可能犯的错误制定的单点突破的攻略。
团队人员规模在扩大，项目越来越多。换一个项目、换一个产品经理、换一个对接人，这些错误就会继续重演。因此，我就一直在琢磨，有没有一种方法，可以：
- 最大限度地避免产品经理犯一些低级错误？
- 最大限度地让不同风格、不同背景的产品团队成员保持相同的步调？
- 让产品经理制定的优先级计划与业务部门的需求尽可能地一致？
- 尽可能地避免产品经理的项目方案犯方向性的在错误？
- 最大限度地降低产品、开发与测试之间的沟通不畅？
……
要回答这些问题，我首先想到的就是——去学，去看看那些比较成熟的大公司它们都是怎么做的。
极简版产品管理流程
作为一名名不见经传的创业公司的产品新人，显然，我很难接触到BAT这样的一些大公司的产品前辈，更没有机会到大公司进行学习。但我知道，有很多的前辈，都已经把他们在大公司里面的积累通过文字和书籍的形式分享出来了。因此，我了解这些大公司的途径就是，看这些大公司的产品前辈写的书。
从刚入行做产品时，我就看过很多产品方面的大牛前辈的书，比如《人人都是产品经理》、《谷歌亚马逊如何做产品》、《yes，产品经理！》等等，他们无一例外都提到了产品管理流程对于一家互联网公司的重要性。因此，我在上任伊始就有意识地去建立一些必要的产品管理的流程。比如：
在我担任我们公司产品经理之前，由于公司刚成立没多久，总共也就七八个开发，没有产品经理，更别提什么产品管理规范。要说有什么原则，那就是——怎么快怎么来。所以，我们能看到的几乎所有需求都是从需求方（老板、销售、市场、客服、开发）以最短路劲直接提给开发。
比如销售接到一个客户需求，回来跟某个开发简单一说，开发gg以他们的高智商在脑回路里一转——没问题，可以做！于是立马就着手开始干了。再问他们要多久呢？脑回路再一转，掐指一算——3天吧。最后，开发gg没有食言，还果真用3天就把功能做完了，由于当时也没有测试，于是开发gg自己测一下没啥问题，当天下午就直接就发布上线了……
这样的形式由于中间环节少，看起来似乎工作效率、沟通效率都挺高。但时间一长，团队规模一大，负面影响也就逐渐显现出来了，这些负面影响集中表现在：
- 低价值需求——需求没有经过有效地筛选过滤，开发的产品没有缺乏有效的价值，一些低价值的需求被投入巨大的精力去实现；
- 低优先级需求——需求的优先级缺乏有效的评估，做了很多紧急但不重要的项目，对产品的提升并无太大的意义；
- 信息不畅——由于大多单点沟通，所以业务部门并不知道技术部门在整体都在做些什么项目，开发每天都很忙，但似乎没有人知道他们在忙什么；
- 节奏混乱——开发做完一个项目没问题就发了，有时候一周法两次，有时候一周发三次，也有时候遇到大的项目，可能两周也不发一次，工作缺乏节奏感。
- 产品质量差——由于产品缺乏需求设计，又缺乏有效测试，产品上线之后又暴露出一堆的bug，根本用不起来。
于是，为了解决这些问题，最为一名新官，在我担任产品经理之后，除了完成自己最基本的产品设计的工作之外，在产品管理的流程上，我也烧了三把火：
第一把火：需求归口
所有人提出的需求，必须且只能提到我这里做统一的需求归口，由我进行统一的需求筛选及优先级管理。业务方不能越过产品经理直接向开发提需求，开发人员也有权拒绝产品经理之外的人员提的所有需求。
就这样，公司千丝万缕的需求变得逐渐清晰，开发和业务部门都可以更加清楚地找到准确的对接人。而且，由于产品经理可以将业务部门的业务需求转化为开发更容易理解的开发需求，也可以把所有开发正在开发的项目以清单的形式传递给业务部门，因此，这一把火，也让整个公司跨部门之间的沟通变得更加通畅。
第二把火：产品测试
向公司提出直接了直接的测试人员招聘需求，为团队补充测试人员的角色。测试人员到位之后，在项目没有经过测试之前，开发不得直接把项目发布上线。这一把火，让我们的线上的产品质量得到了很大的提升。
第三把火：产品发布
跟开发、业务部门一起，商定了每周四晚上23:00之后作为常规的发布时间，除紧急修复类的项目之外，常规情况下，一周一个发布周期，产品和项目的开发都按照这个节奏进行推动。这一把火，让整个研发部门的计划性得到了很大的提升。
这就是上任伊始我为公司制定的极简版产品管理流程，尽管比较简单，但的确解决了当时的很多实际的问题，以至于我们CTO在月度全员例会上，对我上任一个月的表现进行了点名表扬。但随着公司的发展和团队的扩张，这个最简版的产品管理流程逐渐不能适应实际的工作需要，于是，我又根据实际的情况对流程进行了版本迭代和升级，比如：
由于没有明确的PRD文档，而沟通又存在信息的损耗和失真，开发最后实际做出来的功能跟产品经理的原始需求差别太大，进而导致跟开发扯皮的情况越来越多，于是，我增加了PRD文档的流程——产品经理提交开发之前必须要形成明确的PRD文档的流程。
业务部门的业务量陡增，对技术部门抱怨连天，总觉得很多很重要也很紧急的项目提给技术部门最后都没做，于是，我增加了优先级例会的流程——产品与业务每周一的需求优先级排序的例会，一起商定接下来要做的项目优先级。
由于需求变更经常导致开发、产品和测试之间的沟通问题，比如产品跟开发商定了需求变更的内容，却没有及时告知测试，导致经常测试按照旧版的PRD跟开发提bug在所难免，不仅产生工作量的浪费，甚至有时还造成一些不必要的矛盾。
于是，我又增加了需求变更的流程——任何的需求变更，均需要同时跟开发和测试确认过后才可以进行需求变更，同时，变更的内容必须及时记录进入PRD文档。
就这样摸着石头过河，一步一步地对产品管理的流程规范进行升级，最终，在我离开公司之前，就在当时那样一个有着七八十人技术团队的创业公司当中，形成了这样一套产品管理的流程规范：
实践证明，我当时为了解决实际问题所制定的这套流程规范，对于我们当时那样一个规模的创业公司而言，基本还是行之有效的。但这并不意味着它也一定适合每一家创业公司，今天把这套流程分享给大家，也只是给大家做个参考。
那么，创业公司到底需要怎样的产品管理流程？
在火山看来，没有任何一套产品管理流程是适合所有创业公司的，因为每家创业公司的情况都不一样，永远没有最好的产品管理的流程，适合实际需要的产品管理流程就是最好的流程。
要问怎样才能制定出一套适合自己公司的符合实际情况的产品管理流程，如果一定要火山给出一个建议，那我的建议是：去了解成熟公司的做法，但照搬照抄成熟的公司的做法。因为每家比较成熟的互联网公司都会有一套自身的需求或产品管理流程规范，它们可能因企业文化的不同、行业属性的不同或产品形态的不同而形态各异，照猫画虎可能会适得其反，即便是火山总结的这套相对比较适合创业公司的产品流程也是如此。
但殊途同归，产品管理流程的存在，说白了都是为了通过规范的流程去降低因人、因项目、因背景等各方面因素带来的不确定性，让需求和产品的管理更加可控。与此同时，一套好的产品管理流程规范还可以从总整体上有效地提升一个团队的工作效率和产品质量，而这也恰恰是管理流程存在与一个互联网公司的最为重要的意义所在。
因此，无论公司大小，无论处于哪个阶段，一套行之有效的产品管理流程对于一家互联网公司都是非常关键和必要的。如果你所在的公司还没有这套流程，或许是时候去制定一套了。
后记
回顾我所走过的这些弯路，它们有一个共同的特点，就是只要产品经理愿意去思考和总结，无论是什么原因导致的，也无论是什么样的弯路，最终都是可以靠产品经理的努力解决掉或避免掉的，因为说到底它们基本都是一个产品经理本职工作内的内容。
但还有一些弯路，可能是产品经理拼劲全力也未必能够扭转得回来的，它们就是由于公司高层决策失误而导致的一些弯路，而这些弯路由于是大方向上的决策失误，因此往往影响也更加深远。
作者：火山，个人微信公众号：PM火山。
