本文由PMCAFF 产品经理社区原创专栏作者 Andy-pm 原创发布于社区，转载请注明出处。
最近看到PMCAFF社区大家都在说“老板说”现象，那么作为一个产品经理如何正确的和老板进行沟通，来应对“老板说”呢？对产品经理来说，有一种灾难，叫“老板说”。老板说不喜欢红色。老板说这产品是给老年人用的。老板说登录框放到左边很醒目，还有更多类似的事情，有的时候听完老板的话，我也会特别头疼，我相信产品们也都有同样的遭遇，那么最后你们是如何解决的呢？
世界上最可怕的人是什么?是老板。谁都有老板。但懂得和老板打交道的产品经理才能成功。 老板要面子，但老板更想赚钱。显而易见的是，你的产品不都是做给你老板用的，所以大多数产品经理在“老板说”之后，或者变了需求，或者偏了方向，或者改了进度，或者啥啥啥的。你要想当个成功的产品经理，学会怎么听从“老板说”，或者学会怎么与老板打交道，是个非常重要的本领。
为什么会有“老板说”现象出现？
我个人总结了以下几点，供参考：
- 老板总认为你不够专业，觉得它比你懂的更多，所以“老板说”——老板自认更专业
- 老板看到邹形后，自我意淫总觉得这里不好、那里不好，所以“老板说”——老板意淫得意
- 老板通过周围人群反馈，非专业的点评，直接告诉你市场好多人反馈这里不行，那里不好，所以“老板说”——所谓的市场反馈数据
- 老板想的比较多，有些老板比较多变，某某人说下，这个觉得对，那个觉得对，然后就出现结论，所以“老板说”——老板善变不坚定
- 老板觉得女性产品女性做会更好，如果是大老爷们做的，缺少很多，结果来了个女性相关人员，所以“老板说”——老板认为异性无法做好相关产品
- 老板希望产品能快速赚钱，产生收益，然后就指指点点，所以“老板说”——这就是老板
- 公司没有规范制度和流程，各种工作无标准、无制度，所以“老板说”——无流程规范难有序
“老板说”现象出现说明了什么问题？
- 上线就出现一堆问题是否没有进行需求功能前的调研和分析？如果没有，那么已经上线了，应该找用户群体进行沟通，然后快速改善。前期工作未做好
- 老板说是常态，毕竟人家是老板，这是特权；但是产品经理是干啥的？为什么没有进行协调？没有说服老板？计划在哪？时间在哪？产品经理需要发挥自己这块的职责和能力来有效解决。产品经理未发挥其作用和职责
- 说明没有标准或者规范的产品流程和规则，那么需要赶紧制定，否则只会让大家做很多无用功。无标准和规范，浪费工时
- 说明沟通、协调很重要，在研发前解决一些不必要的问题研发前的成本最小。研发前工作不可省，很重要
如何解决“老板说”现象
可能大家觉得要解决“老板说”现象还是多和老板沟通、周旋，但是我确不这样认为，这种只能解决一时的问题，而无法从本质解决，我觉得要想根本解决还是要从流程规范、需求前期调研、完善的功能评审机制来解决。首先，我认为需求功能点的搜集源需要统一
在公司中，各个阶层、各个人员、各个部门、老板都会经常提出一些想法、诉求，为了避免他们的这些想法、诉求不被遗漏、能进行有效的记录和跟踪，我们需要一些项目管理工具进行统一管理。例如禅道、MantisBT等。
我们现在使用的是自己做的一个小系统，支持用户发表自己的想法、采取投票来决定是否实现，以及在哪个版本实现，想法更改次数和时间来验证想法的有效性。投票中包括：认可、采纳、不采纳。（我本人技术出身，所以直接贴表结构了，有兴趣的可以看看）
其次，我认为需求功能澄清到移交到技术团队需要有规范的流程，任何人都应该遵守。
我只想强调需求功能实现在前期过程不能减少，在前期解决问题成本代价最小，下图则反映了此现象：
目前我们需求的流程如下：
大家提出的想法记录——-提出人讲解和说明——-投票表决及实现版本——产品输出原型设计——和UI、老板第一次原型沟通——召集技术进行评审——修改评审结果及更新——移交技术团队实施
这里我重点说明下和技术团队的评审，一般我会提前1天发出版本的原型评审范围及时间，然后技术相关人员填写评审记录，正式评审的时候针对技术提出的问题进行解答和沟通。因为一切需求功能不管你设计的再好，再完美，技术不能实现都是天方夜谭，所以功能移交技术团队一定要达成一致。
下图是我们需求功能技术评审的模板，供参考：
再次，我认为需求功能实现的验证，从而保证功能被正确的实现。
这个我们在每一个功能实现完成后进行内部测试人员的测试之后，产品一定要再次测试，然后进行修复BUG，解决BUG的循环，都解决后才正式发布上线。按照TDD的思想，在需求功能移交给技术团队的时候，这个需求功能就是一个BUG，不断解决到这个功能无BUG的时候就可以发布了。
总之，我觉得"老板说"现象经过规范的流程、严格的需求评审之后，"老板说"也不在是万能的了，数据、方式、流程多方面、多维度的把控，规避"老板说"现象，让需求功能正确的执行。
之前我发布了一篇拒绝不靠谱的需求：怎样确定需求才是正确的？里面表达了我的大部分观点，也希望大家来一起沟通和交流，杜绝"老板说"现象，让需求功能正确的执行，这也是我们每一个产品人员的职责和使命。
产品经理少一些常规问题，让老板无话可说？
我想以此标题来表达我的观点，“老板说”现象出现既有老板的原因，也有我们自己的原因；我总相信一句话，既然我们不能改变别人，我们只能改变自己，任何时候我们应该先从自身反省，找出自我的不足改正，提升自我实力，实现共赢。
下面是我搜集的一些产品经理的常犯的一些问题：
1、想当然
这个是产品经理经常所犯的最大错误了。我们接到一个需求，我们想了想，然后就认为自己想的是对的。因为我们用过很多同类产品，想过很多类似的事情，等等。我们也想去做市场调查，但漫长而经常不靠谱的市调结果，往往让我们更加不知所措。所以我们反思：除了想当然我们还能干嘛?也就只能想当然了。 为了不让自己想当然，我们找目标用户听取需求，我们绘制用户模型，我们头脑风暴，我们力争让自己的每一步都显得比较靠谱，希望最终的结果证明我们不是在想当然。唉，我们不容易啊。 当然，我们都不想想当然。如何去除在项目初期的想当然成份，就是产品经理的巨大课题。
2、沟通不足
产品经理，作为一款产品的精神领袖，我们需要把我们的想法，让团队中的每一个人都清清楚楚明明了了。这时，沟通显得极为重要。你做了PPT、写了文档、文档中图文并茂还配了音频视频;你一而再再而三地开会，你每时每刻都在强调产品的核心功能与特色功能。但你无数次悲哀地发现：漏斗原理绝对是特么的真理。甚至你无可奈何地想起存在主义的信条：他人即地狱。 是的，没有人能完全了解另一个人。幸好，做一款优秀的产品不需要完完全全了解你Team中所有人。沟通本身是有很多技巧的，每个人都可以学会。 呃，其实沟通有件法宝。那就是，永远不要觉得自己牛逼而别人傻了吧叽。倾听一直比表达重要。
3、忽视原型
我倾向于任何产品，都需要有原型阶段。原型阶段是个思维和验证阶段。最近两三年的经验是，我们大家都知道做原型，但原型并没有发挥出真正的用途，没有让我们发现产品中潜在的问题。每当这时，我就无比崇拜那些独创出游戏门类的人象宫本茂、席德·梅尔、彼得·莫里纽克斯等人。只有好的、彻底的、令人兴奋的原型，才能让他们成就万千玩家的欢乐。 原型不是用来交差的啊。
4、需求变更
人无完人，我们更不可能强求每个人都是伟人。所以，我们也有犯错的时候。我们经常会发现自己想错了，我们需要改变原来的需求。但是，在原型阶段之后步入实施，也就是思考阶段完毕进入构造阶段，需求真的已经不是我们一个人的事儿了，你这一拍脑袋，设计师、前端、后端、UE都得跟着你变啊。
据不完全统计，所有失败的产品，60%的原因是需求变更太频繁导致实施人员心灰意冷无以为继。 做产品跟建房子真的就是一回事。当你画完建筑图纸，然后开始施工了。这时你想把卫生间从东移到西把书房从南移到北，嘿，还真不是件简单的事情。 当然不是说不能变。我相信认真负责的产品经理，需求越变更未来产品会越好。但不能太随意了。
5、对产品经理来说，有一种灾难，叫“老板说”
老板说不喜欢红色。老板说这产品是给老年人用的。老板说登录框放到左边很醒目…… 世界上最可怕的人是什么?是老板。谁都有老板。但懂得和老板打交道的产品经理才能成功。 老板要面子，但老板更想赚钱。显而易见的是，你的产品不都是做给你老板用的，所以大多数产品经理在“老板说”之后，或者变了需求，或者偏了方向，或者改了进度，或者啥啥啥的。 你要想当个成功的产品经理，学会怎么听从“老板说”，或者学会怎么与老板打交道，是个非常重要的本领。
6、未能有效地整合资源
我把所有你在项目行进过程中，所要调配的人力、物力都叫作资源。你最头疼的肯定是人员问题了。那位程序员死活听不懂你的话。那位设计师一直对你铁青着脸。而你觉得他们能力真的有问题。你想换成配合更默契的人。你得找人事经理，或者直接找老板。你能否成功，就归结为你的资源整合能力怎么样。 或者是，当你做到半道，你的产品不被大家看好，上司不愿再继续了。能否说服上司对项目进行持续投入，这也是资源整合的能力之一。 据不完全统计，所有失败的产品，90%的原因归结为资源整合不到位。
7、靠谱的项目周期
老板总希望第二天早上醒来就发现项目已完成，开始赚钱了。产品经理希望第二天早上醒来，项目的里程碑已经圆满。但希望不是现实，愿望只是愿望。大多数产品经理在既定的时间点上，看不到应该看的东西。Delay是我们永恒的宿命。 互联网的一些事 每当你陷入拖期的烦恼时，你该明白，你团队中的伙伴们，谁都不希望拖期，谁都知道青春无比宝贵。
项目管理的精华就是资源管理，而时间是最可宝贵的资源。 如果你开始了一个新项目，那我建议你一定要把周期分得细之又细，并在每个验证点仔细验证。如果你的项目现在拖期，不必烦恼，只要团队中每一分子都有求胜欲望，那很快会靠谱起来。
8、直视产品品质
绝大部分产品，尤其是互联网类的，产品不是做完了就完了;还必须在交付运营的过程中，进一步验证、改造，提升产品的质量。 最糟糕的情况莫过于，当你的产品一上线，用户蜂拥而至，又一哄而散。据不完全统计，80%跳楼的产品经理都是因为这个原因。剩下的20%很坚强，他们顶住了压力，从另外一个角度来反观产品，分析数据，说服团队积极面对快速行动，然后把用户又感召回来了。 当然大多数产品都是上线后无人问津。
大概念上的产品经理也需要对此负责。而不幸的是，很多产品经理在这时候退缩了，不敢担责任。遥想当年，当我的团队承受这种压力时，那几个跟着我的兄弟，纷纷提出辞职，整得我仰天长笑壮怀激烈。 其实，反思我们的产品为什么赢不来用户，这样的过程会让我们成长得更快。别怕总结教训，别怕失败，别怕面对过去。
9、有效学习
很多产品经理，当他们做成了一款或者两款或者更多的产品之后，他们往往固守成功，忘记了进一步学习。即便他们认为自己是在学习，那也是在学习如何让自己已经有的经验成为牢不可破的教条。咳咳，其实没有比这更可怕的事情了。你想想，为神马拥有那么多优秀产品的微软会在网络时代行走艰难? 有则你肯定听过的寓言，关于空杯的。如果我们想一直在产品这条线上走下去，嗯，要保持有一颗空灵的心，天真而好奇，永远不认为自己是对的，永远做好迎接新知识新理论的准备。还有，永远不要再说永远! 完全避免这9个问题谈何容易。但我们可以用来警醒自己：别再犯二了。
最后，我想对各位产品大神们说，“老板说”现象并不可怕，可怕的是我们怎么去规避此现象。作为一个产品汪，我们应该学会解决问题的方法，而不是遇到问题随波逐流，那么你永远无法成长。
产品的魅力在于过程，结果虽然重要，但过程的风景也是那么迷人，我愿意在产品的路上，做一枚小小的产品，也希望能遇到更多的同道，大家一起交流、成长，开心就好。