产品经理经常做的「10件错事」

我最近挖了不少坑，做了不少看起来像对的错事，可谓是惊险刺激。最近小伙伴们也是总会告诉我，他今天又「亲手」给自己挖了多少坑，而且是无法自拔的那种「神坑」。我俩面面相觑，似笑非笑，互道一声「兄弟安好」，继续回去挖坑了，噢，错了，是填坑。

如同我之前所说，其实产品经理有的时候是很无奈的，受限制的因素有很多，但是又处在驱动的这个角色，所以只能严防死守，降低发生问题的概率，只可惜有时候是防不胜防，当然，有时候也是自己的问题。

之前写过产品经理挖过的坑有哪些，这次我们聊点儿更「接地气儿」的，看看我们经常在不经意间犯的小错误有什么。

第一错：画原型带颜色

先从原型说起，互联网发展到现在，交互设计师这个岗位其实已经很普及了，但是我相信还是有不少产品经理在自己苦逼的画着原型，最为重要的，还有不少产品经理是在自己苦逼的画着带颜色的原型，而且是乐此不疲。夸张点说，这就是一件掠夺他人「权利」的暴力事件。

我看到过不少产品经理，觉得自己色彩搭配的感觉不错，然后就开始给原型「大刀阔斧」的上色了，花花绿绿的，而且还满世界的截一些跟自己想法相近的图，放到原型上，好是精彩，让人哭笑不得。这样的结果，却是让视觉设计师痛不欲生。

为什么？因为这样做会干扰视觉设计师的思考，相当于给视觉设计师加上了枷锁，限制了他的发挥；因为这样做会无形中增加产品经理与视觉设计师的沟通成本，甚至可能引起不必要的摩擦；因为这样做还可能会招来不必要的鄙视。

所以，产品经理输出的高保真原型请用「黑」、「白」、「灰」这三个基础色，优先级通过「色彩饱和度」来区分，色彩的部分请放心的交给视觉设计师来完成吧。

第二错：画原型过度追求动态效果

网上有好多类似「Axure7天速成」、「Axure深入浅出」这样的教材，也有在线的培训，导致不少产品经理在学习之后，愣是在Axure上「痴迷」的追求控件各种各样的出现、消失、切换的动态效果，注意我这里说的是「痴迷」。任何动作都想着在Axure上模拟出来，哪怕是一个手势。很明显，「痴迷」=「过度」。

这样的动态效果能给自己加分吗？能，但是能加多少分？只能说很少。但是相反，产品经理为此需要付出的时间和精力，却远远超过这个加分的价值。说白了就是用了很大的价值投入做了一件产出价值很低的事，二者完全不成正比。但是并不是说就一点动态效果都不做了，这里需要自己衡量一下。

所以产品经理需要遵循「产出高效」、「不易出错」、「逻辑清晰」、「界面展示完整」这几个原则来制作原型，其中，复杂的动态部分用文字描述即可，简单的动态效果可以做一下，我们则需要使用更多的时间去思考产品的现在和将来。噢，对了，还有一条很重要的原则：「除去颜色之外，输出的产品原型95%以上的界面布局和交互过程都与最终产品保持一致」。

第三错：只提需求变更不更新需求文档

产品经理平时都很忙，经常不在座位上，不是在开会，就是在去往开会的路上，十分匆忙。你喊他说点问题，他都答的十分快速，由此就可见一般。所以有个经常发生的问题就是，开发同学跟产品经理勾兑完产品功能逻辑之后，发现有些细节之前没有想到，需要提需求变更来补充，产品经理有时候嘴上说好的，可是回去之后就忙忘记了。

所以产品经理在跟开发同学勾兑产品功能逻辑的时候，需要将变更的点都记下来，在结束一天的工作之前将这些需求变更进行复盘和汇总，最后统一在系统中提需求变更单，以天为单位即可。

第四错：需求变更只告诉开发同学，忽略了测试同学

我们继续聊需求变更的事儿，产品经理还会经常闹出另外一个趣事，就是自己针对某个产品问题想好了解决方案后去跟开发同学商量需要变更的点，商量的如火如荼，非常热闹，可是项目经理在确认变更进度的时候，发现测试同学居然什么都不知道，当时尴尬的氛围可想而知。

所以产品经理在确认需求变更的时候，除了要做好记录，还要把相关人都要召集齐，例如客户端开发同学，关联的后台开发同学，测试同学等等。当面沟通完毕后，回去记得再拉一个RTX群，最后再做一次同步，还有把之前提到的需求变更单及时复制到群里，周知大家。

第五错：永远站在开发同学的对立面

外界一直盛传产品经理和开发同学是很典型的冰与火，两者不相容。其实我们的关系没有那么紧张，甚至不少产品和开发都是好基友。但是，有的产品经理在需求评审会上，不知道为什么，好像一下子就进入到那个角色中了，咔嚓一下就站在了开发同学的对立面上，死活都不能听开发同学的建议，哪怕开发同学是对的，因为那样似乎会伤害到产品经理的自尊心。如果对需求评审会有什么疑惑，可以看看我之前写的那篇文章，产品经理的战场：需求评审会。

其实恰恰相反，应该是站在同一个方向才对，我们的目的只有一个，就是让产品变的更好。产品经理应该抱着一个开放的心态，只要是对产品好的，谁的解决方案好就采纳谁，调整好自己的心态很重要。

第六错：忽略与业务部门配合时需要的时间和人力

前阵子跟阿里巴巴集团下菜鸟物流的产品经理们交流的时候就提到了这点，在淘宝，某个简单的需求可能就要贯穿几大核心业务系统，例如订单，交易等等。所以这里有一个很严峻的问题，就是需求事前沟通的较少，没有给其他业务部门预留足够的配合时间，导致时间和人力都很紧迫，协调不开。

所以产品经理在跨部门展开合作的时候，需要给配合的业务部门预留出足够的响应时间，需求先沟通再评审，提前告诉对方，让对方提前有个心理预期。在需求评审后需要让对方在第一时间对产品功能进行开发周期和人力成本的评估，双方校准配合时间，风险一定要提前暴露出来，这时候，不管是否有项目经理，产品经理自己一定要制作一份产品开发甘特图，颗粒度具体到每天/人。每天都要跟进开发进度，落实进展。

第七错：自己代表产品的用户（想当然）

或许这是产品经理的通病，因为我是某个产品的产品经理，所以我就会天天YY一些自己的需求到产品中去，凭着感觉去感觉，而且还觉得这么做是正确的。这么做也许确实会发现一些需求点，但是很有可能都是在想当然，没有任何依据，可以服务的人可能只有自己。