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

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

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

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

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

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

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

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

一、此刻老板又丢需求过来,要不要接?

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

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

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

不过今年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,就可以借鉴上次的经验来指导此次方案。

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

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

五、总结

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

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

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

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

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

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

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

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

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