业务太强势,产品经理如何有效破局?

5 评论 8711 浏览 39 收藏 14 分钟

在日常工作场景中,产品和业务如何取得协同发展,是一个常见的难题,尤其是当业务一侧相对强势时,产品经理便需要想办法应对此类局面。那么,产品经理可以从哪些维度进行破局思考?本篇文章里,作者便结合经验发表了他的看法,一起来看。

不能从一个极端,走向另一个极端。

在如今经济下行的大背景下,很多互联网公司都开始强调以「业务经营」为导向,明确要求尽快稳增长、加强外部业务收入,就连来年预算也指出要坚持「以收定支」。

有一说一,业务为导向也好,经营为核心也罢,这本身并没有错,但怕就怕从一个极端走向另一个极端。

前天有个产品小伙伴和我交流,吐槽他们公司最近过度以业务为导向,他甚至夸张地说,他们公司业务现在都是横着走,对产品设计指手画脚,对开发周期愈发严苛,不断碾压着产品经理的尊严和底线

最残忍的是,公司颇有些「不以为耻」,而「反以为荣」的感觉。

从公司层面来看,这其实是典型的经营战略失衡,镜同学也曾在之前文章中分享过,对于公司或者产品经理来说,最难做的事情其实都是「找平衡」(对产品经理而言,哪件事最难做?)。

实际上,业务「压迫」产品,这种现象是很常见的,重要的是我们需要正确的看待和应对,尤其是下面这些问题,咱们需要找到真正的破局之法:

  1. 如何避免从一个极端走向另一个极端?
  2. 产品和业务,如何才能可持续地协同发展?
  3. 业务团队作为产品经理的内部客户,又是业务上游,如果他们很强势,产品同学应该如何有效应对?

本文,镜同学结合过往经历分享一些浅薄产品职场经验,希望能带给你一些启发和参考。

一、认知定位准确、把握自我节奏

众所周知,职场工作中,有很多矛盾争执并非是沟通问题,往往源于不对称性,尤其是信息的不对称和认知的不对称。

何为「强势」?何为「压迫」?

就像和我交流的那个产品同学,他举了不少「业务强势」的例子,但是坦白说,其实这中间有不少是有认知误区的,有些并非业务强势,而是我们没有准确定位,情绪主导了理性。

比如,他提到他们在做B端产品服务,业务希望增加数据埋点,以便对经营数据进行分析,但这个同学却认为增加这样的功能设计比较麻烦,业务价值有限,ROI会比较低,于是就不主张做相关产品设计,进而和业务battle。

其实,这就是认知错位,没有找准定位,产品需要考虑业务价值,但相较于业务人员,他们的确更有话语权

再比如,这个产品同学又提到他们业务希望对SAAS版本进行差异性定价,其中就希望对「数据权限」作为一个增值功能,购买了产品就可以查看某些数据,否则就无法查看。

他还是觉得业务同事想当然,这些价值都是过于理想,于是,开始讨论、争执、battle,加上业务有了公司导向的「尚方宝剑」,就给了这个产品小伙伴被业务压迫的错觉。

这些都是产品同学的认知问题,因为「强势」、「压迫」这些词汇本身就是主观用语,其实,产品经理首先要抓住主要矛盾,从本质认知取代现象感受,在定位准确的前提下再把握好节奏。

只有这样,才能形成合力;只要这样,就能创造价值。

镜同学早些年曾负责一个紧急项目,当时客户要求时间很紧急,我们团队并不大,但是业务、产品、开发、测试等同事配合很到位,沟通很高效,最终顺利完成了项目,虽然金额不大,但当时团队的亲密感、价值实现让我至今印象深刻。

产品同学和业务同学绝非“敌我矛盾”,而是亲密伙伴,因此,在有被业务压迫的感受时,首先想的应该是要形成合力,就应先从自身出发,明确认知定位,把握自我节奏,不盲目放大小分歧。

二、先礼后兵:理性容错,顾大局、重协作

相信大家都有这样的感受和共识:产品工作本就错综复杂,一团和气是理想,矛盾争执反而是常态。

客观上来看,很多时候我们认知定位是正确的,总有一些业务同学因不懂流程规范、沟通比较强势等各种原因,无端将压力和情绪错误传导至我们。

这些问题都不是很大,但却让我们很不爽,应该如何做呢?

这种情况下,镜同学觉得我们应该果断采取措施,尝试解决矛盾,但不是一顿疯狂输出,而是守中正之道去解决问题的高端操作,简单来说就是:理性容错、顾大局、重协作

现实中,有不少产品同学喜欢标榜「有理走天下、得理不饶人」,甚至还自我标榜:我是就是论事,泾渭分明,只要有理,我就要一决雌雄。

但是,多数情况下,这都是缺乏智慧的表现,职场中很多问题就如同家庭矛盾,分辨对错并不是明智之举,解决问题才是王道。

比如,上周我们有个业务同事突然在群里质问我们产品经理,说为啥某个需求没有按期上线,并言辞强硬地说这样已经影响业务进展了等等,领导也都在群内,他这样的确让我们很难堪。

