编辑导读：产品经理是最危险的职业，站在中间位置既要讨好用户还有服务好老板，另外还有技术和运营包括设计都需要打好交道，简直太难了。但这是我们的职业，我们只能想尽一切办法做好。今天我们以产品经理遇到的一个职场问题（接老板的需求）为例，给出相关做法，我们一起来看看。

不知有没有遇到这样的经历，老板刚提出一个想法，在脑海里还在思考打转的时候，接着又被叫去办公室，讨论下一个想法和需求。

也有可能是被怼的时候，因为老板在体验产品时遇到阻塞，不能顺畅的体验产品某个功能的完整流程。

这个时候有可能是文案让人没能让人第一时间理解到位，作为产品经理需要站出来背这个锅，因为老板指向你。

现在很多互联网创业小公司，有的产品经理与老板同在一间办公室，因此与老板频繁打交道是不可避免。

当需求特别多，研发要求做技术任务时，希望是如期进行，不希望被插需求，这是研发最忌讳。

但是老板眼里希望研发是可以灵活性更高，对于紧急或者小的且有价值的需求，能临时被安排进去并且快速上线验证效果。

作为产品经理就起到了关键作用，需要进行中间协调。

一、此刻老板又丢需求过来，要不要接？

有些开玩笑说，产品经理是最危险的职业。

因为站在中间位置既要讨好用户还有服务好老板，另外还有技术和运营包括设计都需要打好交道。

说不准哪天哪个岗位的人不顺，就给你。当然这是开玩笑的话了。

不过今年7月份的时候，在社群刷过一个截图，图中的内容是杭州某创业公司，因为老板提出一个需求，要求4个月时间造一个抖音，被产品经理拒绝后两人发生口角，吵到最后老板动手，将产品经理打晕住院，这……

从老板提出需求那刻开始，结合自己过往一些经验，还有一些思考，不管老板提出的需求是小还是大，甚至是夸张首先第一反应当然是“接”。

往夸张了说，夸张的需求往讨论的方向走，小的需求往执行方向走。

老板是公司最会画饼的人，我们需要站在老板角度去思考，为什么会这么提出这个想法？而不应该是拒绝！

往小了说，虽然也会提出很多小的需求，包括优化性的，可能不重要，但是我们也要接并且还要给反馈。

因为只有接了，老板下次还会再找你。

如果在公司有多位产品经理，老板丢需求过来不被重视或选择忽视，很有可能失去老板对你的信任，下次还有需求时会选择另外一位产品反馈。

所以不管老板丢过来的需求是啥，如果不能执行，也需要找老板反馈并说明原因，因为老板是一个追逐利益的人。

总之用一句话总结概括就是“不管需求大小，还是需求利与弊，都应当做到正向反馈”。

因为这是一个良好职业形象，和对于做一件事让信息在团队之间流通。

二、需求如果被接了，接下来该怎么做？

被接了的需求，当然不是第一时间安排给研发，否则会被研发暴揍一顿。

如果真是这样，还要产品经理做什么？

作为产品原本就是站在老板与技术之间的中间协调人，服务好老板，也要照顾好研发的心情和情绪，让研发尽可能有一个沉浸式的研发环境。

1. 接到需求时，从业务角度思考，对需求的大小进行判断

因为前面在接需求时，已经做了一层过滤，再说老板也不傻，不能研发的需求肯定不会要求你及时安排，不然把炒老板鱿鱼也好。

结合过往经验和思考，会将需求划分大中小三个不同级别。

因为在公司已经熟悉业务，对于很多功能和优化，其实能第一眼判断出大概研发成本，以及做了之后会不会对其它关联业务是否有影响。

举个例子：“在页面改动一个按钮组件，这个很简单吧？但是，有的时候可能不简单，因为我们需要看这个按钮组件是否是共用，以及关联的地方有多少，只有做过判断后才有决策依据。”

对于熟悉业务如果欠缺，有个比较合适的方式，看看业务是否重构。

当做重构时技术在制定重构方案，就可以多和技术泡在一块。

有些产品会参与制定重构方案，这个时候需要看技术功底，所以提到为什么产品经理需要懂点技术是好事。

2. 从成本角度思考小中大的需求

在这里，小是指小需求，调用的成本也小。

• 如果从开发成本角度思考的话，一般是从工时计算，几个小时搞定的需求，可能都视为小需求；
• 中型需求，是指需要以半天为单位计算，一般需要用户到一个/或者几个半天时，基本为中型需求；
• 大型需求，是指以天为单位计算，一般需要用到几天/一周或者半个月时间，这种为大型需求，当然还有更长时间研发周期。

