产品经理，如何应对“老板改需求”？

作者：PM咖夏老师

微信号：PMzone

全文共3500字2图，阅读预计6分钟

在创业公司以及一些中小型公司里，很多产品经理会遇到这样的问题，在项目执行的过程中，因为老板不参与需求的评审，所以很多事情都没办法去跟老板确认。

但是，等到项目结束，版本上线以后，老板会非常认真的参与试用，然后提出很多问题。当然，如果只是一些小的问题，比如UI没做好，交互效果不是很理想，可以直接在线修正，或者发个小版本迭代掉。

但是如果遇到功能与业务目标不一致的时候，会出现项目需要返工，然后整个项目组的人都要加班加点的完成，无论是从士气上，还是从工作强度上，都不是一件很好的事情。

那么，遇到这种情况，产品经理应该如何去面对？其实并没有一个方法可以完美的解决这个问题，只能是作为产品经理的我们，从一开始就注重各种流程环节，尽量把这种可能性降到最低。

一、首先，你要先修炼内功

产品经理与老板之间的博弈，往往是付出与收获之间的博弈。老板发了工资，就希望员工产生相应的价值，产品经理也不例外，很多时候很多老板评估产品经理是否为公司创造了价值的唯一标准就是，产品经理做出来的东西是否符合自己的要求。

那么，这个时候，就需要产品经理先修炼自己的内功。

你要非常清楚在这个公司里，什么样的功能是老板最为关心的，什么样的用户是老板最为在意的，而你在设计功能的时候，一旦觉得触碰到了老板的敏感区域，就要及时做好心理准备。

为什么我们说初级的产品经理才关心用户体验，高级的产品经理一般只关心利益，原因其实很简单。产品经理做出来的产品往往是为公司的利益服务，而不是为了某一个用户服务。很多产品经理认为，如果不是因为用户觉得这个产品有用，他们也不会去使用产品，也不会为产品买单。

其实，这是很初级的想法，在后互联网时代，驱动一个用户去使用一款产品的原因一定是用户的目的性得到满足，也就是我们所谓的用户痛点。但是这样的痛点基本不会是因为一个功能体验的好与坏能决定的，而是公司的业务决定的。

举个例子，在传统的企业采购业务流程中，电子合同是一个非常高效且低成本的业务，如果你是一个可以为用户提供这个业务需求的产品，那么即使你的用户体验做得不好，自然也会有人去用。所以忘记所谓的用户体验，回归到公司利益上来吧。

二、然后，你要理解清楚老板说的话

很多老板在下任务的时候，往往说的非常不清楚，也许只是一句话，也许是随手扔了一篇报告，这个时候就需要考验产品经理对老板说的话如何理解清楚。

很多产品经理在得到老板的指示的时候就会去想功能应该怎么设计，其实这并不是一个明智的做法，是因为有可能连老板他自己都不知道自己想要的是什么，如果你把老板的话当成是需求来分析的话，你就会发现他提出来的压根就不是一个需求，那么即使是你想破脑袋都不一定能想出一个是他真正想要的。

曾经，我的老板给我下过一个任务，他需要知道每个销售商，每个合作商每个月的销售情况，我一开始以为他要的是一个分销体系以及财务报表系统，等我花了一个多星期时间设计出来以后才发现，其实他要的只是一个邀请码功能，并且在管理后台可以看到每个订单是由哪个销售商和合作商的用户产生的订单。

三、接着，你要从内部评审开始

严格意义上来讲，内部评审这个环节其实属于产品研发流程中最为重要的一个环节，但是很多产品经理不会去重视这个环节，甚至还有很多产品经理并不知道有内部评审这个环节的存在。

在他们的思维里，认为评审就是跟开发把需求详细得过一遍，就进入开发阶段。其实这是不正确的，很多时候功能上线了以后，发现与老板的预期出入太大，往往是在内部评审环节出了问题，那么我们首先要搞明白内部评审到底是评审什么。

在开始讲内部评审环节时，产品经理需要非常清楚的知道一件事情，那就是如果对公司当前业务不会造成太大影响的版本迭代，往往可以忽略掉这个环节，那么这个时候就是需要考验产品经理的经验。

1.评审业务解读是否正确

如果当前版本计划中，涉及到对业务的解读，产品经理一定要在内部评审环节跟老板确定自己对业务的解读是否有误，包括业务的流程，业务的逻辑，都要巨细无遗的跟老板过一遍，及时查漏补缺。因为往往产品的功能流程和功能逻辑一定是要与业务流程和业务逻辑相符合的。