其实,问题的真相也很简单,他自己弄错了需求,并且我们有会议纪要,写的也很明确,团队的产品经理当时就想在群内回复,直接顶回去,被我制止了。

因为,这样表面能解决当下问题,但却不利于后续协作,毕竟都是一个团队,需要为公司利益同舟共济,后来我们进行了私下沟通,并先商量解决他的需求,也委婉的展示了他的理解误区。

结果却是出奇的好,该业务同学更是坦诚以待,并主动在群内道歉说明,这对我们后续协作更加有利,团队也更有合力,而这样的结果源于我们并没有就事论事般的猛烈反攻

因此,面对业务的问题,不要上来就得理不饶人,要学会变通,有容错胸怀,格局打开,重视协作,风物长宜放眼量。

三、蛮横不讲理?用制度流程惩戒

前天和那个小伙伴交流后,他也认可团结同志、协作创造价值的理念,但他也指出他们公司有一两个业务同事是真的不讲道理,特别强势,你友好沟通反而会被认为好欺负。

这个同学还拿他们这俩同事举例子:

其中一个是业务骨干,有业绩傍身,腰杆子就硬,提的一些产品需求不少都是纯业务思维,丝毫不顾及用户体验和产品的持续发展。

另一个则是业务小兵,业绩差的不行,就是仗着公司「以业务为导向」,真的是对产品肆意践踏,张口闭口为了公司经营着想,甚至以道德绑架,提出的需求乱七八糟,而且常常就是一句话,描述含糊不清。

听他说完,镜同学深有感触,我觉得不少公司都会遇到一两个这样的业务同事,这种情况下怎么破局呢?

根据镜同学浅薄的经验,我们需要运用智慧进行「制度流程惩戒」,讲到这里,镜同学想起过往的两个产品小案例。

案例一

前几年在做供应链金融时,我们有个项目是业务总监兼任项目经理,他中间越过工作流程强行加入不少业务需求,且这些需求并未经市场深度分析,让我们产品经理做起工作来很难受。

但是他总是以市场要动态快速响应,不仅没听我们建议,而且强制压缩设计时间,完全忽略了客观规律,进入了Go fever状态,让我们天天加班。(加班就能搞好产品?这两点你一定要明白!)

最后眼瞅项目团队就要分裂,项目也明显就要延期,我和总裁汇报后,总裁直接让审计中心发了个《项目督办通告》,重申了对项目职责、工作边界、协作机制及按期上线等要求。

其实大家都知道这就是针对该业务总监的,但是以公告形式发出,算是公开的警示,属于职场阳谋,后来他果然大幅收敛,不再一意孤行。

案例二

前段时间我们也在强调「经营导向」,业务在公司的地位也因势水涨船高,的确提了很多不合理的需求,甚至某个按钮觉得太小,用户看着不醒目,要求简单粗暴加大,离谱不?

不仅提报很多未经深度思考的「低质量市场需求」,一度还混淆了工作边界,颇有些对产品设计指点江山的味道,问就说「业务经营需要」,很多产品同学都自嘲:咱也不敢说,咱也不敢问。

后来我意识到必须要解决该问题,就找机会在公司经营会上提出来,当然,咱先是肯定了业务为导向的价值,认可了市场团队的责任心,表示坚决以公司经营规划为导向。

而后我也提出,为了更加科学、高效的管理市场需求,统筹各业务线的盈利发展,建议在市场需求提报时,增加「预期收益」模块,并认真研判、评审,且作为产品是否启动开发的重要依据。

领导很自然就通过了,而接下来市场需求就不再这么无序了,因为「预期收益」就像是个承诺书,写进文档后是会被追溯的,需求管理也通过流程优化得到明显改善

所以你看,解决问题不一定要推到重来、重建秩序,职场中也没有太多橡皮擦可以抹掉这些BUG,对我们而言,重要的是,抓住关键节点、蛇打七寸,厉行价值创造,实现产品价值。

还是那句话,公司团队不同部门之间绝非「敌我矛盾」,而是有机的统一,规范共识、达到更高效的合力才是最有意义的事

为我投票

我在参加人人都是产品经理2022年度作者评选,希望喜欢我的文章的朋友都能来支持我一下~

点击下方链接进入我的个人参选页面,点击红心即可为我投票。

每人每天最多可投35票,投票即可获得抽奖机会,抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦!

投票传送门:https://996.pm/7gBAd

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文由@产品大峡谷 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 学习了。所有公司都有长短期平衡问题,项目驱动还是战略驱动,鱼和熊掌怎么兼得。资源有限,项目很诱惑,再少也是肉,还是跪着把钱挣了吧。当业绩达到预期或者超预期,所有的问题都不是问题;当业绩未达标,没有问题也一定是有问题。

    来自广东 回复
  2. 请教下:预期收益没有达成或者差距非常大怎么办?对业务是否有所措施

    来自浙江 回复
  3. 学到了,作者真的是胸有格局💪🏻

    来自北京 回复
  4. 尊重产品

    来自中国 回复
  5. mark下

    来自广东 回复