每个公司情况一样，所以评估的标准也不一样。

当然，除了从成本角度考虑，还得从价值思考，因为需求最终是为用户和公司创造价值，不能为用户带来好的体验，还不能给公司带来商业利益，那就不值得深究。

所以接下来我们进入价值分析模块。

三、接了后决定做时，是否要马上安排？

第一要点，就是需求小但是价值大，或者这个优化点明确收益，以及不解决会影响用户使用，那就必须马上安排。

什么叫需求小价值大？

举个简单例子：

经过数据分析，用户在购买商品下单时，总是会误点旁边的按钮。

经过调研分析用户误以为旁边的按钮是结算，主要原因是旁边的按钮过于显眼。

而此时调整方案就是弱化按钮的颜色，加强结算按钮的效果。

这种对收益产生大研发成本又低，就可以和技术开会或者找到对应的技术负责人马上安排。

这个例子有点扯，不过在实际工作场景中会有很多这样跟收益直接相关且简单的需求。

过往经验和思考，对于这种利好的小需求，无需进行研发排期，真排期研发就不灵活，会限制很多利益相关的需求，还会打击相关人的信心，因此需要产品经理做到平衡点。

所以，对于接到的需求且决定做时，是否需要马上安排，具体还是得看价值，如果是大需求需要进入排期，所以最终需要介入价值分析。

用老板最喜欢的话来说：“这个需求能给公司创造了多少收益/利润？也就是赚不赚钱？”

所以接下来进入价值分析，价值层离不开用户同时也离不开公司。

作为一个产品经理即为用户服务同时也是为公司服务，一个合格的中间人需要学会衡量双方的利益。

当遇到争议比较大的决策时，可能是价值判断没有做足。

因此、需要找到平衡双方利益点的方法，有的时可能是如何取舍的问题。

做价值判断，也不能完全凭着对业务的熟悉，靠着主观臆断做评判，最好有理论方法支撑，尽可能让决策有充分的说明条件，这样大家对你做的决策才信服力，否则会减分从而失去威信。

需求是为谁服务？虽然是老板提出来的，但是最终还是离不开用户。

不管商业模式如何，没有用户就无法变成有利可图的商业模式。

用户如此广众，每一个人都是有自己的想法，而且每个人都能提出不一样的需求。

因此作为产品经理的我们需要学会判断，这个需求到底是解决用户的什么诉求，是否值得优先做，非常值得深度思考。

平常个人会比较常用的方法就是“剑指ROI”，因为这是最好判断的标准之一。

ROI好又受老板欢迎，如果不影响其它关联业务或者有些许影响时，可以进行计算营收和影响之间是否形成正比，如果营收值大于影响值的好几倍，可以直接做。

不过，有的时候工作久了，就会不由自主进入主观臆断，所以有些市面上的分析方法还是有一定的作用。

比如我们常听说的KANO模型（这个模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系）。

• 基本（必备）型质量——Must-be Quality/ Basic Quality；
• 期望（意愿）型质量——One-dimensional Quality/ Performance Quality；
• 兴奋（魅力）型质量—Attractive Quality/ Excitement Quality；
• 无差异型质量——Indifferent Quality/Neutral Quality；
• 反向（逆向）型质量——Reverse Quality，亦可以将 ‘Quality’ 翻译成“质量”或“品质”。

感觉KANO模型没有那么直接，认为俞军老师在他的著作《俞军产品方法论》里提到过一个，关于一套对需求的分析方法，通过分层的方式划分需求的优先级。

1）底线功能

满足用户基本需求，像在淘宝购物的时候必须要能付款，使用微信的时候必须能发消息”。

2）是够用就好

不需要投入太深入，继续做了也不会解决具体业务问题还不如适合而止，这些往往一般都是在非主干道上。

用另外一个词表达，就是没有必要纠结细枝末叶，把精力放在核心区。

举例：

• 购物车为空时，推荐去引导购物就可，没有必要认证研究用户喜欢什么；
• 添加微信好友只需要打招呼就够，就没有必要放一段视频介绍；
• 购物软件的分类查找够用就好，没有必要精细化区分等等”。

3）越多越好

个人认为这类优先考虑营收为主，然后考虑留存。