如果脱开了业务，设计出来的功能再好，那也是没有任何作用的。产品的价值体现在为业务创造价值之上，所以业务解读是非常重要的。曾经我在设计一个报价功能的时候，因为不清楚业务中是由报价方来给出价格中是否包含税费，所以在内部评审的时候发现功能设计得有误，好在及时发现，将功能修正了过来。

2.评审功能设计是否能达到预期

内部评审的过程中往往会因为需求可能来源于运营部门，所以在评审的时候，产品经理需要与运营部门去讨论功能的设计是否能达到预期。

比如涉及到秒杀、抽奖这类的活动功能的时候，运营经理往往都想要设置一个可以手动去调整中奖白名单的功能，或者是在线修正抽奖概率的功能，那么这个时候产品经理应该提前能够预知到运营经理可能会存在哪些额外的功能需求，并在进行功能设计的时候一并规划进去。

即使需求不是来源于运营部门，你也需要把相关人员都聚集在一起，把你的设计的功能的大致逻辑给所有人都讲一遍，力求功能的设计能达到他们的预期，只要大方向保持一致，细节上的问题是可以被允许的。

3.评审人力资源是否能满足要求

内部评审环节很多时候会因为工作量较大，而选择让开发组的组长、测试组负责人以及UI组长提前参与到评审的过程中来，所以这个时候就需要在内部评审会议上，跟研发部门相关负责人确认清楚人力资源是否能够满足要求。甚至可以在内部评审阶段，就评估出一个大致的研发周期。

四、不要忘了及时将信息同步给老板

在绝大部分中小型公司里，老板往往对于公司里的大小事务都会过问得巨细无遗，一个功能怎么做，一个活动奖品怎么设置，恨不得每个工作都要亲自参与进去。

这种劳模型的老板，其实对于员工来说是非常痛苦的，因为他们会觉得老板每时每刻都在监控着他，做起事情来也是束手束脚，生怕一个没做好，就收到老板的训斥。

其实，很多老板并不是真的懂得如何去做这些执行层面的工作，他们只是每天都在迫切的想要知道员工拿着公司发的工资，到底有没有好好的干活。

所以，长期以往，这就会导致员工和老板之间会产生隔阂，产生矛盾。那么其实对于产品经理而言，很多时候要反其道而行之，要知道产品经理有一个职业素养很重要，那就是主观能动性。你要学会主动将信息同步给老板，你不要怕老板嫌你烦，因为这是一个职场人应该具备的最基本的职业素养。

开完内部评审会议以后，无论老板是否有参加会议，你都要把评审会议的结果以正式邮件的形式发送给所有与会人，并告知给老板，在这封邮件中，你需要详细的把评审过程中所记录的问题以及相关的解决方法都列出来，等老板答复确认邮件后，再行启动开发。但是在这个过程中，一定要区分什么样的内容要同步给老板，什么的内容部需要同步给老板，不要让老板认为你很没有主见。

无论是在评审会议上，周会上，例会上还是在跟老板吃饭的时候，你都要抓住机会沟通，让他对你这次的版本迭代内容做到牢记于心，以防止后期他以不记得会议内容来让你返工。

五、还要记得抓住一切机会给老板科普

你永远都不要认为自己的老板对互联网很精通，你也永远不要认为做一个网站一个App很简单，老板不会不知道。我见过很多土豪背景的老板创办互联网公司，甚至自己只会玩几个APP而已，我也见过很多老板看过几篇文章，能说得出几个专业术语也是仅此而已。

那么，作为产品经理的你，就要学会抓住一切机会给老板科普。

你要告诉他产品的研发流程是什么样的，一旦项目启动研发以后，临时改变需求会给多少人造成多大的困扰，会让多少人做无用功。

你要告诉他一个功能从设计出来到发版上线，中间要做多少工作，功能是基于什么样的场景，什么样的需求被设计出来的，如果一旦做出改动，会造成多大的影响。

总之，你可以使用一切你觉得合情合理的方法让老板认为轻易改变需求是增加成本和风险的。

六、最后硬气面对老板改需求

很多时候，当我们已经把前期的铺垫工作做完以后，难免会遇到就是很轴的老板，版本上线了死活要改需求。老板的任务当然要执行，但是我们在执行任务的过程中，其实可以做得更好。

• 给一个折衷的方案给老板，既能以最小的工作量去修改功能，也能满足老板的要求
• 学会拒绝老板的任务，不是所有的任务都需要去执行的，你要学会拒绝。但是你在拒绝的时候，一定要跟老板讲清楚，为什么这个任务不能做，原因是什么

与老板相处其实没有那么难，重点在于你是否能够站在老板的角度去思考，是否能够站在公司的角度去思考，不要一味的沉浸在你的功能设计中，好的产品经理更多的应该是倾向于老板。