比如：像做B端工具产品，很多功能越多越好，因为能满足不同类型的商家诉求，滴滴打车当然是叫车越快越好，百度搜索能越快搜索到想要的内容，还有购物商品越多越好。

对于这些能增加用户体验，帮助用户提升效率找到自己想要的东西，都是有利于长期投入。

4）惊喜需求

对于这类没有必要投入更多资源，只需要在恰当的时候做到惊喜就够。

比如：用户在叫快车的时候，如果快车资源没有，刚好专车有闲置资源，这个时候为用户选一辆专车，就能为用户制造惊喜。

有了需求分析方法，就一切都了事了吗？最后才进入真正的执行环节。

四、需求分析完后，到底该如何做？

当对需求做了足够的分析之后，接下来就是进入执行环节。

从产出需求文档开始到最后的研发上线，最终还有一个环节，遇到过很多的朋友、包括也有同事会经常忽略掉的，就是对上线后的需求进行效果跟踪和复盘。

对于个人的理解，或者站在老板的角度思考，已经付出成本，是否应该给我反馈结果？好让老板自己知道花费的这个钱，到底买的是个啥东西？

对于产品经理而言，是一次历练的机会，因为能对自己跟进执行的需求进行一次完整的收尾，而复盘就是最好的收尾。

整个环节按照自己的理解分为4个部分：

1）对待研发进度

得先从做任务规划到任务拆解开始，在这里不再细说，有机会可以专门写一篇文章来解释，但是对于产品经理有一个点必须做到位，就是对研发进度做到心中有数，大概可以从这几个维度。

2）产品规划

作为产品经理有一份专门的产品规划线，每一个需求都是为最终目标服务，有些公司会专门制定目标，或者是用现在比较流行的OKR制定计划。

3）任务拆解

比较考验产品对业务的熟悉程度，还有得有一定的技术理解能力，有些技术可能在做任务拆解没有产品做得那么顺畅，原因是技术对业务熟悉程度低于产品。

4）任务同步

得定期有任务进度同步会议，拉上相关人员组织会议，询问进度，针对中间遇到的问题讨论解决方案，一切都是希望研发能如期按照既定的时间上线，解决中间协作问题。

最重要的一点是，当老板询问进度的时候，我们能立马答出并具体说明，这才是对整个进度的把控表现。

然后进入到效果复盘环节，在这里老板往往比较在乎，我们付出的成本是否真正有所收获。

假如做的需求直接与营收相关，那最好的收获就是ROI是否成正比，达到了需求才是非常值得的，尤其是创业公司需要自己学会供血。

效果复盘的前面，有一个很重要的环节，就是需要实时检测数据，当数据有异常，不管是上升还是下跌，都需要及时做出反馈，明白具体的原因才好对下一步工作开展。

对于复盘的情况，在相同的业务场景，我们可以借鉴。

比如：我们在搜索列表的商品页增加了一个引导下单的营销icon，发现此次效果非常好。对于这个时候，我们对其他场景产生了新的想法，想在分类列表页做相同的营销icon，就可以借鉴上次的经验来指导此次方案。

对于效果复盘，需要拉上相关同事进行汇报，尤其是老板做到及时同步，还有具体的原因。

所以在复盘汇报时，不能光说数据，而是要有具体且可靠的结论，不然会被误认为是瞎猫碰上个死耗子。

五、总结

对于老板提出的任务需求，我们的第一反应不是拒接，而是先接住，然后进入判断。

尤其是创业公司，如果产品经理有多位时，老板总是丢需求给你，而最终却石沉大海，下次的需求可能就不会再丢给你了。

将心比心如果是你丢给别人需求，对方对你的需求无动于衷，不给予任何反应或者是直接拒绝，你心里的想法会有很大的改变。

除了学会接住老板的需求之外，我们还得有具体的分析方法。

不是每个需求都是优先级极高，因为我们是中间人，除了学会接需求，还需要照顾执行需求程序员的情绪，尽可能让程序员拥有一个沉浸式工作环境。

如果总是打扰程序员，是会被对方拒绝，还会落下一个坏印象。

久而久之在大家眼里就会失去公信力，认为产品经理只是一个传递信息的话筒，连基本的判断能力都没有。

需求虽然被安排上了，我们得对最终结果负责。

需要去观察数据，得出结论，学会向上和向下汇报和同步信息，这样才能让一个好的需求或者遇到的问题，在整个协作环节就不会信息阻塞，还能在老板面前博得一个好印象，也能助力自己在以后的业务达成难度有所减少。